10:01 a.m.
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(a)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$(a)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(a)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$(a)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(a)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$(a)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(a)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(a)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$(a)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(a)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(a)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(a)NAT.C.EXAMPLE.COM (des-cbc-crc)
6 host/jedi.nat.c.example.com(a)NAT.C.EXAMPLE.COM (des-cbc-md5)
6 host/jedi.nat.c.example.com(a)NAT.C.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
6 host/jedi.nat.c.example.com(a)NAT.C.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
6 host/jedi.nat.c.example.com(a)NAT.C.EXAMPLE.COM (arcfour-hmac)
6 host/JEDI(a)NAT.C.EXAMPLE.COM (des-cbc-crc)
6 host/JEDI(a)NAT.C.EXAMPLE.COM (des-cbc-md5)
6 host/JEDI(a)NAT.C.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
6 host/JEDI(a)NAT.C.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
6 host/JEDI(a)NAT.C.EXAMPLE.COM (arcfour-hmac)
6 JEDI$(a)NAT.C.EXAMPLE.COM (des-cbc-crc)
6 JEDI$(a)NAT.C.EXAMPLE.COM (des-cbc-md5)
6 JEDI$(a)NAT.C.EXAMPLE.COM (aes128-cts-hmac-sha1-96)
6 JEDI$(a)NAT.C.EXAMPLE.COM (aes256-cts-hmac-sha1-96)
6 JEDI$(a)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(a)NAT.C.SDU.DK (des-cbc-crc)
4 nfs/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (des-cbc-md5)
4 nfs/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (arcfour-hmac)
4 nfs/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (aes256-cts-hmac-sha1-96)
4 nfs/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (aes128-cts-hmac-sha1-96)
4 host/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (des-cbc-crc)
4 host/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (des-cbc-md5)
4 host/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (aes128-cts-hmac-sha1-96)
4 host/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (aes256-cts-hmac-sha1-96)
4 host/jota.nat.c.sdu.dk(a)NAT.C.SDU.DK (arcfour-hmac)
4 host/JOTA(a)NAT.C.SDU.DK (des-cbc-crc)
4 host/JOTA(a)NAT.C.SDU.DK (des-cbc-md5)
4 host/JOTA(a)NAT.C.SDU.DK (aes128-cts-hmac-sha1-96)
4 host/JOTA(a)NAT.C.SDU.DK (aes256-cts-hmac-sha1-96)
4 host/JOTA(a)NAT.C.SDU.DK (arcfour-hmac)
4 JOTA$(a)NAT.C.SDU.DK (des-cbc-crc)
4 JOTA$(a)NAT.C.SDU.DK (des-cbc-md5)
4 JOTA$(a)NAT.C.SDU.DK (aes128-cts-hmac-sha1-96)
4 JOTA$(a)NAT.C.SDU.DK (aes256-cts-hmac-sha1-96)
4 JOTA$(a)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\$(a)NAT.C.EXAMPLE.COM
---------------
root@jota:/home/alongina# klist -c
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: JOTA$(a)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(a)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
10:39 a.m.
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?
10:54 a.m.
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
2:09 p.m.
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(a)NAT.C.SDU.DK
Your client is not in that domain:
host/jedi.nat.c.example.com(a)NAT.C.EXAMPLE.COM
José
3:20 a.m.
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(a)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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
3:44 a.m.
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
3:58 a.m.
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
4 a.m.
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
5 a.m.
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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
3545
days inactive
3548
days old
sssd-users@lists.fedorahosted.org
9 comments
3 participants
participants (3)
-
John Hodrien -
Longina Przybyszewska -
steve