Hi,
I really struggle with "permission denied" while mounting NFS share with sec=krb5; Both machines(Ubuntu 14.04) , NFS client and server are configured with SSSD, and authentication seems to work (only one test user for configuration with PoSIX ids ;) 'getent passwd longina' returns correct values on both.
I joined both machines to AD with 'realmd', and additionaly created SPN principal nfs/jota.nat.c.example.com@NAT.C.EXAMPLE.COM with setspn.exe on AD and added keys to the /etc/krb5.keytab .
I expect to be able to mount NFS share with sec=krb5 as root on client using machine credentials.
HERE some debugging output
Output on client (jedi) from 'rpc.gssd' while mounting nfs share ----------------- doing error downcall handling gssd upcall (/run/rpc_pipefs/nfs/clnt9) handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 ' handling krb5 upcall (/run/rpc_pipefs/nfs/clnt9) process_krb5_upcall: service is '<null>' Full hostname for 'jota.nat.c.sdu.dk' is 'jota.nat.c.sdu.dk' Full hostname for 'jedi.nat.c.sdu.dk' is 'jedi.nat.c.sdu.dk' Success getting keytab entry for 'JEDI$@NAT.C.SDU.DK' INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_NAT.C.SDU.DK' are good until 1407542806 INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_NAT.C.SDU.DK' are good until 1407542806 using FILE:/tmp/krb5ccmachine_NAT.C.SDU.DK as credentials cache for machine creds using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_NAT.C.SDU.DK creating context using fsuid 0 (save_uid 0) creating tcp client for server jota.nat.c.sdu.dk DEBUG: port already set to 2049 creating context with server nfs@jota.nat.c.sdu.dk WARNING: Failed to create krb5 context for user with uid 0 for server jota.nat.c.sdu.dk WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5ccmachine_NAT.C.SDU.DK for server jota.n\ at.c.sdu.dk WARNING: Machine cache is prematurely expired or corrupted trying to recreate cache for server jota.nat.c.sdu.dk Full hostname for 'jota.nat.c.sdu.dk' is 'jota.nat.c.sdu.dk' Full hostname for 'jedi.nat.c.sdu.dk' is 'jedi.nat.c.sdu.dk' Success getting keytab entry for 'JEDI$@NAT.C.SDU.DK' INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_NAT.C.SDU.DK' are good until 1407542806 INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_NAT.C.SDU.DK' are good until 1407542806 using FILE:/tmp/krb5ccmachine_NAT.C.SDU.DK as credentials cache for machine creds using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_NAT.C.SDU.DK creating context using fsuid 0 (save_uid 0) creating tcp client for server jota.nat.c.sdu.dk DEBUG: port already set to 2049 creating context with server nfs@jota.nat.c.example.com WARNING: Failed to create krb5 context for user with uid 0 for server jota.nat.c.example.com WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM for server jota.n\ at.c.example.com WARNING: Failed to create machine krb5 context with any credentials cache for server jota.nat.c.example.com doing error downcall destroying client /run/rpc_pipefs/nfs/clnta destroying client /run/rpc_pipefs/nfs/clnt9
----------- client(jedi):
hostname: jedi ---------- root@jedi:/var/lib/sss/db# klist -c klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0) root@jedi:/var/lib/sss/db# klist -c /tmp/krb5ccmachine_NAT.C.EXAMPLE.COM Ticket cache: FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM Default principal: JEDI$@NAT.C.EXAMPLE.COM
Valid starting Expires Service principal 08/08/2014 16:06:46 08/09/2014 02:06:46 krbtgt/NAT.C.EXAMPLE.COM@NAT.C.EXAMPLE.COM renew until 08/09/2014 16:06:46 08/08/2014 16:06:46 08/09/2014 02:06:46 nfs/jota.nat.c.example.com@NAT.C.EXAMPLE.COM renew until 08/09/2014 16:06:46 root@jedi:/var/lib/sss/db# klist -ce /tmp/krb5ccmachine_NAT.C.EXAMPLE.COM Ticket cache: FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM Default principal: JEDI$@NAT.C.EXAMPLE.COM
Valid starting Expires Service principal 08/08/2014 16:06:46 08/09/2014 02:06:46 krbtgt/NAT.C.EXAMPLE.COM@NAT.C.EXAMPLE.COM renew until 08/09/2014 16:06:46, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 08/08/2014 16:06:46 08/09/2014 02:06:46 nfs/jota.nat.c.example.com@NAT.C.EXAMPLE.COM renew until 08/09/2014 16:06:46, Etype (skey, tkt): arcfour-hmac, arcfour-hmac
------------ root@jedi:/etc# klist -ek Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 6 host/jedi.nat.c.example.com@NAT.C.EXAMPLE.COM (des-cbc-crc) 6 host/jedi.nat.c.example.com@NAT.C.EXAMPLE.COM (des-cbc-md5) 6 host/jedi.nat.c.example.com@NAT.C.EXAMPLE.COM (aes128-cts-hmac-sha1-96) 6 host/jedi.nat.c.example.com@NAT.C.EXAMPLE.COM (aes256-cts-hmac-sha1-96) 6 host/jedi.nat.c.example.com@NAT.C.EXAMPLE.COM (arcfour-hmac) 6 host/JEDI@NAT.C.EXAMPLE.COM (des-cbc-crc) 6 host/JEDI@NAT.C.EXAMPLE.COM (des-cbc-md5) 6 host/JEDI@NAT.C.EXAMPLE.COM (aes128-cts-hmac-sha1-96) 6 host/JEDI@NAT.C.EXAMPLE.COM (aes256-cts-hmac-sha1-96) 6 host/JEDI@NAT.C.EXAMPLE.COM (arcfour-hmac) 6 JEDI$@NAT.C.EXAMPLE.COM (des-cbc-crc) 6 JEDI$@NAT.C.EXAMPLE.COM (des-cbc-md5) 6 JEDI$@NAT.C.EXAMPLE.COM (aes128-cts-hmac-sha1-96) 6 JEDI$@NAT.C.EXAMPLE.COM (aes256-cts-hmac-sha1-96) 6 JEDI$@NAT.C.EXAMPLE.COM (arcfour-hmac) ------------------------- Server (jota): --------------------- hostname: jota.nat.c.example.com ------- root@jota:/home/alongina# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 4 nfs/jota.nat.c.sdu.dk@NAT.C.SDU.DK (des-cbc-crc) 4 nfs/jota.nat.c.sdu.dk@NAT.C.SDU.DK (des-cbc-md5) 4 nfs/jota.nat.c.sdu.dk@NAT.C.SDU.DK (arcfour-hmac) 4 nfs/jota.nat.c.sdu.dk@NAT.C.SDU.DK (aes256-cts-hmac-sha1-96) 4 nfs/jota.nat.c.sdu.dk@NAT.C.SDU.DK (aes128-cts-hmac-sha1-96) 4 host/jota.nat.c.sdu.dk@NAT.C.SDU.DK (des-cbc-crc) 4 host/jota.nat.c.sdu.dk@NAT.C.SDU.DK (des-cbc-md5) 4 host/jota.nat.c.sdu.dk@NAT.C.SDU.DK (aes128-cts-hmac-sha1-96) 4 host/jota.nat.c.sdu.dk@NAT.C.SDU.DK (aes256-cts-hmac-sha1-96) 4 host/jota.nat.c.sdu.dk@NAT.C.SDU.DK (arcfour-hmac) 4 host/JOTA@NAT.C.SDU.DK (des-cbc-crc) 4 host/JOTA@NAT.C.SDU.DK (des-cbc-md5) 4 host/JOTA@NAT.C.SDU.DK (aes128-cts-hmac-sha1-96) 4 host/JOTA@NAT.C.SDU.DK (aes256-cts-hmac-sha1-96) 4 host/JOTA@NAT.C.SDU.DK (arcfour-hmac) 4 JOTA$@NAT.C.SDU.DK (des-cbc-crc) 4 JOTA$@NAT.C.SDU.DK (des-cbc-md5) 4 JOTA$@NAT.C.SDU.DK (aes128-cts-hmac-sha1-96) 4 JOTA$@NAT.C.SDU.DK (aes256-cts-hmac-sha1-96) 4 JOTA$@NAT.C.SDU.DK (arcfour-hmac)
root@jota:/# ps ax | grep rpc 512 ? Ss 0:00 rpcbind 625 ? Ss 0:00 rpc.statd -L 670 ? S< 0:00 [rpciod] 769 ? Ss 0:00 rpc.idmapd 850 ? Ss 0:00 rpc.gssd 2348 ? Ss 0:00 /usr/sbin/rpc.svcgssd -vvvvvvvvvv 2350 ? Ss 0:00 /usr/sbin/rpc.mountd --manage-gids
root@jota:/home/alongina# klist -c klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0) -------------- root@jota:/home/alongina# cat /etc/exports
# /nfs *(rw,crossmnt,no_subtree_check,sec=krb5:krb5p:krb5i) ---------------- root@jota:/home/alongina# kinit -k JOTA$@NAT.C.EXAMPLE.COM --------------- root@jota:/home/alongina# klist -c Ticket cache: FILE:/tmp/krb5cc_0 Default principal: JOTA$@NAT.C.EXAMPLE.COM
Valid starting Expires Service principal 08/08/14 16:36:44 09/08/14 02:36:44 krbtgt/NAT.C.EXAMPLE.COM@NAT.C.EXAMPLE.COM renew until 09/08/14 16:36:44
/var/log/syslog (rpc.svcgssd)
Aug 8 16:34:56 jota rpc.svcgssd[2348]: finished handling null request Aug 8 16:34:56 jota rpc.svcgssd[2348]: entering poll Aug 8 16:34:56 jota rpc.svcgssd[2348]: leaving poll Aug 8 16:34:56 jota rpc.svcgssd[2348]: handling null request Aug 8 16:34:56 jota rpc.svcgssd[2348]: svcgssd_limit_krb5_enctypes: Calling gss_set_allowable_enctypes with 7 enctypes from the kernel Aug 8 16:34:56 jota rpc.svcgssd[2348]: WARNING: gss_accept_sec_context failed Aug 8 16:34:56 jota rpc.svcgssd[2348]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - Wrong principal in request Aug 8 16:34:56 jota rpc.svcgssd[2348]: sending null reply
Mange hilsner Longina
On Fri, 2014-08-08 at 15:01 +0000, Longina Przybyszewska wrote:
I expect to be able to mount NFS share with sec=krb5 as root on client using machine credentials.
What mount command are you using? Is root a domain user who can get a ticket? Usually she isn't. Is the user mentioned on the mount command?
I expect to be able to mount NFS share with sec=krb5 as root on client using machine credentials.
What mount command are you using? mount.nfs4 -o rw,sec=krb5 jota.nat.c.example.com:/nfs /nfs
or entry in /etc/fstab: (mount on boot, or with 'mountall' as root) jota.nat.c.sdu.dk:/nfs /nfs nfs rw,sec=krb5 0 0
Is root a domain user who can get a ticket?
no (is machine's root she or he :) ??) Usually she isn't.
Is the user mentioned on the mount command? no - no user in options...
best, Longina
On Sun, 2014-08-10 at 15:54 +0000, Longina Przybyszewska wrote:
The nfs server is serving: jota.nat.c.sdu.dk nfs/jota.nat.c.sdu.dk@NAT.C.SDU.DK
Your client is not in that domain: host/jedi.nat.c.example.com@NAT.C.EXAMPLE.COM
José
No, not that simple ;( - sorry for typing fail.
Mount command: mount -t nfs4 -o rw,sec=krb5 jota.nat.c.example.com:/nfs /nfs
or 'mountall' with the following entry in /etc/fstab :
jota.nat.c.example.com:/nfs /nfs nfs4 rw,sec=krb5 0 0
On server /etc/exports: /nfs *(rw,crossmnt,no_subtree_check,sec=krb5)
I can't see there is a 'user' option for nfs mount.
Best
Longina
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Longina Przybyszewska Sent: 10. august 2014 17:54 To: End-user discussions about the System Security Services Daemon Subject: Re: [SSSD-users] NFS+KERB+SSSD Ubuntu 14.04
I expect to be able to mount NFS share with sec=krb5 as root on client using machine credentials.
What mount command are you using? mount.nfs4 -o rw,sec=krb5 jota.nat.c.example.com:/nfs /nfs
or entry in /etc/fstab: (mount on boot, or with 'mountall' as root) jota.nat.c.sdu.dk:/nfs /nfs nfs rw,sec=krb5 0 0
Is root a domain user who can get a ticket?
no (is machine's root she or he :) ??) Usually she isn't.
Is the user mentioned on the mount command? no - no user in options...
best, Longina _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Mon, 11 Aug 2014, Longina Przybyszewska wrote:
No, not that simple ;( - sorry for typing fail.
Mount command: mount -t nfs4 -o rw,sec=krb5 jota.nat.c.example.com:/nfs /nfs
or 'mountall' with the following entry in /etc/fstab :
jota.nat.c.example.com:/nfs /nfs nfs4 rw,sec=krb5 0 0
On server /etc/exports: /nfs *(rw,crossmnt,no_subtree_check,sec=krb5)
I can't see there is a 'user' option for nfs mount.
I fail to see how SSSD can be to blame for any of this, as the mount has nothing to do with mapping users.
I've always gone for an nfs/fqn userPrincipal for both client and server, which I understand to be a touch outdated with current nfs-utils. If you're using AD, it's also important to set the userAccountControl to limit the kerberos tickets to not include PAC, or else you'll have issues with user accounts that are members of a significant number of groups.
I think the significant bit is "Wrong principal in request" on the server.
Possibly things to check:
Check kvno lines up correctly for all machine credentials. When in doubt, delete the machine objects and start again.
Previously NFS was very limited in what enctypes it could cope with. Try again with:
[libdefaults] default_tkt_enctypes = arcfour-hmac
set in krb5.conf at both ends.
jh
On Mon, 2014-08-11 at 09:44 +0100, John Hodrien wrote:
Check kvno lines up correctly for all machine credentials. When in doubt, delete the machine objects and start again.
+1 Maybe easier to delete both server and client keytabs and recreate them. You can save a bit of time since the nfs/ key is necessary only on the server. The client is happy with MACHINE$. HTH, Steve
On Mon, 11 Aug 2014, steve wrote:
Maybe easier to delete both server and client keytabs and recreate them. You can save a bit of time since the nfs/ key is necessary only on the server. The client is happy with MACHINE$.
As long as you have sufficiently recent nfs-utils, which in this case you almost certainly do.
jh
No, not that simple ;( - sorry for typing fail.
What, 'typing fail'?
...when editing debugging output for posting to mailinglist
Mount command: mount -t nfs4 -o rw,sec=krb5 jota.nat.c.example.com:/nfs /nfs
Your server is not in that domain.
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users@lists.fedorahosted.org
-
John Hodrien -
Longina Przybyszewska -
steve