> 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
Am 02.12.2016 um 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 >Looking at the log file Dec 2 08:01:49 client02 rpc.gssd[10462]: No key table entry found forCLIENT02.DOMAIN.TLD$@DOMAIN.TLD while getting keytab entry for 'CLIENT02.DOMAIN.TLD$@DOMAIN.TLD' Dec 2 08:01:49 client02 rpc.gssd[10462]: No key table entry found forroot/client02.domain.tld at DOMAIN.TLD while getting keytab entry for 'root/client02.domain.tld at DOMAIN.TLD' Dec 2 08:01:49 client02 rpc.gssd[10462]: Success getting keytab entry for 'nfs/client02.domain.tld at DOMAIN.TLD' Dec 2 08:01:49 client02 rpc.gssd[10462]: WARNING: Client 'nfs/client02.domain.tld at DOMAIN.TLD' not found in Kerberos database while getting initial ticket for principal'nfs/client02.domain.tld at DOMAIN.TLD' using keytab'FILE:/etc/krb5.keytab' At first CLIENT02.DOMAIN.TLD$ is searched. I'd try to define that as the clients UPN, missed the $ earlier. Also this UPN must be added to the keytab file. This can be achived by samba-tool domain exportkeytab --principal=client02$ /etc/krb5.keytab Still abit of an hack but at least the UPN looks better.
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
On Fri, 2 Dec 2016 11:05:50 +0100 Matthias Kahle via samba <samba at lists.samba.org> wrote:> > 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 >I don't normally use NFS, but I did try it out some time ago and I didn't do it the way everybody else seems to be trying. I created a user just for nfs and gave that a SPN 'nfs/FQDN', where 'FQDN' is the fully qualified name of the computer that is running the NFS server. This works for me, I just tried it again, mounting nfs shares from a DC on a domain member. Rowland
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 >
Am 2016-12-02 12:12, schrieb Rowland Penny via samba:> On Fri, 2 Dec 2016 11:05:50 +0100 > Matthias Kahle via samba <samba at lists.samba.org> wrote: > >> > 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 >> > > I don't normally use NFS, but I did try it out some time ago and I > didn't do it the way everybody else seems to be trying. > I created a user just for nfs and gave that a SPN 'nfs/FQDN', where > 'FQDN' is the fully qualified name of the computer that is running the > NFS server. > > This works for me, I just tried it again, mounting nfs shares from a DC > on a domain member. > > RowlandHi Rowland, I just wanted to make sure: Your DCs are Samba based? After mounting the nfs share, were you able to access files? Bye, Marcel
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