Google for: rpc.gssd Failed to create krb5 context for user

http://joshuawise.com/kerberos-nfs
has some debugging, and take about idmapd issues

There are also RedHat and CentOS threads listed.


On 8/24/2012 11:39 AM, Derek Warren wrote:
> Hello all,
>
> We have a test CentOS 6.3 NFSv4 server and client[0], both bound to a Windows 
> 2008 R2 Active Directory domain controller.
>
> We don't appear to be having any issues calling `kinit -k` to get machine 
> credentials[1], or logging in with pam_krb5[2].  (RHEL's `authconfig` took 
> care of all that for us.)
>
> The problem: our test NFS client is unable to list "private" (chmod 700-ed) 
> directories, even if the current user owns the directory in question.
>
> ID mapping works:
>       [joeuser@nfsclient ~]$ id joeuser
>       uid=56055(joeuser) gid=6502(domain users) groups=6502(domain 
> users),1000001(BUILTIN\users)
>
>
> ... and we can mount directories with -o sec=none/krb5/krb5i/krb5p:
>       [joeuser@nfsclient ~]$ sudo mount -t nfs4 -o proto=tcp,port=2049 -o 
> sec=krb5p nfsserver.example.com:/testdir /mnt
>       
>       [joeuser@nfsclient ~]$ ls -l /mnt
>       drwx------ 2 user1    domain users 4096 Aug  3 11:43 user1
>       drwx------ 2 adbinder domain users 4096 Aug 17 15:20 adbinder
>       drwx------ 2 joeuser  domain users 4096 Aug  3 11:43 joeuser
>
> ... but we hit the wall here:
>       [joeuser@nfsclient ~]$ cd /mnt/joeuser
>       bash: cd: joeuser: Permission denied
>
> At this point, we get a warning from rpc.gssd: "Failed to create krb5 context 
> for user xxx..."[3]
>
> Mailing list archives suggest this is usually a matter of mismatched 
> UIDs/GIDs, but we don't appear to have such a problem--we are happily 
> retrieving[4] identical UID/GID info from our Active Directory DC (W2K8R2) 
> via Samba 3.5 and winbindd on both the server and client.
>
> We are using a least-privileges-required Active Directory bind account[5] for 
> Samba/winbind, but I can reproduce the same issue with a full-on "Domain 
> Admin" bind account.
>
> NFSv4 mounts with sec=sys work fine, but sec=none or sec=krb5/i/p results in 
> the problem described above.  World-readable and -executable directories are 
> readily accessed without any problems.
>
> If encryption type mismatches are a problem, neither rpc.svcgssd or rpc.gssd 
> have complained.  Our krb5.conf file looks like this: [6]
>
>
> Does this sound more like a Linux KRB5 client issue or a Win2K8R2 KDC issue?  
> An educated guess or wild speculation from anyone more experienced that me 
> (that's everyone here) would be most welcome.
>
>
> Many thanks,
>
> --
> Derek Warren, IT Services, Research Computing Group, Simon Fraser University
>
>
>
>
> [0] Both hosts are running CentOS 6.3:
>       $ uname -a ; cat /etc/redhat-release ; rpm -qa | egrep 
> "(samba|winbind|nfs)"
>       Linux nfsserver 2.6.32-279.2.1.el6.x86_64 #1 SMP Fri Jul 20 01:55:29 
> UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
>       CentOS release 6.3 (Final)
>       nfs-utils-1.2.3-26.el6.x86_64
>       nfs-utils-lib-1.1.5-4.el6.x86_64
>       samba-client-3.5.10-125.el6.x86_64
>       samba-common-3.5.10-125.el6.x86_64
>       samba-winbind-3.5.10-125.el6.x86_64
>       samba-winbind-clients-3.5.10-125.el6.x86_64
>
> Out of curiosity, I tried the same AD/Winbind/NFSv4 setup on Fedora 17 and 
> had the same results when mounting either -o sec=none or -o sec=krb5/i/p:
>       $ uname -a ; cat /etc/redhat-release ; rpm -qa | egrep 
> "(samba|winbind|nfs)"
>       Linux nfsserver-fedora 3.5.2-1.fc17.x86_64 #1 SMP Wed Aug 15 16:09:27 
> UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
>       Fedora release 17 (Beefy Miracle)
>       libnfsidmap-0.25-3.fc17.x86_64
>       libnfsidmap-debuginfo-0.25-3.fc17.x86_64
>       nfs-utils-1.2.6-3.fc17.x86_64
>       nfs-utils-debuginfo-1.2.6-3.fc17.x86_64
>       samba-3.6.6-92.fc17.1.x86_64
>       samba-client-3.6.6-92.fc17.1.x86_64
>       samba-common-3.6.6-92.fc17.1.x86_64
>       samba-winbind-3.6.6-92.fc17.1.x86_64
>       samba-winbind-clients-3.6.6-92.fc17.1.x86_64
>
>
>
> [1] No kinit problems here, we think...
> # net ads join createupn="nfs/[email protected]" 
> createcomputer="OU" -U $BINDUSER%$BINDPASSWD
> # kinit -k NFSSERVER$
> # net ads keytab add nfs
>
> # klist -ke
> Keytab name: WRFILE:/etc/krb5.keytab
> KVNO Principal
> ---- 
> --------------------------------------------------------------------------
>    3 host/[email protected] (des-cbc-crc)
>    3 host/[email protected] (des-cbc-md5)
>    3 host/[email protected] (arcfour-hmac)
>    3 host/[email protected] (des-cbc-crc)
>    3 host/[email protected] (des-cbc-md5)
>    3 host/[email protected] (arcfour-hmac)
>    3 [email protected] (des-cbc-crc)
>    3 [email protected] (des-cbc-md5)
>    3 [email protected] (arcfour-hmac)
>    3 nfs/[email protected] (des-cbc-crc)
>    3 nfs/[email protected] (des-cbc-md5)
>    3 nfs/[email protected] (arcfour-hmac)
>    3 nfs/[email protected] (des-cbc-crc)
>    3 nfs/[email protected] (des-cbc-md5)
>    3 nfs/[email protected] (arcfour-hmac)      
> (same `klist -ke` output on the client, too)
>
>
>
>
> [2] Our clocks are synced and pam_krb5 lets us in:
> $ ssh [email protected]
> [email protected]'s password:
> Last login: Fri Aug 24 07:39:42 2012 from nowheresville.example.com
>
> [joeuser@nfsclient ~]$ cd /mnt
> /mnt: Permission denied.
>
> [joeuser@nfsclient ~]$ klist -e
> Ticket cache: FILE:/tmp/krb5cc_56055_2iPnxk
> Default principal: [email protected]
>
> Valid starting     Expires            Service principal
> 08/24/12 08:44:06  08/24/12 18:44:11  krbtgt/[email protected]
>       renew until 08/31/12 08:44:06, Etype (skey, tkt): arcfour-hmac, 
> arcfour-hmac
> 08/24/12 08:44:14  08/24/12 18:44:11  nfs/[email protected]
>       renew until 08/31/12 08:44:06, Etype (skey, tkt): arcfour-hmac, 
> arcfour-hmac
>
>
>
>
> [3] rpc.gssd complains "Failed to create krb5 context for user with uid 
> xxx..."
>
> nfsclient rpc.gssd[10256]: handling gssd upcall 
> (/var/lib/nfs/rpc_pipefs/nfs/clnt1b)
> nfsclient rpc.gssd[10256]: handle_gssd_upcall: 'mech=krb5 uid=56055 
> enctypes=18,17,16,23,3,1,2 '
> nfsclient rpc.gssd[10256]: handling krb5 upcall 
> (/var/lib/nfs/rpc_pipefs/nfs/clnt1b)
> nfsclient rpc.gssd[10256]: process_krb5_upcall: service is '<null>'
> nfsclient rpc.gssd[10256]: getting credentials for client with uid 56055 for 
> server nfsserver.example.com
> nfsclient rpc.gssd[10256]: CC file '/tmp/krb5cc_56055_od8D5s' being 
> considered, with preferred realm 'AD.EXAMPLE.COM'
> nfsclient rpc.gssd[10256]: CC file 
> '/tmp/krb5cc_56055_od8D5s'([email protected]) passed all checks and has 
> mtime of 1344544593
> nfsclient rpc.gssd[10256]: CC file '/tmp/krb5cc_56055_DUEN2I' being 
> considered, with preferred realm 'AD.EXAMPLE.COM'
> nfsclient rpc.gssd[10256]: CC file 
> '/tmp/krb5cc_56055_DUEN2I'([email protected]) passed all checks and has 
> mtime of 1344543679
> nfsclient rpc.gssd[10256]: CC file '/tmp/krb5cc_56055_od8D5s' is our current 
> best match with mtime of 1344544593
> nfsclient rpc.gssd[10256]: CC file '/tmp/krb5cc_0' being considered, with 
> preferred realm 'AD.EXAMPLE.COM'
> nfsclient rpc.gssd[10256]: CC file '/tmp/krb5cc_0' owned by 0, not 56055
> nfsclient rpc.gssd[10256]: using FILE:/tmp/krb5cc_56055_od8D5s as credentials 
> cache for client with uid 56055 for server nfsserver.example.com
> nfsclient rpc.gssd[10256]: using environment variable to select krb5 ccache 
> FILE:/tmp/krb5cc_56055_od8D5s
> nfsclient rpc.gssd[10256]: creating context using fsuid 56055 (save_uid 0)
> nfsclient rpc.gssd[10256]: creating tcp client for server 
> nfsserver.example.com
> nfsclient rpc.gssd[10256]: DEBUG: port already set to 2049
> nfsclient rpc.gssd[10256]: creating context with server 
> [email protected]
> nfsclient rpc.gssd[10256]: WARNING: Failed to create krb5 context for user 
> with uid 56055 for server nfsserver.example.com
> nfsclient rpc.gssd[10256]: WARNING: Failed to create krb5 context for user 
> with uid 56055 for server nfsserver.example.com
> nfsclient rpc.gssd[10256]: doing error downcall
>
>
>
>
> [4] ID mapping problems? Nothing seems wrong here:
>
> nfsserver rpc.idmapd[1455]: Server : (user) id "56055" -> name 
> "[email protected]"
> nfsserver rpc.idmapd[1455]: nfsdcb: authbuf=gss/krb5p authtype=group
> nfsserver rpc.idmapd[1455]: nfs4_gid_to_name: calling nsswitch->gid_to_name
> nfsserver rpc.idmapd[1455]: nfs4_gid_to_name: nsswitch->gid_to_name returned 0
> nfsserver rpc.idmapd[1455]: nfs4_gid_to_name: final return value is 0
> nfsserver rpc.idmapd[1455]: Server : (group) id "6502" -> name "domain 
> [email protected]"
> nfsserver rpc.idmapd[1455]: nfsdcb: authbuf=gss/krb5p authtype=user
> nfsserver rpc.idmapd[1455]: nfs4_uid_to_name: calling nsswitch->uid_to_name
> nfsserver rpc.idmapd[1455]: nfs4_uid_to_name: nsswitch->uid_to_name returned 0
> nfsserver rpc.idmapd[1455]: nfs4_uid_to_name: final return value is 0
> nfsserver rpc.idmapd[1455]: Server : (user) id "0" -> name 
> "[email protected]"
> nfsserver rpc.idmapd[1455]: nfsdcb: authbuf=199.60.0.0/255.255.240.0 
> authtype=group
> nfsserver rpc.idmapd[1455]: nfs4_gid_to_name: calling nsswitch->gid_to_name
> nfsserver rpc.idmapd[1455]: nfs4_gid_to_name: nsswitch->gid_to_name returned 0
> nfsserver rpc.idmapd[1455]: nfs4_gid_to_name: final return value is 0
> nfsserver rpc.idmapd[1455]: Server : (group) id "0" -> name 
> "[email protected]"
> nfsserver rpc.idmapd[1455]: nfsdcb: authbuf=199.60.0.0/255.255.240.0 
> authtype=user
> nfsserver rpc.idmapd[1455]: nfs4_uid_to_name: calling nsswitch->uid_to_name
> nfsserver rpc.idmapd[1455]: nfs4_uid_to_name: nsswitch->uid_to_name returned 0
> nfsserver rpc.idmapd[1455]: nfs4_uid_to_name: final return value is 0
>
>
> [5] Our method for creating a least-privileges-required Samba/winbind bind 
> account on a W2K8R2 DC, taken from HP Samba documentation:
> 1. Run ADU&C. View menu=>Advanced Features
> 2. Create a binding account (e.g., 'megabind')
> 3. Right-click on the relevant OU=>Properties=>Security tab
> 4. [Advanced]=>[Add...]=>megabind=>[OK]
> 5. [megabind: This object and all descendant objects...]      
>       => Write All Properties: allow
>       => Create Computer objects: allow
> 6. [OK]/[OK]/[OK]
>
>
>
> [6] http://www.sfu.ca/~warren/krb5.conf.txt
> ________________________________________________
> Kerberos mailing list           [email protected]
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>

-- 

  Douglas E. Engert  <[email protected]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444


________________________________________________
Kerberos mailing list           [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos

Reply via email to