[Samba] Samba and kerberized NFSv4

marcel at linux-ng.de marcel at linux-ng.de
Fri Dec 2 10:47:49 UTC 2016


Hi Matthias,

adding (or better replacing) the userPrincipalName attribute
with the nfs/* one, is exactly what you need to do.

For some reason the NFS client's request *only* matches
the userPrincipalName attribute, while all other services
I tried so far are fine when matching one of the values
in servicePrincipalName attribute.

NFS seems to be a very special kind of kerberos service
as it uses two different kinds of authentication:

First of all a host based authentication to authenticate
the mount itself, followed by the user's credentials that
are checked upon directory/file access.

In case you haven't found it yet: There's a nice tool
called msktutil, that will help when creating user/
servicePrincipalNames in Active Directory / Samba DC.

One other thing I found during my tries to get kerberized
NFSv4 working with my Samba DC: Some principals require
the NO_AUTH_DATA_REQUIRED flag to be set (--no-pac in msktutil),
otherwise tickets will not be accepted (not all of the
principals require this and I'm not sure wether it was the
client or the server who needed this...).

Motivated by your mail, I'm currently trying (once again) to
get NFSv4 working with Samba DC: but for now it seems, that
there's still a bug in the verify_pac() function - at least I
could not make it work without a patch I posted 5 years ago:

https://lists.samba.org/archive/samba-technical/2011-June/078193.html

Without the patch, mount works, but as soon as a user tries to
access a directory/file access is denied with an "unknown error 22".

If you get NFSv4 + Krb5 working without that patch/hack, please
let me now.

If I should succeed, I'll also post my complete findings :-)

Good luck,
     Marcel


Am 2016-12-02 11:05, schrieb Matthias Kahle via samba:
>> Does it work if you manually add userPrincipalName=CLIENT02.DOMAIN.TLD 
>> to your clients ldap entry and reexport the keytab?
> 
> I already thought about trying that. So by now, I tried tweaking the
> client's LDAP entry.
> 
> Adding
> 
>   userPrincipalName=CLIENT02.DOMAIN.TLD
> 
> does not succeeed, however, after reviewing the ldap filter once again, 
> I added
> 
>   userPrincipalName=nfs/client02.domain.tld at DOMAIN.TLD
> 
> to the workstation's account  and finally, the mount does not return
> an error anymore. Though I can't access anything on the mounted share
> but I guess that's OK for now, because the users' home directories
> hosted there must not be accessible to the root user at all.
> 
> However I don't expect that to be the right approach, not only because
> it requires a userPricipalName for a service but mainly because I even
> have to add the kerberos REALM ... or am I mistaken there? (please
> bear with me if that sounds stupid, I'm still somehow new to dealing
> with kerberos)
> 
> Regards,
> Mathias



More information about the samba mailing list