[Samba] NFS4 with samba4 AD for authentication

Gaiseric Vandal gaiseric.vandal at gmail.com
Tue Sep 23 06:54:08 MDT 2014


What is the client OS?

I have been implementing Kerberos with linux (Fedora Core 19) nfs 
clients, but a Oracle/Solaris Kerberos server (MIT not Heimdal) and 
Directory (LDAP) server.

For the client,  I created the following principals

     root/client.example.com
     host/client.example.com
     nfs/client.example.com


I then exported them to a keytab file to be used on the client ( 
/etc/krb5.keytab )

Verify with "klist -k -e"

# klist -k -e
Keytab name: WRFILE:/etc/krb5.keytab
KVNO Principal
---- 
--------------------------------------------------------------------------
    3 host/client.example.com at XYZ.EXAMPLE.COM (ArcFour with HMAC/md5)
    3 nfs/client.example.com at XYZ.EXAMPLE.COM (ArcFour with HMAC/md5)
    3 root/client.example.com at XYZ.EXAMPLE.COM (ArcFour with HMAC/md5)
#


(My DNS domain name is example.com, my kerberos realm is XYZ.EXAMPLE.COM.)


NFS is a little tricky because nfs and autofs clients are run as root.


Fedora 19 will  try any of the principals above (root, host, nfs) so you 
probably don't really need all 3.

I found specifying the correct encryption to be important.  When I 
create principals and keytab entries, several encryption options will be 
supported.    However, it looks  like , with NFS, the client and server 
won't negotiate the highest common protocol.    If the client supports 
RC4 and 3DES, and the server supports 3DES, the connection will fail  
even tho they have a common protocol.       Fedora 11 did not support 
RC4 or AES with NFS, so I would have to make sure I created the 
principals and keytabs to only use 3DES and DES.   Fedora 19 (and I 
think Fedora 14) support newer encryption.


On Fedora 19, the services don't start up in the correct order by 
default.    For testing you may want to manually restart nfs-idmap and 
nfs-secure services.


And make sure client and server have the same time (at least w/in a few 
minutes.)








