I want to ask a question about nfs4 keytabs and Samba 4. I've tried
asking here, on the Samba 4 list and on the openSUSE list (which is my
Linux distribution) but they refer me to an nfs list. I see that this
list is only for nfs devs.
I don't want to waste your time here but my question is just this:
My nfs4 server has a service principal nfs/server.domain.name
I already use nfs4 to serve my Linux clients. I'm going to kerberize it.
My clients already have machine and host principals. What else do they need?
1. nfs/client.domain.name
2. nfs/server.domain/name
3. neither
4. both
The Google doco is contradictory and confusing to say the least. If you
can't help, could you point me in the right direction?
Thanks so much fr your time,
Steve
> Thanks, the problem isn't getting NFS with Kerberos to work in general, it's
> with AD as the KDC. It seems that NFS still only accepts DES encrypted
> Kerberos tickets, and these are specifically disabled in Windows Server 2008
> R2.
I've recently managed to get a Linux Kerberized NFS server working
using an Active Directory 2008 R2 domain controller as a KDC (using
arcfour-hmac and aes256-cts-hmac-sha1-96).
It's reasonably fiddly and took quite a lot of tweaking to get right.
A short summary of the AD specific side of our configuration:
For hosts with Samba 3. We join them to the domain with 'net ads join' and
create NFS principals with 'net ads keytab'.
For hosts without Samba (the vast majority of hosts). We use ksetpw (an old Solaris utility to
generate AES/arcfour principals). I believe that Microsoft has a similar
utility called ktpass.exe but I've never tested it.
I'm happy to provide more details of the domain joining process offlist or summarise in another
email if there is interest.
In the computer Active Directory account we set the :
UserPrincpalName: host/fqdn@DNS_DOMAIN
ServicePrincipalName: host/fqdn and nfs/fqdn
DNSDomainName: fqdn
MSDS-SupportedEncryptionTypes: 0x1C
One caveat. I've observed the following behaviour on RHEL5 and RHEL6 (it may
have changed):
In AD (as far as I'm aware) you can only obtain a TGT from a
principal matching the UserPrincpalName of the account. On startup rpc.gssd
obtains a TGT. If you've generated both 'nfs/*' and 'host/*'
principals in your keytab rpc.gssd will prefer the nfs principal.
This won't work if your UserPrincipalName in AD is 'host/*'. My workaround in the
past has been to change the search order in the nfs-utils source code (putting the
host principal first). Using a UPN of nfs/fqdn@DNS_DOMAIN may also work.
One issue that caused me difficulty was configuring the Kerberized NFS
server on Linux. Specifically - clients could mount the filesystem
without issue but when a user attempted to access the mount they got
'permission denied'.
Looking at the NFS requests on the wire I noticed that the GSS tokens
were around 2500 bytes in size. Further research indicated that this is the
result of Microsoft adding a 'Privilege Attribute Certificate' to service
tickets.
Setting the UserAccountControl parameter in AD on the NFS server to
'0x2000000' (NO_AUTH_DATA_REQUIRED) reduced the size of this token to
about 500 bytes and resolved the issue.
Our NFS clients are mostly RHEL6 and RHEL5 with a few Gentoo boxes running
nfs-utils 1.2.5 and kernel 3.2.1 . All seem to work fine with the above configuration.
On the server side we've tested RHEL6 and Gentoo.
Hopefully that is of some help.
I'm surprised by the lack of documentation available on using Kerberised NFS with AD. I
would have thought that it would be a fairly common configuration?
Since it's taken me a while to put the pieces together I'll try and come up with some more
comprehensive documentation in the near future.
Cheers
Don
On Thu, Feb 2, 2012 at 12:33 PM, steve <[email protected]> wrote:
> On 02/02/12 11:58, Tigran Mkrtchyan wrote:
>>
>> Hi Steve,
>>
>>>
>>> I already use nfs4 to serve my Linux clients. I'm going to kerberize it.
>>> My
>>> clients already have machine and host principals. What else do they need?
>>>
>>> 1. nfs/client.domain.name
>>> 2. nfs/server.domain/name
>>> 3. neither
>>> 4. both
>>>
>>
>> We run kerberized NFS.
>>
>> our keytab contains:
>>
>> on server;
>> nfs/server.domain
>>
>> on client:
>> nfs/client.domain
>>
>> and, of course, you need a consistent idmap configuration.
>>
>> Tigran.
>>
> Hi Tigran
>
> That's what we have on our test lan at the moment. I can understand that the
> server would need the service principal:
> nfs/server.domain
> but not the client, as it's not offering any kerberized service.
The mount step happens on behalf of host as there are no user requests yet.
Client host credentials are used at that time.
>
> As an experiment, I removed the nfs/client.domain from a client keytab,
> rebooted and remounted the share. We could still access the kerberized nfs
> share. Maybe there were still some tickets left somewhere? That has me
> really confused.
Huh! did you enforce kerberos in /etc/exports?
Tigran.
>
> And yes, we found out very early on that idmapd had to be running at both
> ends.
>
> Thanks for the reply. You've got me thinking.
> Steve
Liam Gretton wrote:
On 05/02/2012 14:16, Jim Rees wrote:
>There is a a NFS wiki, and it does have kerberos setup instructions:
>http://wiki.linux-nfs.org/wiki/index.php/Enduser_doc_kerberos
>
>The wiki has mostly been used by developers for developer info but it might
>be a good thing to use it for more general info too.
Thanks, the problem isn't getting NFS with Kerberos to work in
general, it's with AD as the KDC. It seems that NFS still only
accepts DES encrypted Kerberos tickets, and these are specifically
disabled in Windows Server 2008 R2.
Wasn't that fixed recently?
I have a related question, and like the OP I was reluctant to ask here
as it's not a dev question, but I can't find any other suitable forum.
Has ANYBODY got kerberised NFS working where the KDC is Active Directory
on a Windows 2008 R2 system? With 2008 R2, DES encryption for Kerberos
is no longer enabled.
Our AD admins are understandably not keen to go against the recommended
behaviour and enable DES just for this service (it needs to be enabled
globally across the domain).
I can't find any documentation about Kerberised NFS that looks more
recent than about 2006. That coupled with what I can see in the sources
suggest that there's little development in this area, so I suspect the
answer is that nobody has managed what I'm trying to do.
--
Liam Gretton [email protected]
HPC Architect http://www.le.ac.uk/its/
IT Services Tel: +44 (0)116 2522254
University Of Leicester, University Road
Leicestershire LE1 7RH, United Kingdom
There is a a NFS wiki, and it does have kerberos setup instructions:
http://wiki.linux-nfs.org/wiki/index.php/Enduser_doc_kerberos
The wiki has mostly been used by developers for developer info but it might
be a good thing to use it for more general info too.
On 02/02/2012 02:05 PM, Tigran Mkrtchyan wrote:
> On Thu, Feb 2, 2012 at 12:33 PM, steve<[email protected]> wrote:
>> On 02/02/12 11:58, Tigran Mkrtchyan wrote:
>>> Hi Steve,
>>>
>>>> I already use nfs4 to serve my Linux clients. I'm going to kerberize it.
>>>> My
>>>> clients already have machine and host principals. What else do they need?
>>>>
>>>> 1. nfs/client.domain.name
>>>> 2. nfs/server.domain/name
>>>> 3. neither
>>>> 4. both
>>>>
>>> We run kerberized NFS.
>>>
>>> our keytab contains:
>>>
>>> on server;
>>> nfs/server.domain
>>>
>>> on client:
>>> nfs/client.domain
>>>
>>> and, of course, you need a consistent idmap configuration.
>>>
>>> Tigran.
>>>
>> Hi Tigran
>>
>> That's what we have on our test lan at the moment. I can understand that the
>> server would need the service principal:
>> nfs/server.domain
>> but not the client, as it's not offering any kerberized service.
> The mount step happens on behalf of host as there are no user requests yet.
> Client host credentials are used at that time.
>
>> As an experiment, I removed the nfs/client.domain from a client keytab,
>> rebooted and remounted the share. We could still access the kerberized nfs
>> share. Maybe there were still some tickets left somewhere? That has me
>> really confused.
> Huh! did you enforce kerberos in /etc/exports?
>
Yes. /etc/exports exports as gss/krb5
I made a screenshot:
http://3.bp.blogspot.com/-g40b11Ys_DA/TypYtlO-ixI/AAAAAAAAAIc/cZdeRhnVuY4/s1600/s4all.png
That's why I'm confused.
Steve
On 02/03/2012 06:22 PM, steve wrote:
> On 02/02/2012 07:57 PM, Tigran Mkrtchyan wrote:
>> On Thu, Feb 2, 2012 at 3:56 PM, steve<[email protected]> wrote:
>>> On 02/02/12 14:29, steve wrote:
>>>> On 02/02/2012 02:05 PM, Tigran Mkrtchyan wrote:
>>>>> On Thu, Feb 2, 2012 at 12:33 PM, steve<[email protected]> wrote:
>>>>>> On 02/02/12 11:58, Tigran Mkrtchyan wrote:
>>>>>>> Hi Steve,
>>>>>>>
>>>>>>>> I already use nfs4 to serve my Linux clients. I'm going to
>>>>>>>> kerberize
>>>>>>>> it.
>>>>>>>> My
>>>>>>>> clients already have machine and host principals. What else do
>>>>>>>> they
>>>>>>>> need?
>>>>>>>>
>>>>>>>> 1. nfs/client.domain.name
>>>>>>>> 2. nfs/server.domain/name
>>>>>>>> 3. neither
>>>>>>>> 4. both
>>>>>>>>
>>>>>>> We run kerberized NFS.
>>>>>>>
>>>>>>> our keytab contains:
>>>>>>>
>>>>>>> on server;
>>>>>>> nfs/server.domain
>>>>>>>
>>>>>>> on client:
>>>>>>> nfs/client.domain
>>>>>>>
>>>>>>> and, of course, you need a consistent idmap configuration.
>>>>>>>
>>>>>>> Tigran.
>>>>>>>
>>>>>> Hi Tigran
>>>>>>
>>>>>> That's what we have on our test lan at the moment. I can
>>>>>> understand that
>>>>>> the
>>>>>> server would need the service principal:
>>>>>> nfs/server.domain
>>>>>> but not the client, as it's not offering any kerberized service.
>>>>> The mount step happens on behalf of host as there are no user
>>>>> requests
>>>>> yet.
>>>>> Client host credentials are used at that time.
>>>>>
>>>>>> As an experiment, I removed the nfs/client.domain from a client
>>>>>> keytab,
>>>>>> rebooted and remounted the share. We could still access the
>>>>>> kerberized
>>>>>> nfs
>>>>>> share. Maybe there were still some tickets left somewhere? That
>>>>>> has me
>>>>>> really confused.
>>>>> Huh! did you enforce kerberos in /etc/exports?
>>>>>
>>>> Yes. /etc/exports exports as gss/krb5
>>>> I made a screenshot:
>>>>
>>>>
>>>> http://3.bp.blogspot.com/-g40b11Ys_DA/TypYtlO-ixI/AAAAAAAAAIc/cZdeRhnVuY4/s1600/s4all.png
>>>>
>>>>
>>>> That's why I'm confused.
>>>> Steve
>>>
>>> Digging a bit further, here is the output of mount on the client:
>>> http://dl.dropbox.com/u/45150875/krb5testnfs.png
>>>
>>> And this appears immediately after the mount:
>>> http://dl.dropbox.com/u/45150875/krb5nfstmp.png
>>>
>>> Most of the documentation tells you to stick nfs into the client
>>> keytab as
>>> well as the server keytab, but here, I only have the principal on the
>>> server.
>>>
>>> What am I missing?
>> I think client simply falls back to 'host' if nfs entry is not
>> available.
>>
>> Tigran.
>
Yep. You're right. And not just host. They changed it to look for other
keys too:
http://linux.die.net/man/8/rpc.gssd
So in my case that's why I see HOSTNAME$@REALM during the nfs mount.
Thanks so much for your time.
Steve
On 04/02/12 21:50, Liam Gretton wrote:
> I have a related question, and like the OP I was reluctant to ask here
> as it's not a dev question, but I can't find any other suitable forum.
>
> Has ANYBODY got kerberised NFS working where the KDC is Active
> Directory on a Windows 2008 R2 system? With 2008 R2, DES encryption
> for Kerberos is no longer enabled.
>
> Our AD admins are understandably not keen to go against the
> recommended behaviour and enable DES just for this service (it needs
> to be enabled globally across the domain).
>
> I can't find any documentation about Kerberised NFS that looks more
> recent than about 2006. That coupled with what I can see in the
> sources suggest that there's little development in this area, so I
> suspect the answer is that nobody has managed what I'm trying to do.
>
Hi Liam
I am the OP. We really do need some down to earth and up to date info on
NFS4. More to the point, it needs to be all in one place, rather than
having snippets all around the Internet. I'm not a tecchie but maybe I
could put together a readable howto if there was enough demand.
We have kerberized nfs4 working against Samba 4. There seem to be
different flavours of des. The Samba 4 Kerberos produced these server
keys for our test domain:
1 nfs/[email protected] (des-cbc-crc)
1 nfs/[email protected] (des-cbc-md5)
1 nfs/[email protected] (arcfour-hmac)
We put together a howto which includes the nfs4 stuff here:
http://linuxcostablanca.blogspot.com/p/samba-4.html
HTH a little
Cheers,
Steve
On 02/09/2012 07:57 PM, Don Riden wrote:
>
>
>> Thanks, the problem isn't getting NFS with Kerberos to work in
>> general, it's with AD as the KDC. It seems that NFS still only
>> accepts DES encrypted Kerberos tickets, and these are specifically
>> disabled in Windows Server 2008 R2.
>
> I've recently managed to get a Linux Kerberized NFS server working
> using an Active Directory 2008 R2 domain controller as a KDC (using
> arcfour-hmac and aes256-cts-hmac-sha1-96).
>
> It's reasonably fiddly and took quite a lot of tweaking to get right.
>
> A short summary of the AD specific side of our configuration:
>
> For hosts with Samba 3. We join them to the domain with 'net ads join'
> and
> create NFS principals with 'net ads keytab'.
>
> For hosts without Samba (the vast majority of hosts). We use ksetpw
> (an old Solaris utility to
> generate AES/arcfour principals). I believe that Microsoft has a similar
> utility called ktpass.exe but I've never tested it.
>
> I'm happy to provide more details of the domain joining process
> offlist or summarise in another
> email if there is interest.
>
> In the computer Active Directory account we set the :
>
> UserPrincpalName: host/fqdn@DNS_DOMAIN
> ServicePrincipalName: host/fqdn and nfs/fqdn
> DNSDomainName: fqdn
> MSDS-SupportedEncryptionTypes: 0x1C
>
> One caveat. I've observed the following behaviour on RHEL5 and RHEL6
> (it may
> have changed):
>
> In AD (as far as I'm aware) you can only obtain a TGT from a principal
> matching the UserPrincpalName of the account. On startup rpc.gssd
> obtains a TGT. If you've generated both 'nfs/*' and 'host/*'
> principals in your keytab rpc.gssd will prefer the nfs principal.
> This won't work if your UserPrincipalName in AD is 'host/*'. My
> workaround in the
> past has been to change the search order in the nfs-utils source code
> (putting the host principal first). Using a UPN of nfs/fqdn@DNS_DOMAIN
> may also work.
>
> One issue that caused me difficulty was configuring the Kerberized NFS
> server on Linux. Specifically - clients could mount the filesystem
> without issue but when a user attempted to access the mount they got
> 'permission denied'.
>
> Looking at the NFS requests on the wire I noticed that the GSS tokens
> were around 2500 bytes in size. Further research indicated that this
> is the
> result of Microsoft adding a 'Privilege Attribute Certificate' to service
> tickets.
>
> Setting the UserAccountControl parameter in AD on the NFS server to
> '0x2000000' (NO_AUTH_DATA_REQUIRED) reduced the size of this token to
> about 500 bytes and resolved the issue.
>
> Our NFS clients are mostly RHEL6 and RHEL5 with a few Gentoo boxes
> running
> nfs-utils 1.2.5 and kernel 3.2.1 . All seem to work fine with the
> above configuration.
>
> On the server side we've tested RHEL6 and Gentoo.
>
> Hopefully that is of some help.
>
> I'm surprised by the lack of documentation available on using
> Kerberised NFS with AD. I would have thought that it would be a fairly
> common configuration?
>
> Since it's taken me a while to put the pieces together I'll try and
> come up with some more
> comprehensive documentation in the near future.
>
> Cheers
>
>
> Don
Hi
If it's a recent Linux distro you should be able to save a bit of
fiddling because the nfs/client.domain principal is not needed. net ads
keytab create makes the machine and host principals for you, and you're
done:
http://linux.die.net/man/8/rpc.gssd
Working fine here with Samba 4 KDC and nfs4 for openSUSE Linux clients
using acrfour-hmac.
HTH
Cheers,
Steve
On 02/02/2012 07:57 PM, Tigran Mkrtchyan wrote:
> On Thu, Feb 2, 2012 at 3:56 PM, steve<[email protected]> wrote:
>> On 02/02/12 14:29, steve wrote:
>>> On 02/02/2012 02:05 PM, Tigran Mkrtchyan wrote:
>>>> On Thu, Feb 2, 2012 at 12:33 PM, steve<[email protected]> wrote:
>>>>> On 02/02/12 11:58, Tigran Mkrtchyan wrote:
>>>>>> Hi Steve,
>>>>>>
>>>>>>> I already use nfs4 to serve my Linux clients. I'm going to kerberize
>>>>>>> it.
>>>>>>> My
>>>>>>> clients already have machine and host principals. What else do they
>>>>>>> need?
>>>>>>>
>>>>>>> 1. nfs/client.domain.name
>>>>>>> 2. nfs/server.domain/name
>>>>>>> 3. neither
>>>>>>> 4. both
>>>>>>>
>>>>>> We run kerberized NFS.
>>>>>>
>>>>>> our keytab contains:
>>>>>>
>>>>>> on server;
>>>>>> nfs/server.domain
>>>>>>
>>>>>> on client:
>>>>>> nfs/client.domain
>>>>>>
>>>>>> and, of course, you need a consistent idmap configuration.
>>>>>>
>>>>>> Tigran.
>>>>>>
>>>>> Hi Tigran
>>>>>
>>>>> That's what we have on our test lan at the moment. I can understand that
>>>>> the
>>>>> server would need the service principal:
>>>>> nfs/server.domain
>>>>> but not the client, as it's not offering any kerberized service.
>>>> The mount step happens on behalf of host as there are no user requests
>>>> yet.
>>>> Client host credentials are used at that time.
>>>>
>>>>> As an experiment, I removed the nfs/client.domain from a client keytab,
>>>>> rebooted and remounted the share. We could still access the kerberized
>>>>> nfs
>>>>> share. Maybe there were still some tickets left somewhere? That has me
>>>>> really confused.
>>>> Huh! did you enforce kerberos in /etc/exports?
>>>>
>>> Yes. /etc/exports exports as gss/krb5
>>> I made a screenshot:
>>>
>>>
>>> http://3.bp.blogspot.com/-g40b11Ys_DA/TypYtlO-ixI/AAAAAAAAAIc/cZdeRhnVuY4/s1600/s4all.png
>>>
>>> That's why I'm confused.
>>> Steve
>>
>> Digging a bit further, here is the output of mount on the client:
>> http://dl.dropbox.com/u/45150875/krb5testnfs.png
>>
>> And this appears immediately after the mount:
>> http://dl.dropbox.com/u/45150875/krb5nfstmp.png
>>
>> Most of the documentation tells you to stick nfs into the client keytab as
>> well as the server keytab, but here, I only have the principal on the
>> server.
>>
>> What am I missing?
> I think client simply falls back to 'host' if nfs entry is not available.
>
> Tigran.
I completely cleared /tmp and stuck nfs/client back in the client keytab
to see if it made any difference. It still wasn't used. I got exactly
the same tickets as above. It looks as though this is a recent change to
nfs-utils. I think this post explains why I see nfs being authenticated
not by the /nfs/client nor /host/client but by the client$ principal.
https://fedorahosted.org/pipermail/sssd-devel/2010-August/004332.html
I'm new to all this so nothing is certain for me the moment!
Does this make sense?
Cheers,
Steve
On Fri, Feb 10, 2012 at 09:19:38AM +0100, steve wrote:
>
> >>
> >>I'm happy to provide more details of the domain joining process
> >>offlist or summarise in another
> >>email if there is interest.
> >>
> >>
> >>
> >>I'm surprised by the lack of documentation available on using
> >>Kerberised NFS with AD. I would have thought that it would be a
> >>fairly common configuration?
> >
> Hi
> This stuff really does need documenting. I've put together a rough
> guide of most of the common misunderstandings here:
> http://linuxcostablanca.blogspot.com/2012/02/nfsv4-myths-and-legends.html
Could you get some of this material into the linux-nfs wiki?
The NFS w/ AD stuff, for example, would probably be worth a page of its
own and a top-level link under "Documentation" (and the link to Mike
Eisler's blog entry could be moved to the page, if it still looks like
it's current).
--b.
On 02/02/12 14:29, steve wrote:
> On 02/02/2012 02:05 PM, Tigran Mkrtchyan wrote:
>> On Thu, Feb 2, 2012 at 12:33 PM, steve<[email protected]> wrote:
>>> On 02/02/12 11:58, Tigran Mkrtchyan wrote:
>>>> Hi Steve,
>>>>
>>>>> I already use nfs4 to serve my Linux clients. I'm going to
>>>>> kerberize it.
>>>>> My
>>>>> clients already have machine and host principals. What else do
>>>>> they need?
>>>>>
>>>>> 1. nfs/client.domain.name
>>>>> 2. nfs/server.domain/name
>>>>> 3. neither
>>>>> 4. both
>>>>>
>>>> We run kerberized NFS.
>>>>
>>>> our keytab contains:
>>>>
>>>> on server;
>>>> nfs/server.domain
>>>>
>>>> on client:
>>>> nfs/client.domain
>>>>
>>>> and, of course, you need a consistent idmap configuration.
>>>>
>>>> Tigran.
>>>>
>>> Hi Tigran
>>>
>>> That's what we have on our test lan at the moment. I can understand
>>> that the
>>> server would need the service principal:
>>> nfs/server.domain
>>> but not the client, as it's not offering any kerberized service.
>> The mount step happens on behalf of host as there are no user
>> requests yet.
>> Client host credentials are used at that time.
>>
>>> As an experiment, I removed the nfs/client.domain from a client keytab,
>>> rebooted and remounted the share. We could still access the
>>> kerberized nfs
>>> share. Maybe there were still some tickets left somewhere? That has me
>>> really confused.
>> Huh! did you enforce kerberos in /etc/exports?
>>
> Yes. /etc/exports exports as gss/krb5
> I made a screenshot:
>
> http://3.bp.blogspot.com/-g40b11Ys_DA/TypYtlO-ixI/AAAAAAAAAIc/cZdeRhnVuY4/s1600/s4all.png
>
>
> That's why I'm confused.
> Steve
Digging a bit further, here is the output of mount on the client:
http://dl.dropbox.com/u/45150875/krb5testnfs.png
And this appears immediately after the mount:
http://dl.dropbox.com/u/45150875/krb5nfstmp.png
Most of the documentation tells you to stick nfs into the client keytab
as well as the server keytab, but here, I only have the principal on the
server.
What am I missing?
Thanks,
Steve
Hi Steve,
On Thu, Feb 2, 2012 at 7:39 AM, steve <[email protected]> wrote:
> I want to ask a question about nfs4 keytabs and Samba 4. I've tried asking
> here, on the Samba 4 list and on the openSUSE list (which is my Linux
> distribution) but they refer me to an nfs list. I see that this list is only
> for nfs devs.
>
> I don't want to waste your time here but my question is just this:
>
> My nfs4 server has a service principal nfs/server.domain.name
>
> I already use nfs4 to serve my Linux clients. I'm going to kerberize it. My
> clients already have machine and host principals. What else do they need?
>
> 1. nfs/client.domain.name
> 2. nfs/server.domain/name
> 3. neither
> 4. both
>
We run kerberized NFS.
our keytab contains:
on server;
nfs/server.domain
on client:
nfs/client.domain
and, of course, you need a consistent idmap configuration.
Tigran.
> The Google doco is contradictory and confusing to say the least. If you
> can't help, could you point me in the right direction?
>
> Thanks so much fr your time,
> Steve
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On 06/02/12 17:39, J. Bruce Fields wrote:
> On Sun, Feb 05, 2012 at 12:37:28PM -0500, Jim Rees wrote:
>> Liam Gretton wrote:
>>
>> On 05/02/2012 14:16, Jim Rees wrote:
>> >There is a a NFS wiki, and it does have kerberos setup instructions:
>> >http://wiki.linux-nfs.org/wiki/index.php/Enduser_doc_kerberos
>> >
>> >The wiki has mostly been used by developers for developer info but it might
>> >be a good thing to use it for more general info too.
>>
>> Thanks, the problem isn't getting NFS with Kerberos to work in
>> general, it's with AD as the KDC. It seems that NFS still only
>> accepts DES encrypted Kerberos tickets, and these are specifically
>> disabled in Windows Server 2008 R2.
>>
>> Wasn't that fixed recently?
> Yes, it supports some AES-based enctypes now, for example. I wouldn't
> know a better source of the details than
>
> git log net/sunrpc/auth_gss/gss_krb5_*
>
> If someone wanted to summarize the situation for the wiki, go for it.
Hi
nfs with arcfour seems OK here with Samba 4. I don't think it's the
default for AD but your windows admins may be happier with it. I think
his is the relevant bit:
Kerberos: ENC-TS Pre-authentication succeeded -- [email protected] using
arcfour-hmac-md5
Kerberos: AS-REQ authtime: 2012-02-06T19:44:47 starttime: unset endtime:
2012-02-07T05:44:47 renew till: 2012-02-07T19:44:47
Kerberos: Client supported enctypes: aes256-cts-hmac-sha1-96,
aes128-cts-hmac-sha1-96, des3-cbc-sha1, arcfour-hmac-md5, des-cbc-crc,
des-cbc-md5, des-cbc-md4, using arcfour-hmac-md5/arcfour-hmac-md5
Kerberos: Requested flags: renewable-ok
Kerberos: TGS-REQ [email protected] from ipv4:192.168.1.3:45421 for
nfs/[email protected] [canonicalize, renewable]
Kerberos: TGS-REQ authtime: 2012-02-06T19:44:47 starttime:
2012-02-06T19:44:47 endtime: 2012-02-07T05:44:47 renew till: 20
HTH
Steve
On 02/02/12 11:58, Tigran Mkrtchyan wrote:
> Hi Steve,
>
>>
>> I already use nfs4 to serve my Linux clients. I'm going to kerberize it. My
>> clients already have machine and host principals. What else do they need?
>>
>> 1. nfs/client.domain.name
>> 2. nfs/server.domain/name
>> 3. neither
>> 4. both
>>
>
> We run kerberized NFS.
>
> our keytab contains:
>
> on server;
> nfs/server.domain
>
> on client:
> nfs/client.domain
>
> and, of course, you need a consistent idmap configuration.
>
> Tigran.
>
Hi Tigran
That's what we have on our test lan at the moment. I can understand that
the server would need the service principal:
nfs/server.domain
but not the client, as it's not offering any kerberized service.
As an experiment, I removed the nfs/client.domain from a client keytab,
rebooted and remounted the share. We could still access the kerberized
nfs share. Maybe there were still some tickets left somewhere? That has
me really confused.
And yes, we found out very early on that idmapd had to be running at
both ends.
Thanks for the reply. You've got me thinking.
Steve
On Sun, Feb 05, 2012 at 12:37:28PM -0500, Jim Rees wrote:
> Liam Gretton wrote:
>
> On 05/02/2012 14:16, Jim Rees wrote:
> >There is a a NFS wiki, and it does have kerberos setup instructions:
> >http://wiki.linux-nfs.org/wiki/index.php/Enduser_doc_kerberos
> >
> >The wiki has mostly been used by developers for developer info but it might
> >be a good thing to use it for more general info too.
>
> Thanks, the problem isn't getting NFS with Kerberos to work in
> general, it's with AD as the KDC. It seems that NFS still only
> accepts DES encrypted Kerberos tickets, and these are specifically
> disabled in Windows Server 2008 R2.
>
> Wasn't that fixed recently?
Yes, it supports some AES-based enctypes now, for example. I wouldn't
know a better source of the details than
git log net/sunrpc/auth_gss/gss_krb5_*
If someone wanted to summarize the situation for the wiki, go for it.
--b.
On Thu, Feb 2, 2012 at 3:56 PM, steve <[email protected]> wrote:
> On 02/02/12 14:29, steve wrote:
>>
>> On 02/02/2012 02:05 PM, Tigran Mkrtchyan wrote:
>>>
>>> On Thu, Feb 2, 2012 at 12:33 PM, steve<[email protected]> wrote:
>>>>
>>>> On 02/02/12 11:58, Tigran Mkrtchyan wrote:
>>>>>
>>>>> Hi Steve,
>>>>>
>>>>>> I already use nfs4 to serve my Linux clients. I'm going to kerberize
>>>>>> it.
>>>>>> My
>>>>>> clients already have machine and host principals. What else do they
>>>>>> need?
>>>>>>
>>>>>> 1. nfs/client.domain.name
>>>>>> 2. nfs/server.domain/name
>>>>>> 3. neither
>>>>>> 4. both
>>>>>>
>>>>> We run kerberized NFS.
>>>>>
>>>>> our keytab contains:
>>>>>
>>>>> on server;
>>>>> nfs/server.domain
>>>>>
>>>>> on client:
>>>>> nfs/client.domain
>>>>>
>>>>> and, of course, you need a consistent idmap configuration.
>>>>>
>>>>> Tigran.
>>>>>
>>>> Hi Tigran
>>>>
>>>> That's what we have on our test lan at the moment. I can understand that
>>>> the
>>>> server would need the service principal:
>>>> nfs/server.domain
>>>> but not the client, as it's not offering any kerberized service.
>>>
>>> The mount step happens on behalf of host as there are no user requests
>>> yet.
>>> Client host credentials are used at that time.
>>>
>>>> As an experiment, I removed the nfs/client.domain from a client keytab,
>>>> rebooted and remounted the share. We could still access the kerberized
>>>> nfs
>>>> share. Maybe there were still some tickets left somewhere? That has me
>>>> really confused.
>>>
>>> Huh! did you enforce kerberos in /etc/exports?
>>>
>> Yes. /etc/exports exports as gss/krb5
>> I made a screenshot:
>>
>>
>> http://3.bp.blogspot.com/-g40b11Ys_DA/TypYtlO-ixI/AAAAAAAAAIc/cZdeRhnVuY4/s1600/s4all.png
>>
>> That's why I'm confused.
>> Steve
>
>
> Digging a bit further, here is the output of mount on the client:
> http://dl.dropbox.com/u/45150875/krb5testnfs.png
>
> And this appears immediately after the mount:
> http://dl.dropbox.com/u/45150875/krb5nfstmp.png
>
> Most of the documentation tells you to stick nfs into the client keytab as
> well as the server keytab, but here, I only have the principal on the
> server.
>
> What am I missing?
I think client simply falls back to 'host' if nfs entry is not available.
Tigran.
> Thanks,
> Steve
>
On 02/10/2012 08:14 PM, J. Bruce Fields wrote:
> On Fri, Feb 10, 2012 at 08:13:16PM +0100, steve wrote:
>> On 02/10/2012 07:40 PM, J. Bruce Fields wrote:
>>> On Fri, Feb 10, 2012 at 09:19:38AM +0100, steve wrote:
>>>>>> I'm happy to provide more details of the domain joining process
>>>>>> offlist or summarise in another
>>>>>> email if there is interest.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I'm surprised by the lack of documentation available on using
>>>>>> Kerberised NFS with AD. I would have thought that it would be a
>>>>>> fairly common configuration?
>>>> Hi
>>>> This stuff really does need documenting. I've put together a rough
>>>> guide of most of the common misunderstandings here:
>>>> http://linuxcostablanca.blogspot.com/2012/02/nfsv4-myths-and-legends.html
>>> Could you get some of this material into the linux-nfs wiki?
>>>
>>> The NFS w/ AD stuff, for example, would probably be worth a page of its
>>> own and a top-level link under "Documentation" (and the link to Mike
>>> Eisler's blog entry could be moved to the page, if it still looks like
>>> it's current).
>>>
>>> --b.
>> Unfortunately, I am unable to write technical English in the style
>> that is required by the wiki.
> Just say it however it makes sense to you, ping me, and I can do any
> wordsmithing if it seems necessary.
>
> --b.
>
>> I am however happy for the link to be
>> placed there. As there is no user nfs mailing list I'm also happy
>> for folk to sign up to the article and use _it_ as a mailing list.
OK. I've requested a login. Linux has never been too good with
documentation. At nfs level, unless you are capable of reading the code,
you are stuck with misinformation. What I feel is that admins are stuck
in the middle. It's a dilemma. You don't want to want to have to burden
the devs with what to them is trivia. As admin, you have your own
trivia: 'I saved it in My Documents but now only Sharon can open it'.
You also need to be able to move forward without guessing: 'What's the
official syntax for /etc/exports with krb5'. Your users get their
answers. From you. Where are we expected to get our answers from!
Cheers,
Steve
>>
>> I'm happy to provide more details of the domain joining process
>> offlist or summarise in another
>> email if there is interest.
>>
>>
>>
>> I'm surprised by the lack of documentation available on using
>> Kerberised NFS with AD. I would have thought that it would be a
>> fairly common configuration?
>
Hi
This stuff really does need documenting. I've put together a rough guide
of most of the common misunderstandings here:
http://linuxcostablanca.blogspot.com/2012/02/nfsv4-myths-and-legends.html
Steve
On 02/10/2012 07:40 PM, J. Bruce Fields wrote:
> On Fri, Feb 10, 2012 at 09:19:38AM +0100, steve wrote:
>>>> I'm happy to provide more details of the domain joining process
>>>> offlist or summarise in another
>>>> email if there is interest.
>>>>
>>>>
>>>>
>>>> I'm surprised by the lack of documentation available on using
>>>> Kerberised NFS with AD. I would have thought that it would be a
>>>> fairly common configuration?
>> Hi
>> This stuff really does need documenting. I've put together a rough
>> guide of most of the common misunderstandings here:
>> http://linuxcostablanca.blogspot.com/2012/02/nfsv4-myths-and-legends.html
> Could you get some of this material into the linux-nfs wiki?
>
> The NFS w/ AD stuff, for example, would probably be worth a page of its
> own and a top-level link under "Documentation" (and the link to Mike
> Eisler's blog entry could be moved to the page, if it still looks like
> it's current).
>
> --b.
Unfortunately, I am unable to write technical English in the style that
is required by the wiki. I am however happy for the link to be placed
there. As there is no user nfs mailing list I'm also happy for folk to
sign up to the article and use _it_ as a mailing list.
Cheers,
Steve
On 05/02/2012 14:16, Jim Rees wrote:
> There is a a NFS wiki, and it does have kerberos setup instructions:
> http://wiki.linux-nfs.org/wiki/index.php/Enduser_doc_kerberos
>
> The wiki has mostly been used by developers for developer info but it might
> be a good thing to use it for more general info too.
Thanks, the problem isn't getting NFS with Kerberos to work in general,
it's with AD as the KDC. It seems that NFS still only accepts DES
encrypted Kerberos tickets, and these are specifically disabled in
Windows Server 2008 R2.
--
Liam Gretton [email protected]
HPC Architect http://www.le.ac.uk/its/
IT Services Tel: +44 (0)116 2522254
University Of Leicester, University Road
Leicestershire LE1 7RH, United Kingdom
On Fri, Feb 10, 2012 at 08:13:16PM +0100, steve wrote:
> On 02/10/2012 07:40 PM, J. Bruce Fields wrote:
> >On Fri, Feb 10, 2012 at 09:19:38AM +0100, steve wrote:
> >>>>I'm happy to provide more details of the domain joining process
> >>>>offlist or summarise in another
> >>>>email if there is interest.
> >>>>
> >>>>
> >>>>
> >>>>I'm surprised by the lack of documentation available on using
> >>>>Kerberised NFS with AD. I would have thought that it would be a
> >>>>fairly common configuration?
> >>Hi
> >>This stuff really does need documenting. I've put together a rough
> >>guide of most of the common misunderstandings here:
> >>http://linuxcostablanca.blogspot.com/2012/02/nfsv4-myths-and-legends.html
> >Could you get some of this material into the linux-nfs wiki?
> >
> >The NFS w/ AD stuff, for example, would probably be worth a page of its
> >own and a top-level link under "Documentation" (and the link to Mike
> >Eisler's blog entry could be moved to the page, if it still looks like
> >it's current).
> >
> >--b.
> Unfortunately, I am unable to write technical English in the style
> that is required by the wiki.
Just say it however it makes sense to you, ping me, and I can do any
wordsmithing if it seems necessary.
--b.
> I am however happy for the link to be
> placed there. As there is no user nfs mailing list I'm also happy
> for folk to sign up to the article and use _it_ as a mailing list.
On 09/02/2012 18:57, Don Riden wrote:
> I've recently managed to get a Linux Kerberized NFS server working
> using an Active Directory 2008 R2 domain controller as a KDC (using
> arcfour-hmac and aes256-cts-hmac-sha1-96).
>
> It's reasonably fiddly and took quite a lot of tweaking to get right.
>
> A short summary of the AD specific side of our configuration:
[snip]
Thanks very much for this information, it's very encouraging and I'll
take another look at getting it working here.
> I'm surprised by the lack of documentation available on using Kerberised NFS with AD. I
> would have thought that it would be a fairly common configuration?
Me too. I'm working on knitting our Windows and Linux environments
together, but all the hard work has to be done at the Linux end (as usual).
I hereby solemnly promise to document my experience on a blog somewhere
assuming I make some progress and can add to the global knowledge pool.
--
Liam Gretton [email protected]
HPC Architect http://www.le.ac.uk/its/
IT Services Tel: +44 (0)116 2522254
University Of Leicester, University Road
Leicestershire LE1 7RH, United Kingdom
