[Samba] Samba and kerberized NFSv4

[Matthias Kahle]

Hi Marcel

I keep on digging and will post possible findings and/or solutions here.

Many thanks for your hints and help.

greetz,
Matthias


Am 02.12.2016 um 11:47 schrieb Marcel via samba:
> 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
>