[Samba] Samba and kerberized NFSv4

L.P.H. van Belle belle at bazuin.nl
Fri Dec 2 12:07:59 UTC 2016


Hai, 

Run this on client and server: 
getent hosts $(hostname) | awk '{print $1; exit}' | xargs getent hosts | awk '{print $2}' 

which should give you host.fqdn.tdd 
if not, your setup of wrong. 

Both client and server needs nfs/host.fqdn.tld 
And you MUST have a PTR records for client and server 

If you want a mount on boot, which i use. 
Try the idmap.conf change i mailed before. 

Root, administrator dont have any access to my user home folders, same as you want.

And after that, it works fine. At least for me, as of samba 4.1.x up to 4.5.1.  

Im running debian Jessie, with recompiled samba from stretch or experimental. 

With the windows user and domain manager, goto the computer object. 
Set view to advanced, and check the servicePrincipalName in the ad. 

About the : userPrincipalName 
I have none set in my AD only servicePrincipalName

And only if you use squid proxy, at least thats the first if encountert which needed and userPrincipalName also, but also only if you want kerberos based group auth on squid. 

I hope this helps out a bit more for you.

Good luck, you close to have this running.


Greetz, 

Louis


> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-bounces at lists.samba.org] Namens Matthias Kahle
> via samba
> Verzonden: vrijdag 2 december 2016 12:36
> Aan: samba at lists.samba.org
> Onderwerp: Re: [Samba] Samba and kerberized NFSv4
> 
> 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
> >
> 
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba




More information about the samba mailing list