Hide Forgot
Description of problem: IPAv2 server on RHEL6.2 beta (ipa.example.com) - running as NFS server IPAv2 client on RHEL5.7 (node01.example.com) - running as NFS client While trying to mount the exported filesystem from ipa, to node01 using: mount -v -t nfs4 -o sec=krb5 ipa.example.com:/ /mnt I would receive the following error at the command line on node01: ================================================================= mount: pinging: prog 100003 vers 4 prot tcp port 2049 mount.nfs4: Permission denied ================================================================= And get the following entry in /var/log/messages on the node01.example.com ================================================================= Nov 30 13:09:46 node01 rpc.gssd[2128]: handling krb5 upcall Nov 30 13:09:46 node01 rpc.gssd[2128]: Using keytab file '/etc/krb5.keytab' Nov 30 13:09:46 node01 rpc.gssd[2128]: INFO: Credentials in CC 'MEMORY:/tmp/krb5cc_machine_EXAMPLE.COM' are good until 1322760376 Nov 30 13:09:46 node01 rpc.gssd[2128]: using MEMORY:/tmp/krb5cc_machine_EXAMPLE.COM as credentials cache for machine creds Nov 30 13:09:46 node01 rpc.gssd[2128]: using environment variable to select krb5 ccache MEMORY:/tmp/krb5cc_machine_EXAMPLE.COM Nov 30 13:09:46 node01 rpc.gssd[2128]: creating context using fsuid 0 (save_uid 0) Nov 30 13:09:46 node01 rpc.gssd[2128]: creating tcp client for server ipa.example.com Nov 30 13:09:46 node01 rpc.gssd[2128]: creating context with server nfs.com Nov 30 13:09:46 node01 rpc.gssd[2128]: WARNING: Failed to create krb5 context for user with uid 0 for server ipa.example.com Nov 30 13:09:46 node01 rpc.gssd[2128]: WARNING: Failed to create krb5 context for user with uid 0 with credentials cache MEMORY:/tmp/krb5cc_machine_EXAMPLE.COM for server ipa.example.com Nov 30 13:09:46 node01 rpc.gssd[2128]: WARNING: Failed to create krb5 context for user with uid 0 with any credentials cache for server ipa.example.com ================================================================= Version-Release number of selected component (if applicable): ipa.example.com: nfs-utils-1.2.3-12.el6.x86_64 nfs-utils-lib-1.1.5-4.el6.x86_64 krb5-server-ldap-1.9-21.el6.x86_64 krb5-pkinit-openssl-1.9-21.el6.x86_64 krb5-workstation-1.9-21.el6.x86_64 krb5-libs-1.9-21.el6.x86_64 krb5-server-1.9-21.el6.x86_64 pam_krb5-2.3.11-8.el6.x86_64 node01.example.com: nfs-utils-lib-1.0.8-7.6.el5 nfs-utils-1.0.9-54.el5 krb5-libs-1.6.1-62.el5 pam_krb5-2.2.14-21.el5 pam_krb5-2.2.14-21.el5 krb5-workstation-1.6.1-62.el5 krb5-libs-1.6.1-62.el5 How reproducible: Easily reproduced, using the steps outlined below Steps to Reproduce: 1.) Install a RHEL 6.2 beta system using the Identity Management build profile select additional packages bind, and bind-dyndb-ldap. Once installed configure the IPA server using the following: ipa-server-install --setup-dns 2.) Install a minimal RHEL5.7 system, rhnreg_ks; yum update -y; yum install -y ipa-client; ipa-client-install --enable-dns-updates. 3.) Configure /etc/krb5.conf on both client and server to use: [libdefaults] allow_weak_crypto = true On the server: service krb5kdc restart On the client: service sssd restart 4.) Configure the keytab on both systems: On the server: ipa service-add nfs/ipa.example.com ipa service-add nfs/node01.example.com ipa-getkeytab -e des-cbc-crc -s ipa.example.com -p nfs/ipa.example.com -k /etc/krb5.keytab On the client: ipa-getkeytab -e des-cbc-crc -s ipa.example.com -p nfs/ipa.example.com -k /etc/krb5.keytab 5.) Configure the IPA server with the following /etc/exports: /export *(rw,fsid=0,insecure,no_subtree_check) /export gss/krb5(rw,fsid=0,insecure,no_subtree_check) /export gss/krb5i(rw,fsid=0,insecure,no_subtree_check) /export gss/krb5p(rw,fsid=0,insecure,no_subtree_check) mkdir /export exportfs -r 6.) Update /etc/sysconfig/nfs on both server, and client to use: SECURE_NFS="yes" RPCGSSDARGS="-vvv" RPCSVCGSSDARGS="-vvv" On the server: service nfs restart; service rpcgssd restart On the client: service rpcgssd restart To test the configuration run the mount command on the server: mount -v -t nfs4 -o sec=krb5 ipa.example.com:/ /mnt The mount should work without issue Once both systems have been configured, and the server tested, run the following command from the client: mount -v -t nfs4 -o sec=krb5 ipa.example.com:/ /mnt Actual results: mount: pinging: prog 100003 vers 4 prot tcp port 2049 mount.nfs4: Permission denied Expected results: mount: pinging: prog 100003 vers 4 prot tcp port 2049 [root@node01 ~]# mount |grep krb5 ipa.example.com:/ on /mnt type nfs4 (rw,sec=krb5,addr=192.168.122.43) Additional info: Issue was resolved after modifying adding the salt type to the ipa-getkeytab commands. If you run: ipa-getkeytab -e des-cbc-crc:normal -s ipa.example.com -p nfs/ipa.example.com -k /etc/krb5.keytab Warning: salt types are not honored with randomized passwords (see opt. -P) Keytab successfully retrieved and stored in: /etc/krb5.keytab Once you have the correct keytab entry, the mount will work properly. Thanks, Ryan
(In reply to comment #0) > 4.) Configure the keytab on both systems: > > On the server: > ipa service-add nfs/ipa.example.com > ipa service-add nfs/node01.example.com > ipa-getkeytab -e des-cbc-crc -s ipa.example.com -p nfs/ipa.example.com -k > /etc/krb5.keytab > > On the client: > ipa-getkeytab -e des-cbc-crc -s ipa.example.com -p nfs/ipa.example.com -k > /etc/krb5.keytab If the client command isn't a result of a copy/paste error, then it is incorrect. The client's keytab needs to contain the client's "nfs" keys (as the server's keytab needs to contain the server's "nfs" keys), like so: ipa-getkeytab -e des-cbc-crc -s ipa.example.com -p nfs/node01.example.com -k /etc/krb5.keytab
(In reply to comment #1) > If the client command isn't a result of a copy/paste error, then it is > incorrect. The client's keytab needs to contain the client's "nfs" keys (as > the server's keytab needs to contain the server's "nfs" keys), like so: > > ipa-getkeytab -e des-cbc-crc -s ipa.example.com -p nfs/node01.example.com -k > /etc/krb5.keytab Did this turn out to be a copy/paste error, or were the keytabs being set up improperly?
Yes, that was a copy/paster error in the reproduction steps. The issue was able to be resolved by adding the salt type to the keytab, using: ipa-getkeytab -e des-cbc-crc:normal -s ipa.example.com -p nfs/node01.example.com -k /etc/krb5.keytab
Salt types can only matter when the key being used is derived from a password, and unless you're using the -P option to be prompted for one, ipa-getkeytab should be forcing the salt type to "none". If you can perform a before/after comparison, please paste in the output of running "klist -k -e" on node01.example.com and 'kadmin.local -q 'getprinc nfs/nfs/node01.example.com' on ipa.example.com. Those are the two places where encryption and salt types are recorded are in the client's keytab and the KDC database, and they should help verify if there's something different going on than what I'm expecting based on the sources. The version information for the ipa-* packages on both systems may be helpful, too.
I am no longer testing across RHEL 5->6 major releases. I have convinced my client to build out the solution on RHEL6.2 across the board, so... I no longer have the test environment configured. I am not able to test, I can only provide you with the details of what the resolution was at the time. Thanks, Ryan
Unfortunately, that doesn't clarify if running the modified ipa-getkeytab command, where it should have had no effect and warned of this, actually made a meaningful difference. In case that it did, what caused you to run it the first way the first time?
Marking as closed due to insufficient data.