On 09/23/14 08:12, Lars Hanke wrote:
> It's probably difting slightly off the topic, but I know that there 
> are some people listening here, who have  a decent expertise. I'm 
> trying to setup a file server (nfs4 at ad.domain) and mount from a client 
> (hunin at ad.domain) using the user database and especially Kerberos 
> provided by my AD (samba at ad.domain).
>
> It already works nicely, if I forget about krb5, i.e. idmapd is 
> working straight.
>
> Running gssd -vvv yields the following messages in /var/log/syslog:
>
> Sep 23 13:36:24 hunin rpc.gssd[15285]: dir_notify_handler: sig 37 si 
> 0xbfad367c data 0xbfad36fc
> Sep 23 13:36:24 hunin rpc.gssd[15285]: dir_notify_handler: sig 37 si 
> 0xbfad367c data 0xbfad36fc
> Sep 23 13:36:24 hunin rpc.gssd[15285]: dir_notify_handler: sig 37 si 
> 0xbfad367c data 0xbfad36fc
> Sep 23 13:36:24 hunin rpc.gssd[15285]: dir_notify_handler: sig 37 si 
> 0xbfad367c data 0xbfad36fc
> Sep 23 13:36:24 hunin rpc.gssd[15285]: dir_notify_handler: sig 37 si 
> 0xbfad367c data 0xbfad36fc
> Sep 23 13:36:24 hunin rpc.gssd[15285]: handling gssd upcall 
> (/var/lib/nfs/rpc_pipefs/nfs/clnte)
> Sep 23 13:36:24 hunin rpc.gssd[15285]: handle_gssd_upcall: 'mech=krb5 
> uid=0 enctypes=18,17,16,23,3,1,2 '
> Sep 23 13:36:24 hunin rpc.gssd[15285]: handling krb5 upcall 
> (/var/lib/nfs/rpc_pipefs/nfs/clnte)
> Sep 23 13:36:24 hunin rpc.gssd[15285]: process_krb5_upcall: service is 
> '<null>'
> Sep 23 13:36:24 hunin rpc.gssd[15285]: Full hostname for 
> 'nfs4.ad.microsult.de' is 'nfs4.ad.microsult.de'
> Sep 23 13:36:24 hunin rpc.gssd[15285]: Full hostname for 
> 'hunin.ad.microsult.de' is 'hunin.ad.microsult.de'
> Sep 23 13:36:24 hunin rpc.gssd[15285]: Success getting keytab entry 
> for 'HUNIN$@AD.MICROSULT.DE'
> Sep 23 13:36:24 hunin rpc.gssd[15285]: INFO: Credentials in CC 
> 'FILE:/tmp/krb5cc_machine_AD.MICROSULT.DE' are good until 1411507622
> Sep 23 13:36:24 hunin rpc.gssd[15285]: INFO: Credentials in CC 
> 'FILE:/tmp/krb5cc_machine_AD.MICROSULT.DE' are good until 1411507622
> Sep 23 13:36:24 hunin rpc.gssd[15285]: using 
> FILE:/tmp/krb5cc_machine_AD.MICROSULT.DE as credentials cache for 
> machine creds
> Sep 23 13:36:24 hunin rpc.gssd[15285]: using environment variable to 
> select krb5 ccache FILE:/tmp/krb5cc_machine_AD.MICROSULT.DE
> Sep 23 13:36:24 hunin rpc.gssd[15285]: creating context using fsuid 0 
> (save_uid 0)
> Sep 23 13:36:24 hunin rpc.gssd[15285]: creating tcp client for server 
> nfs4.ad.microsult.de
> Sep 23 13:36:24 hunin rpc.gssd[15285]: DEBUG: port already set to 2049
> Sep 23 13:36:24 hunin rpc.gssd[15285]: creating context with server 
> nfs at nfs4.ad.microsult.de
> Sep 23 13:36:24 hunin rpc.gssd[15285]: WARNING: Failed to create krb5 
> context for user with uid 0 for server nfs4.ad.microsult.de
> Sep 23 13:36:24 hunin rpc.gssd[15285]: WARNING: Failed to create 
> machine krb5 context with credentials cache 
> FILE:/tmp/krb5cc_machine_AD.MICROSULT.DE for server nfs4.ad.microsult.de
> Sep 23 13:36:24 hunin rpc.gssd[15285]: WARNING: Machine cache is 
> prematurely expired or corrupted trying to recreate cache for server 
> nfs4.ad.microsult.de
> Sep 23 13:36:24 hunin rpc.gssd[15285]: Full hostname for 
> 'nfs4.ad.microsult.de' is 'nfs4.ad.microsult.de'
> Sep 23 13:36:24 hunin rpc.gssd[15285]: Full hostname for 
> 'hunin.ad.microsult.de' is 'hunin.ad.microsult.de'
> Sep 23 13:36:24 hunin rpc.gssd[15285]: Success getting keytab entry 
> for 'HUNIN$@AD.MICROSULT.DE'
> Sep 23 13:36:24 hunin rpc.gssd[15285]: INFO: Credentials in CC 
> 'FILE:/tmp/krb5cc_machine_AD.MICROSULT.DE' are good until 1411507622
> Sep 23 13:36:24 hunin rpc.gssd[15285]: INFO: Credentials in CC 
> 'FILE:/tmp/krb5cc_machine_AD.MICROSULT.DE' are good until 1411507622
> Sep 23 13:36:24 hunin rpc.gssd[15285]: using 
> FILE:/tmp/krb5cc_machine_AD.MICROSULT.DE as credentials cache for 
> machine creds
> Sep 23 13:36:24 hunin rpc.gssd[15285]: using environment variable to 
> select krb5 ccache FILE:/tmp/krb5cc_machine_AD.MICROSULT.DE
> Sep 23 13:36:24 hunin rpc.gssd[15285]: creating context using fsuid 0 
> (save_uid 0)
> Sep 23 13:36:24 hunin rpc.gssd[15285]: creating tcp client for server 
> nfs4.ad.microsult.de
> Sep 23 13:36:24 hunin rpc.gssd[15285]: DEBUG: port already set to 2049
> Sep 23 13:36:24 hunin rpc.gssd[15285]: creating context with server 
> nfs at nfs4.ad.microsult.de
> Sep 23 13:36:24 hunin rpc.gssd[15285]: WARNING: Failed to create krb5 
> context for user with uid 0 for server nfs4.ad.microsult.de
> Sep 23 13:36:24 hunin rpc.gssd[15285]: WARNING: Failed to create 
> machine krb5 context with credentials cache 
> FILE:/tmp/krb5cc_machine_AD.MICROSULT.DE for server nfs4.ad.microsult.de
> Sep 23 13:36:24 hunin rpc.gssd[15285]: WARNING: Failed to create 
> machine krb5 context with any credentials cache for server 
> nfs4.ad.microsult.de
> Sep 23 13:36:24 hunin rpc.gssd[15285]: doing error downcall
> Sep 23 13:36:24 hunin rpc.gssd[15285]: dir_notify_handler: sig 37 si 
> 0xbfad319c data 0xbfad321c
> Sep 23 13:36:24 hunin rpc.gssd[15285]: dir_notify_handler: sig 37 si 
> 0xbfad319c data 0xbfad321c
> Sep 23 13:36:24 hunin rpc.gssd[15285]: dir_notify_handler: sig 37 si 
> 0xbfad319c data 0xbfad321c
> Sep 23 13:36:24 hunin rpc.gssd[15285]: dir_notify_handler: sig 37 si 
> 0xbfad319c data 0xbfad321c
> Sep 23 13:36:24 hunin rpc.gssd[15285]: dir_notify_handler: sig 37 si 
> 0xbfad319c data 0xbfad321c
> Sep 23 13:36:24 hunin rpc.gssd[15285]: dir_notify_handler: sig 37 si 
> 0xbfad319c data 0xbfad321c
> Sep 23 13:36:24 hunin rpc.gssd[15285]: dir_notify_handler: sig 37 si 
> 0xbfad319c data 0xbfad321c
> Sep 23 13:36:24 hunin rpc.gssd[15285]: destroying client 
> /var/lib/nfs/rpc_pipefs/nfs/clntf
> Sep 23 13:36:24 hunin rpc.gssd[15285]: destroying client 
> /var/lib/nfs/rpc_pipefs/nfs/clnte
>
> However Wireshark tells me that it looks for nfs/nfs4.ad.microsult.de. 
> This principal does not exist, but neither has to do anything with uid 
> 0. Furthermore, the man page to gssd stipulates that the machine 
> account would be just fine.
>
> I'm pretty confused, which principals I'd need and how to create them 
> in the samba AD.
>
> Any help appreciated,
>  - lars.



More information about the samba mailing list