[SSSD-users] FW: NFS+KERB+SSSD Ubuntu 14.04

Longina Przybyszewska longina at sdu.dk
Mon Aug 11 16:26:38 UTC 2014


yeah,  am getting blind, and got square eyes...sanitizing output.

My hosts _are_ in the same domain. 
L.
_______________________________________
From: sssd-users-bounces at lists.fedorahosted.org [sssd-users-bounces at lists.fedorahosted.org] on behalf of Longina Przybyszewska [longina at sdu.dk]
Sent: 11 August 2014 17:16
To: End-user discussions about the System Security Services Daemon      (sssd-users at 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 at 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 at jota:/# klist -ke
Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   4 host/jota.nat.c.sdu.dk at NAT.C.SDU.DK (des-cbc-crc)
   4 host/jota.nat.c.sdu.dk at NAT.C.SDU.DK (des-cbc-md5)
   4 host/jota.nat.c.sdu.dk at NAT.C.SDU.DK (aes128-cts-hmac-sha1-96)
   4 host/jota.nat.c.sdu.dk at NAT.C.SDU.DK (aes256-cts-hmac-sha1-96)
   4 host/jota.nat.c.sdu.dk at NAT.C.SDU.DK (arcfour-hmac)
   4 host/JOTA at NAT.C.SDU.DK (des-cbc-crc)
   4 host/JOTA at NAT.C.SDU.DK (des-cbc-md5)
   4 host/JOTA at NAT.C.SDU.DK (aes128-cts-hmac-sha1-96)
   4 host/JOTA at NAT.C.SDU.DK (aes256-cts-hmac-sha1-96)
   4 host/JOTA at 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 at NAT.C.SDU.DK (des-cbc-crc)
   4 nfs/jota.nat.c.sdu.dk at NAT.C.SDU.DK (des-cbc-md5)
   4 nfs/jota.nat.c.sdu.dk at NAT.C.SDU.DK (arcfour-hmac)
   4 nfs/jota.nat.c.sdu.dk at NAT.C.SDU.DK (aes256-cts-hmac-sha1-96)
   4 nfs/jota.nat.c.sdu.dk at 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
_______________________________________________
sssd-users mailing list
sssd-users at lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users


More information about the sssd-users mailing list