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 don't blame SSSD either ;) The only context to SSSD could be - joining computers to AD - as I joined both computers with 'realmd' method recommended by SSSD team. The Kerberos keys created by realm are good enough for authentication users with SSSD. 'Realm' does not support adding SPN principal into AD ; To create nfs principal for server I used method described in https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server with the following commands:
setspn -A nfs/jota.nat.c.example.com jota ktpass /princ nfs/jota.nat.c.example.com@NAT.C.EXAMPLE.COM /out jota-nfs-2.keytab /crypto all /ptype KRB5_NT_PRINCIPAL -desonly /mapuser NAT-EXAMPLE\JOTA$ -setupn -setpass +rndPass +answer
(NAT-EXAMPLE in my case is short AD domain name)
I added keytab for nfs principal to the NFS server's /etc/krb5.keytab
root@jota:/# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 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) 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)
...and I am getting persistent "Permission denied " on client.
Version of nfs-utils Is the same:
root@jota:/home/alongina# dpkg -l | grep nfs ii libnfsidmap2:amd64 0.25-5 amd64 NFS idmapping library ii nfs-common 1:1.2.8-6ubuntu1.1 amd64 NFS support files common to client and server ii nfs-kernel-server 1:1.2.8-6ubuntu1.1 amd64 support for NFS kernel server
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.
Kvno seems to be OK ; (SSSD could be the proof)
Previously NFS was very limited in what enctypes it could cope with. Try again with:
[libdefaults] default_tkt_enctypes = arcfour-hmac
I added that option to /etc/krb5.conf (on both, and rebooted both); Still permission denied...
ON client:
Output from rpc.gssd after issuing 'mount' command -------------------------------- Success getting keytab entry for 'JEDI$@NAT.C.EXAMPLE.COM' INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM' are good until 1407800571 INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM' are good until 1407800571 using FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM as credentials cache for machine creds using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM creating context using fsuid 0 (save_uid 0) creating tcp client for server jota.nat.c.example.com 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.nat.c.example.com WARNING: Machine cache is prematurely expired or corrupted trying to recreate cache for server jota.nat.c.example.com Full hostname for 'jota.nat.c.example.com' is 'jota.nat.c.example.com' Full hostname for 'jedi.nat.c.example.com' is 'jedi.nat.c.example.com' Success getting keytab entry for 'JEDI$@NAT.C.EXAMPLE.COM' INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM' are good until 1407800571 INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM' are good until 1407800571 using FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM as credentials cache for machine creds using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM creating context using fsuid 0 (save_uid 0) creating tcp client for server jota.nat.c.example.com 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.nat.c.example.com WARNING: Failed to create machine krb5 context with any credentials cache for server jota.nat.c.example.com doing error downcall
Kerberos cache on the client:
root@jedi:/home/longinap# 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/11/2014 15:42:51 08/12/2014 01:42:51 krbtgt/NAT.C.EXAMPLE.COM@NAT.C.EXAMPLE.COM renew until 08/12/2014 15:42:51, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 08/11/2014 15:42:51 08/12/2014 01:42:51 nfs/jota.nat.c.example.com@NAT.C.EXAMPLE.COM renew until 08/12/2014 15:42:51, Etype (skey, tkt): arcfour-hmac, arcfour-hmac
------------------- Encryption mismatch? Principal mismach? !"#¤%&! -- Longina
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Mon, 2014-08-11 at 15:16 +0000, Longina Przybyszewska wrote
I added keytab for nfs principal to the NFS server's /etc/krb5.keytab
root@jota:/# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal
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) 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)
Mmm. Once again. The nfs server is serving a different domain to the client.
Your client will get nothing from this server with that keytab in those domains!
yeah, am getting blind, and got square eyes...sanitizing output.
My hosts _are_ in the same domain. L. _______________________________________ From: sssd-users-bounces@lists.fedorahosted.org [sssd-users-bounces@lists.fedorahosted.org] on behalf of Longina Przybyszewska [longina@sdu.dk] Sent: 11 August 2014 17:16 To: End-user discussions about the System Security Services Daemon (sssd-users@lists.fedorahosted.org) Subject: [SSSD-users] FW: NFS+KERB+SSSD Ubuntu 14.04
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 don't blame SSSD either ;) The only context to SSSD could be - joining computers to AD - as I joined both computers with 'realmd' method recommended by SSSD team. The Kerberos keys created by realm are good enough for authentication users with SSSD. 'Realm' does not support adding SPN principal into AD ; To create nfs principal for server I used method described in https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server with the following commands:
setspn -A nfs/jota.nat.c.example.com jota ktpass /princ nfs/jota.nat.c.example.com@NAT.C.EXAMPLE.COM /out jota-nfs-2.keytab /crypto all /ptype KRB5_NT_PRINCIPAL -desonly /mapuser NAT-EXAMPLE\JOTA$ -setupn -setpass +rndPass +answer
(NAT-EXAMPLE in my case is short AD domain name)
I added keytab for nfs principal to the NFS server's /etc/krb5.keytab
root@jota:/# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 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) 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)
...and I am getting persistent "Permission denied " on client.
Version of nfs-utils Is the same:
root@jota:/home/alongina# dpkg -l | grep nfs ii libnfsidmap2:amd64 0.25-5 amd64 NFS idmapping library ii nfs-common 1:1.2.8-6ubuntu1.1 amd64 NFS support files common to client and server ii nfs-kernel-server 1:1.2.8-6ubuntu1.1 amd64 support for NFS kernel server
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.
Kvno seems to be OK ; (SSSD could be the proof)
Previously NFS was very limited in what enctypes it could cope with. Try again with:
[libdefaults] default_tkt_enctypes = arcfour-hmac
I added that option to /etc/krb5.conf (on both, and rebooted both); Still permission denied...
ON client:
Output from rpc.gssd after issuing 'mount' command -------------------------------- Success getting keytab entry for 'JEDI$@NAT.C.EXAMPLE.COM' INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM' are good until 1407800571 INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM' are good until 1407800571 using FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM as credentials cache for machine creds using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM creating context using fsuid 0 (save_uid 0) creating tcp client for server jota.nat.c.example.com 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.nat.c.example.com WARNING: Machine cache is prematurely expired or corrupted trying to recreate cache for server jota.nat.c.example.com Full hostname for 'jota.nat.c.example.com' is 'jota.nat.c.example.com' Full hostname for 'jedi.nat.c.example.com' is 'jedi.nat.c.example.com' Success getting keytab entry for 'JEDI$@NAT.C.EXAMPLE.COM' INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM' are good until 1407800571 INFO: Credentials in CC 'FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM' are good until 1407800571 using FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM as credentials cache for machine creds using environment variable to select krb5 ccache FILE:/tmp/krb5ccmachine_NAT.C.EXAMPLE.COM creating context using fsuid 0 (save_uid 0) creating tcp client for server jota.nat.c.example.com 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.nat.c.example.com WARNING: Failed to create machine krb5 context with any credentials cache for server jota.nat.c.example.com doing error downcall
Kerberos cache on the client:
root@jedi:/home/longinap# 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/11/2014 15:42:51 08/12/2014 01:42:51 krbtgt/NAT.C.EXAMPLE.COM@NAT.C.EXAMPLE.COM renew until 08/12/2014 15:42:51, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 08/11/2014 15:42:51 08/12/2014 01:42:51 nfs/jota.nat.c.example.com@NAT.C.EXAMPLE.COM renew until 08/12/2014 15:42:51, Etype (skey, tkt): arcfour-hmac, arcfour-hmac
------------------- Encryption mismatch? Principal mismach? !"#¤%&! -- Longina
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Mon, 2014-08-11 at 16:26 +0000, Longina Przybyszewska wrote:
yeah, am getting blind, and got square eyes
Here is our nfs4 setup, also against AD: http://linuxcostablanca.blogspot.com.es/p/samba-4.html
There are lots of misinformed notes about nfs4. Early versions had to be exported from a fsuid 0 pseudo-root folder to which the actual exports were bind mounted. Recent versions should _not_ be so exported. You export them as normal folders as you always have done.
What do you have at /etc/exports and /etc/idmapd.conf Does the same configuration mount with kerberised nfs3?
Hi Steve , thanks for links to your great stuff.
There is some progress here with my issue.
I could figure out, using different principals on the server (rpc.svcgssd -vvv -p principal_from_krb5_keytab)) , which principal works with client machine; Now I can nfs mount with sec=krb5 ; Still some issues to solve, but it is going to work! :D
Thanks for help.
Mange hilsner Longina
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of steve Sent: 11. august 2014 19:37 To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] FW: NFS+KERB+SSSD Ubuntu 14.04
On Mon, 2014-08-11 at 16:26 +0000, Longina Przybyszewska wrote:
yeah, am getting blind, and got square eyes
Here is our nfs4 setup, also against AD: http://linuxcostablanca.blogspot.com.es/p/samba-4.html
There are lots of misinformed notes about nfs4. Early versions had to be exported from a fsuid 0 pseudo-root folder to which the actual exports were bind mounted. Recent versions should _not_ be so exported. You export them as normal folders as you always have done.
What do you have at /etc/exports and /etc/idmapd.conf Does the same configuration mount with kerberised nfs3?
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users@lists.fedorahosted.org
-
Longina Przybyszewska -
steve