[Freeipa-devel] [PATCH][DOC] Fix NFS configuration documentation
Alexander Bokovoy
abokovoy at redhat.com
Wed Apr 16 11:35:47 UTC 2014
Hi,
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.
https://fedorahosted.org/freeipa/ticket/4310
--
/ Alexander Bokovoy
-------------- next part --------------
>From 825d9b89dc127154c87333dd9f3bc7238fa56b07 Mon Sep 17 00:00:00 2001
From: Alexander Bokovoy <abokovoy at redhat.com>
Date: Wed, 16 Apr 2014 14:27:58 +0300
Subject: [PATCH] NFS: update instructions to use safe method to transfer the
keytab
---
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 b/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>
RPCSVCGSSDARGS="-vvv"</programlisting>
</note>
+ <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>
<orderedlist>
<listitem>
<para>
@@ -424,22 +426,44 @@ RPCSVCGSSDARGS="-vvv"</programlisting>
<para>
On &IPAA; server, add an NFS service principal for the NFS client.
</para>
-<programlisting language="Bash">[root at server ~]# ipa service-add nfs/ipaclient.example.com at EXAMPLE</programlisting>
+<programlisting language="Bash">[root at server ~]# ipa service-add nfs/nfs.example.com at EXAMPLE</programlisting>
<note><title>NOTE</title>
<para>
- 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.
</para>
</note>
</listitem>
- <listitem>
+ <listitem>
<para>
- 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>
- <para>
-
-<programlisting language="Bash">[root at server ~]# ipa-getkeytab -s ipaserver.example.com -p nfs/ipaclient.example.com at EXAMPLE -k /tmp/krb5.keytab</programlisting>
-
+ <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 at nfs ~]# kinit -k host/`hostname`
+[root at nfs ~]# ipa-getkeytab -s ipaserver.example.com -p nfs/`hostname`@EXAMPLE -k /etc/krb5.keytab
+[root at 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 at server ~]# ipa-getkeytab -s ipaserver.example.com -p nfs/nfs.example.com at EXAMPLE -k /tmp/krb5.keytab
+[root at server ~]# chmod 0600 /tmp/krb5.keytab
+[root at server ~]# scp -p /tmp/krb5.keytab root at nfs.example.com:/tmp/krb5.keytab
+ ... switch over to the NFS server
+[root at nfs ~]# ( echo rkt /tmp/krb5.keytab ; echo wkt /etc/krb5.keytab ) | ktutil
+[root at nfs ~]# rm -f /tmp/krb5.keytab
+</programlisting>
</para>
+ <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>
<note>
<title>NOTE</title>
<para>
@@ -454,18 +478,6 @@ RPCSVCGSSDARGS="-vvv"</programlisting>
</listitem>
<listitem>
<para>
- 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 at server ~]# scp /tmp/krb5.keytab root at nfs.example.com:/etc/krb5.keytab</programlisting>
- </para>
- </listitem>
- <listitem>
- <para>
- Copy the keytab from the &IPA; server to the &IPA; client. For example:
-<programlisting language="Bash">[root at server ~]# scp /tmp/krb5.keytab root at client.example.com:/etc/krb5.keytab</programlisting>
- </para>
- </listitem>
- <listitem>
- <para>
Configure the <filename>/etc/exports</filename> file on the NFS server.
</para>
<programlisting language="Bash">/ipashare gss/krb5p(rw,no_root_squash,subtree_check,fsid=0)</programlisting>
@@ -476,7 +488,7 @@ RPCSVCGSSDARGS="-vvv"</programlisting>
<itemizedlist>
<listitem>
<para>
- 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.
</para>
</listitem>
<listitem>
@@ -486,7 +498,7 @@ RPCSVCGSSDARGS="-vvv"</programlisting>
</listitem>
</itemizedlist>
</para>
-<programlisting language="Bash">[root at ipaclient ~]# mount -v -t nfs4 -o sec=krb5p nfs.example.com:/ /mnt/ipashare</programlisting>
+<programlisting language="Bash">[root at ipaclient ~]# mount -v -t nfs4 -o sec=krb5p nfs.example.com:/ipashare /mnt/ipashare</programlisting>
</listitem>
</orderedlist>
</section>
--
1.9.0
More information about the Freeipa-devel
mailing list