[Samba] Samba and kerberized NFSv4

[marcel at linux-ng.de]

Am 2016-12-02 13:16, schrieb Rowland Penny via samba:
> On Fri, 02 Dec 2016 12:44:04 +0100
> marcel at linux-ng.de wrote:
> 
>> 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.
>> >
>> > Rowland
>> 
>> Hi 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
> 
> Yes, I only have Unix machines.
> 
> Yes, if I create a file in the mounted NFS share
> 
> rowland at devstation:~$ touch /home/SAMDOM/rowland/nfstest.txt
> 
> And then go to the share on the NFS server:
> 
> root at member1:~# ls -la /home/rowland/
> ........
> -rw-r--r--   1 SAMDOM\rowland SAMDOM\domain users    0 Dec  2 11:08
> nfstest.txt
> .......
> 
> I can open, read, write etc anything in my share
> 
>  Rowland


Hi Rowland,

thanks for your feedback.

I just re-created my keytabs without the NO_AUTH_DATA_REQUIRED flag
and NFS client / server now work.

However with a "real" MS Active Directory we had to set this bit to
get things working at all.
There seems to be some difference in handling this flag between the
samba and MS implementation.

Setting this bit in the samba DC results in the following error
messages (on the DC) when trying to access a file (via NFSv4):

[2016/12/02 17:08:08.870770,  3] 
../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
   Kerberos: TGS-REQ marcel at MYDOMAIN.DE [renewable, proxiable, 
forwardable]
[2016/12/02 17:08:08.875148,  3] 
../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
   Kerberos: Verify PAC failed for nfs/nfss.mydomain.de at MYDOMAIN.DE 
(marcel at MYDOMAIN.DE) from ipv4:XXX.XXX.XXX.XXX:38054 with <unknown 
error: 22>
[2016/12/02 17:08:08.875220,  3] 
../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
   Kerberos: Failed building TGS-REP to ipv4:XXX.XXX.XXX.XXX:38054


A discussion about a fix for that started years ago - but
ended without result:

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

Maybe someone is willing to pick it up this time ;-)


Bye,
     Marcel