Attached patch attempts to improve NFS configuration section.
Please review, if it is OK, I'll prepare patch to update the other parts
as we have quite a duplication across the guide.


/ Alexander Bokovoy
>From 825d9b89dc127154c87333dd9f3bc7238fa56b07 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy <aboko...@redhat.com>
Date: Wed, 16 Apr 2014 14:27:58 +0300
Subject: [PATCH] NFS: update instructions to use safe method to transfer the

 src/user_guide/en-US/InstallingClients.xml | 56 ++++++++++++++++++------------
 1 file changed, 34 insertions(+), 22 deletions(-)

diff --git a/src/user_guide/en-US/InstallingClients.xml 
index 1665a6c..f4795c3 100644
--- a/src/user_guide/en-US/InstallingClients.xml
+++ b/src/user_guide/en-US/InstallingClients.xml
@@ -413,6 +413,8 @@ $ getent group admins</programlisting>
+                               <para>Kerberos authentication requires that 
both client and server participating in an exchange have own Kerberos 
principals. NFS servers are configured by default to use a Kerberos principal 
named <emphasis>nfs/server's host name</emphasis>. NFS client software 
constructs NFS server's Kerberos principal by prepending 
<emphasis>nfs/</emphasis> to the server's hostname. The client's Kerberos 
principal is not that important; as long as KDC permits issuing a ticket 
towards <emphasis>nfs/server.example.com</emphasis>, the client's Kerberos 
principal can be used to perform the authentication. For example, an NFS client 
can connect using <emphasis>host/client.example.com</emphasis> principal or as 
a specific user.</para>
+                               <para>When NFS server machine 
<emphasis>nfs.example.com</emphasis> is enrolled to &IPAA; domain as &IPAA; 
client, a service named <emphasis>nfs/nfs.example.com</emphasis> has to be 
created by &IPAA; administrator and the service key has to be extracted and 
stored on the NFS server.</para>
@@ -424,22 +426,44 @@ RPCSVCGSSDARGS="-vvv"</programlisting>
                                                        On &IPAA; server, add 
an NFS service principal for the NFS client.
-<programlisting language="Bash">[root@server ~]# ipa service-add 
+<programlisting language="Bash">[root@server ~]# ipa service-add 
-                                                               This must be 
run from a machine with the <package>ipa-admintools</package> package installed 
so that the <command>ipa</command> command is available.
+                                                               This command 
must be run on a machine with the <package>ipa-admintools</package> package 
installed so that the <command>ipa</command> command is available.
-                                        <listitem>
+                                       <listitem>
-                                                       On the &IPA; server, 
obtain a keytab for the NFS service principal.
+                                                       Next we need to obtain 
a keytab for the NFS service principal. The keytab contains long term Kerberos 
key which uniquely authenticates <emphasis>nfs/nfs.example.com</emphasis> to 
the KDC. This key must be protected or otherwise anyone who has access to the 
key may impersonate the NFS server. Ideally, NFS server is &IPAA; client, thus 
it should already have <command>ipa-getkeytab</command> installed.
-                                                <para>
-<programlisting language="Bash">[root@server ~]# ipa-getkeytab -s 
ipaserver.example.com -p nfs/ipaclient.example.com@EXAMPLE -k 
+                                               <orderedlist>
+                                                       <listitem>
+                                               <para>
+                                                       If NFS server has 
<command>ipa-getkeytab</command> installed, it is safer to fetch the key 
directly from the NFS server. Given that &IPA;-enrolled machine owns all 
services associated with it, <emphasis>host/nfs.example.com</emphasis> 
principal may retrieve the NFS service keytab directly on the NFS server:
+                                                       <programlisting 
language="Bash">[root@nfs ~]# kinit -k host/`hostname`
+[root@nfs ~]# ipa-getkeytab -s ipaserver.example.com -p nfs/`hostname`@EXAMPLE 
-k /etc/krb5.keytab
+[root@nfs ~]# kdestroy</programlisting>
+                                               </para>
<para><command>ipa-getkeytab</command> utility makes sure to not overwrite 
other Kerberos keys in the keytab.
+                                               </para>
+                                       </listitem>
+                                       <listitem>
+                                               <para>
+                                                        If 
<command>ipa-getkeytab</command> is not available on the NFS server, the keys 
can be fetched up on the &IPA; server and copied over to the NFS server:
+                                                        <programlisting 
language="Bash">[root@server ~]# ipa-getkeytab -s ipaserver.example.com -p 
nfs/nfs.example.com@EXAMPLE -k /tmp/krb5.keytab
+[root@server ~]# chmod 0600 /tmp/krb5.keytab
+[root@server ~]# scp -p /tmp/krb5.keytab r...@nfs.example.com:/tmp/krb5.keytab
+ ... switch over to the NFS server
+[root@nfs ~]# ( echo rkt /tmp/krb5.keytab ; echo wkt /etc/krb5.keytab ) | 
+[root@nfs ~]# rm -f /tmp/krb5.keytab
+                                               <para>
+                                                       It is recommended to 
use <command>ktutil</command> utility to transfer Kerberos keys between keytabs 
to avoid overwriting keys that are already placed in the keytab by other 
applications. For example, all &IPA; clients have their 
<emphasis>host/client.example.com</emphasis> keys stored in 
<filename>/etc/krb5.keytab</filename> file. Simple overwrite of the file will 
render SSH authentication to the client impossible as SSH server will not be 
able to authenticate to the KDC using 
<emphasis>host/client.example.com</emphasis> key. The same can be said about 
users and groups as SSSD on &IPA; clients is configured to authenticate with 
the help of the host key.
+                                               </para>
+                                       </listitem>
+                               </orderedlist>
@@ -454,18 +478,6 @@ RPCSVCGSSDARGS="-vvv"</programlisting>
-                                                       Copy the keytab from 
the &IPA; server to the NFS server. For example, if the &IPA; and NFS servers 
are on different machines:
-<programlisting language="Bash">[root@server ~]# scp /tmp/krb5.keytab 
-                                               </para>
-                                       </listitem>
-                                       <listitem>
-                                               <para>
-                                                       Copy the keytab from 
the &IPA; server to the &IPA; client. For example:
-<programlisting language="Bash">[root@server ~]# scp /tmp/krb5.keytab 
-                                               </para>
-                                       </listitem>
-                                       <listitem>
-                                               <para>
                                                        Configure the 
<filename>/etc/exports</filename> file on the NFS server.
 <programlisting  language="Bash">/ipashare       
@@ -476,7 +488,7 @@ RPCSVCGSSDARGS="-vvv"</programlisting>
Always specify the share as <emphasis>nfs_server:/ /mountpoint</emphasis>.
Always specify the share as <emphasis>nfs.example.com:/share 
/mountpoint</emphasis>, using fully-qualified domain name of the NFS server.
@@ -486,7 +498,7 @@ RPCSVCGSSDARGS="-vvv"</programlisting>
-<programlisting  language="Bash">[root@ipaclient ~]# mount -v -t nfs4 -o 
sec=krb5p nfs.example.com:/ /mnt/ipashare</programlisting>
+<programlisting  language="Bash">[root@ipaclient ~]# mount -v -t nfs4 -o 
sec=krb5p nfs.example.com:/ipashare /mnt/ipashare</programlisting>

Freeipa-devel mailing list

Reply via email to