We had trouble getting kerberized nfsv4 working in our environment with RHEL5 servers and RHEL6 clients using the campus Windows 2008 AD servers as our KDC. We've resolved the issue now but I just wanted to summarize our solution in case others are fighting the same problem.
The key issue seems related to encryption since 1) the older RHEL5 kernels only support DES for nfs and 2) it appears that limiting the keytabs to only DES causes a failure to communicate with our campus Windows KDC. I found a number of discussions that suggested limiting the encryption types to only DES and this seems to be the common fix when using a standard MIT kerberos server. However, in our environment we are using a Windows KDC and that solution did not work for us. I don't know if that is a generic problem with a Windows KDC or something particular to the configuration of our campus servers.
Cutting to the chase, here is the configuration in the /etc/krb5.conf on the RHEL6 client that worked for us:
[libdefaults]
default_tkt_enctypes = des-cbc-crc aes256-cts-hmac-sha1-96 arcfour-hmac
allow_weak_crypto = 1
All the gory details are below for anyone interested.
--Rob
Disclaimer: I am not saying this is the only and/or best solution, but it is working for us... :)
===================================================================
Keytab Generation
=================
The campus Windows AD admins generate nfs keytabs for us using the "/crypto ALL" argument to ktpass. They also set the NO_AUTH_DATA_REQUIRED UAC flag on the associated machine accounts. Keytabs are generated using the same procedure for both servers and clients.
RHEL5 NFS Server
================
The keytabs are installed on the RHEL5 server and look like this:
# klist -kte
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp Principal
---- ----------------- --------------------------------------------------------
3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (DES cbc mode with CRC-32)
3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (DES cbc mode with RSA-MD5)
3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (ArcFour with HMAC/md5)
3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (AES-256 CTS mode with 96-bit SHA-1 HMAC)
3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (AES-128 CTS mode with 96-bit SHA-1 HMAC)
There is nothing special in the /etc/krb5.conf on the server side.
RHEL6 NFS Client
================
The keytabs for the client are generated in the same way as for the server and look exactly like that for the server (with the exception that the encryption types are displayed differently with the newer version of klist). They look like this:
# klist -kte
Keytab name: WRFILE:/etc/krb5.keytab
KVNO Timestamp Principal
---- ----------------- --------------------------------------------------------
3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (des-cbc-crc)
3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (des-cbc-md5)
3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (arcfour-hmac)
3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (aes256-cts-hmac-sha1-96)
3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (aes128-cts-hmac-sha1-96)
The following are added to the /etc/krb5.conf:
[libdefaults]
default_tkt_enctypes = des-cbc-crc aes256-cts-hmac-sha1-96 arcfour-hmac
allow_weak_crypto = 1
After the mount, the machine credentials on the client look like this:
# klist -e /tmp/krb5cc_machine_[REALM]
Ticket cache: FILE:/tmp/krb5cc_machine_[REALM]
Default principal: nfs/[client hostname]@[REALM]
Valid starting Expires Service principal
06/21/11 02:44:18 06/21/11 12:44:18 krbtgt/[REALM]@[REALM]
renew until 06/28/11 02:44:18, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
06/21/11 02:44:18 06/21/11 12:44:18 nfs/[server hostname]@[REALM]
renew until 06/28/11 02:44:18, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
And, the user sees the following:
$ klist -e
Ticket cache: FILE:/tmp/krb5cc_[UID]_EfGvpD
Default principal: [USERNAME]@[REALM]
Valid starting Expires Service principal
06/21/11 09:33:01 06/21/11 19:33:01 krbtgt/[REALM]@[REALM]
renew until 06/28/11 09:33:01, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
06/21/11 09:33:03 06/21/11 19:33:01 nfs/[server hostname]@[REALM]
renew until 06/28/11 09:33:01, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
I'm not sure I can give you all the details you'd like since much of my testing was done when we first set this up with RHEL5 servers and clients a couple years ago. In fact, we first set this up when our campus had a genuine MIT kerberos server and things went quite smoothly. Then, they ditched the MIT kerberos server and pushed us into using the Windows KDC and that was the start of all our troubles... ;-) If you want to see some of our earlier pain, search the list archives for:
Migration from MIT KDC to AD: mount succeeds, user access yields"Failed to create krb5 context for user with uid 500"
But, when we first moved to using AD I tried for the longest time generating only keytabs with DES-base enctypes and it never worked. I recall errors about missing keytab entries but am sorry I don't have all the details (tho some information is in the thread with the above subject). All I know is that once I started generating keytabs with 'ktpass /crypto ALL' I got it to work and we've been using these keytabs on both RHEL5 servers and clients (with no default_tgs_enctypes or default_tkt_enctypes settings whatsoever in our krb5.conf files) for the past 2 years with no problems.
When RHEL6 came out I started trying to get it to talk to our RHEL5 servers which led to the working config that I posted. I kept a series of notes about what I tried and you are welcome to look at that:
http://www.cs.indiana.edu/~robh/nfsv4+rhel6.html
These notes were never meant for public consumption so I make no guarantees as to their suitability for any purpose whatsoever... :)
Thanks,
--Rob
Kevin Coffman wrote:
> Can somone point me to a description of the symptoms you were seeing?
> I'd like to better understand what is going on. You say AD doesn't
> allow DES, but Rob's tickets had des session keys.
>
> In any case, a keytab with all enctypes is incorrect for a RHEL5 NFS server.
>
> Thanks,
> K.C.
>
> On Wed, Jun 22, 2011 at 1:13 PM, Vladimir Elisseev <[email protected]> wrote:
>> I had about the same issues and I can prove that the configs posted by
>> Rob _has_ to be used in order to get Linux working with AD (the latest
>> patches don't allow des) RHEL5 works perfectly fine with arcfour-hmac.
>> As for negotiation, theoretically it should work, but not with AD
>> AFAIK... The part about nfs, with the latest nfs-utils you can use
>> aes-256 without any problems.
>>
>> Regards,
>> Vlad.
>>
>> On Wed, 2011-06-22 at 12:53 -0400, Kevin Coffman wrote:
>>> Rob,
>>> I am not clear what initial issues (symptoms) you were seeing. In
>>> general, it is never a good idea to set default_tgs_enctypes or
>>> default_tkt_enctypes in /etc/krb5.conf unless absolutely necessary.
>>> The Kerberos libraries will attempt to negotiate the strongest
>>> algorithm supported by both sides, and setting these values limits
>>> what the Kerberos libraries are able to negotiate for ALL Kerberos
>>> services on the machine.
>>>
>>> If it is necessary to set default_tgs_enctypes or default_tkt_enctypes
>>> to get NFS working, then we still have some work to do!
>>>
>>> I believe that in RHEL5 the nfs kernel code only has DES support, and
>>> uses MIT Kerberos 1.6.1. If that is true, your keytab generation for
>>> your server is incorrect. It should only include DES key(s) for the
>>> NFS service. See
>>> https://www.citi.umich.edu/projects/nfsv4/linux/krb5-setup.html.
>>> Offhand, I do not know the correct syntax to accomplish this with a
>>> Windows KDC.
>>>
>>> K.C.
>>>
>>> On Wed, Jun 22, 2011 at 9:44 AM, Steve Dickson <[email protected]> wrote:
>>>> Hey Rob,
>>>>
>>>> Thanks for the info... I was thought the correct default enctypes
>>>> for Window KDCs where
>>>> default_tgs_enctypes = des-cbc-md5
>>>> default_tkt_enctypes = des-cbc-md5
>>>>
>>>> Maybe we should add this finding to the the NFS FAQ (http://nfs.sourceforge.net/) ?
>>>>
>>>> steved.
>>>>
>>>> On 06/21/2011 09:52 AM, Rob Henderson wrote:
>>>>> We had trouble getting kerberized nfsv4 working in our environment with RHEL5 servers and RHEL6 clients using the campus Windows 2008 AD servers as our KDC. We've resolved the issue now but I just wanted to summarize our solution in case others are fighting the same problem.
>>>>>
>>>>> The key issue seems related to encryption since 1) the older RHEL5 kernels only support DES for nfs and 2) it appears that limiting the keytabs to only DES causes a failure to communicate with our campus Windows KDC. I found a number of discussions that suggested limiting the encryption types to only DES and this seems to be the common fix when using a standard MIT kerberos server. However, in our environment we are using a Windows KDC and that solution did not work for us. I don't know if that is a generic problem with a Windows KDC or something particular to the configuration of our campus servers.
>>>>>
>>>>> Cutting to the chase, here is the configuration in the /etc/krb5.conf on the RHEL6 client that worked for us:
>>>>>
>>>>> [libdefaults]
>>>>> default_tkt_enctypes = des-cbc-crc aes256-cts-hmac-sha1-96 arcfour-hmac
>>>>> allow_weak_crypto = 1
>>>>>
>>>>>
>>>>> All the gory details are below for anyone interested.
>>>>>
>>>>> --Rob
>>>>>
>>>>> Disclaimer: I am not saying this is the only and/or best solution, but it is working for us... :)
>>>>>
>>>>> ===================================================================
>>>>>
>>>>>
>>>>> Keytab Generation
>>>>> =================
>>>>>
>>>>> The campus Windows AD admins generate nfs keytabs for us using the "/crypto ALL" argument to ktpass. They also set the NO_AUTH_DATA_REQUIRED UAC flag on the associated machine accounts. Keytabs are generated using the same procedure for both servers and clients.
>>>>>
>>>>>
>>>>> RHEL5 NFS Server
>>>>> ================
>>>>>
>>>>> The keytabs are installed on the RHEL5 server and look like this:
>>>>>
>>>>> # klist -kte
>>>>>
>>>>> Keytab name: FILE:/etc/krb5.keytab
>>>>> KVNO Timestamp Principal
>>>>> ---- ----------------- --------------------------------------------------------
>>>>> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (DES cbc mode with CRC-32)
>>>>> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (DES cbc mode with RSA-MD5)
>>>>> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (ArcFour with HMAC/md5)
>>>>> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (AES-256 CTS mode with 96-bit SHA-1 HMAC)
>>>>> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (AES-128 CTS mode with 96-bit SHA-1 HMAC)
>>>>>
>>>>> There is nothing special in the /etc/krb5.conf on the server side.
>>>>>
>>>>>
>>>>> RHEL6 NFS Client
>>>>> ================
>>>>>
>>>>> The keytabs for the client are generated in the same way as for the server and look exactly like that for the server (with the exception that the encryption types are displayed differently with the newer version of klist). They look like this:
>>>>>
>>>>> # klist -kte
>>>>> Keytab name: WRFILE:/etc/krb5.keytab
>>>>> KVNO Timestamp Principal
>>>>> ---- ----------------- --------------------------------------------------------
>>>>> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (des-cbc-crc)
>>>>> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (des-cbc-md5)
>>>>> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (arcfour-hmac)
>>>>> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (aes256-cts-hmac-sha1-96)
>>>>> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (aes128-cts-hmac-sha1-96)
>>>>>
>>>>>
>>>>> The following are added to the /etc/krb5.conf:
>>>>>
>>>>> [libdefaults]
>>>>> default_tkt_enctypes = des-cbc-crc aes256-cts-hmac-sha1-96 arcfour-hmac
>>>>> allow_weak_crypto = 1
>>>>>
>>>>> After the mount, the machine credentials on the client look like this:
>>>>>
>>>>> # klist -e /tmp/krb5cc_machine_[REALM]
>>>>> Ticket cache: FILE:/tmp/krb5cc_machine_[REALM]
>>>>> Default principal: nfs/[client hostname]@[REALM]
>>>>>
>>>>> Valid starting Expires Service principal
>>>>> 06/21/11 02:44:18 06/21/11 12:44:18 krbtgt/[REALM]@[REALM]
>>>>> renew until 06/28/11 02:44:18, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
>>>>> 06/21/11 02:44:18 06/21/11 12:44:18 nfs/[server hostname]@[REALM]
>>>>> renew until 06/28/11 02:44:18, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
>>>>>
>>>>> And, the user sees the following:
>>>>>
>>>>> $ klist -e
>>>>> Ticket cache: FILE:/tmp/krb5cc_[UID]_EfGvpD
>>>>> Default principal: [USERNAME]@[REALM]
>>>>>
>>>>> Valid starting Expires Service principal
>>>>> 06/21/11 09:33:01 06/21/11 19:33:01 krbtgt/[REALM]@[REALM]
>>>>> renew until 06/28/11 09:33:01, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
>>>>> 06/21/11 09:33:03 06/21/11 19:33:01 nfs/[server hostname]@[REALM]
>>>>> renew until 06/28/11 09:33:01, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
>>>>>
>>>>>
>>>>> --
>>>>> 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
>>>> --
>>>> 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
>>>>
>>> --
>>> 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
>>
> --
> 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
Windows KDC doesnt like creating des keys and it has to be enabled
specifically. So what happened is that while you created your NFS
server keytab with a des key, your user's enctypes are windows
defaults which is arcfour-hmac. Btw, if you want des tickets for user,
then all user accounts in AD should be configured with an option "use
DES encryption methods".
Also let's remember that there are default_tkt_enctype and
default_tgs_enctype. First one limits encryption types for a tgt and
another is for a service ticket. In this scenario, your tgts should be
either arcfour or aes and your nfs service ticket should be des.
On Fri, Jun 24, 2011 at 4:47 PM, Rob Henderson <[email protected]> wrote:
> When I try the settings you suggest, the mount is actually successful. ?However, when I login as a normal user and try to obtain a tgt I see the following:
>
> ?$ kinit
> ?kinit: KDC has no support for encryption type while getting initial credentials
>
> As soon as I add arcfour-hmac to default_tgs_enctypes the kinit then works. ?However, it doesn't appear that nfs actually work properly until I add both es256-cts-hmac-sha1-96 and arcfour-hmac to this list, tho I haven't tested that extensively.
>
> ?--Rob
>
>
> Steve Dickson wrote:
>> Hey Rob,
>>
>> Thanks for the info... I was thought the correct default enctypes
>> for Window KDCs where
>> ? ? default_tgs_enctypes = des-cbc-md5
>> ? ? default_tkt_enctypes = des-cbc-md5
>>
>> Maybe we should add this finding to the the NFS FAQ (http://nfs.sourceforge.net/) ?
>>
>> steved.
>>
>> On 06/21/2011 09:52 AM, Rob Henderson wrote:
>>> We had trouble getting kerberized nfsv4 working in our environment with RHEL5 servers and RHEL6 clients using the campus Windows 2008 AD servers as our KDC. ?We've resolved the issue now but I just wanted to summarize our solution in case others are fighting the same problem.
>>>
>>> The key issue seems related to encryption since 1) the older RHEL5 kernels only support DES for nfs and 2) it appears that limiting the keytabs to only DES causes a failure to communicate with our campus Windows KDC. ?I found a number of discussions that suggested limiting the encryption types to only DES and this seems to be the common fix when using a standard MIT kerberos server. ?However, in our environment we are using a Windows KDC and that solution did not work for us. ?I don't know if that is a generic problem with a Windows KDC or something particular to the configuration of our campus servers.
>>>
>>> Cutting to the chase, here is the configuration in the /etc/krb5.conf on the RHEL6 client that worked for us:
>>>
>>> ? ? [libdefaults]
>>> ? ? ? ? default_tkt_enctypes = des-cbc-crc aes256-cts-hmac-sha1-96 arcfour-hmac
>>> ? ? ? ? allow_weak_crypto = 1
>>>
>>>
>>> All the gory details are below for anyone interested.
>>>
>>> ? ?--Rob
>>>
>>> Disclaimer: ?I am not saying this is the only and/or best solution, but it is working for us... :)
>>>
>>> ===================================================================
>>>
>>>
>>> Keytab Generation
>>> =================
>>>
>>> The campus Windows AD admins generate nfs keytabs for us using the "/crypto ALL" argument to ktpass. ?They also set the NO_AUTH_DATA_REQUIRED UAC flag on the associated machine accounts. ?Keytabs are generated using the same procedure for both servers and clients.
>>>
>>>
>>> RHEL5 NFS Server
>>> ================
>>>
>>> The keytabs are installed on the RHEL5 server and look like this:
>>>
>>> # klist -kte
>>>
>>> Keytab name: FILE:/etc/krb5.keytab
>>> KVNO Timestamp ? ? ? ? Principal
>>> ---- ----------------- --------------------------------------------------------
>>> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (DES cbc mode with CRC-32)
>>> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (DES cbc mode with RSA-MD5)
>>> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (ArcFour with HMAC/md5)
>>> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (AES-256 CTS mode with 96-bit SHA-1 HMAC)
>>> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (AES-128 CTS mode with 96-bit SHA-1 HMAC)
>>>
>>> There is nothing special in the /etc/krb5.conf on the server side.
>>>
>>>
>>> RHEL6 NFS Client
>>> ================
>>>
>>> The keytabs for the client are generated in the same way as for the server and look exactly like that for the server (with the exception that the encryption types are displayed differently with the newer version of klist). ?They look like this:
>>>
>>> # klist -kte
>>> Keytab name: WRFILE:/etc/krb5.keytab
>>> KVNO Timestamp ? ? ? ? Principal
>>> ---- ----------------- --------------------------------------------------------
>>> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (des-cbc-crc)
>>> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (des-cbc-md5)
>>> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (arcfour-hmac)
>>> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (aes256-cts-hmac-sha1-96)
>>> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (aes128-cts-hmac-sha1-96)
>>>
>>>
>>> The following are added to the /etc/krb5.conf:
>>>
>>> ? ? ?[libdefaults]
>>> ? ? ? ? default_tkt_enctypes = des-cbc-crc aes256-cts-hmac-sha1-96 arcfour-hmac
>>> ? ? ? ? allow_weak_crypto = 1
>>>
>>> After the mount, the machine credentials on the client look like this:
>>>
>>> ? ? ? # klist -e /tmp/krb5cc_machine_[REALM]
>>> ? ? ? Ticket cache: FILE:/tmp/krb5cc_machine_[REALM]
>>> ? ? ? Default principal: nfs/[client hostname]@[REALM]
>>>
>>> ? ? ? Valid starting ? ? Expires ? ? ? ? ? ?Service principal
>>> ? ? ? 06/21/11 02:44:18 ?06/21/11 12:44:18 ?krbtgt/[REALM]@[REALM]
>>> ? ? ? ? ? ? ? renew until 06/28/11 02:44:18, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
>>> ? ? ? 06/21/11 02:44:18 ?06/21/11 12:44:18 ?nfs/[server hostname]@[REALM]
>>> ? ? ? ? ? ? ? renew until 06/28/11 02:44:18, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
>>>
>>> And, the user sees the following:
>>>
>>> ? ? ? $ klist -e
>>> ? ? ? Ticket cache: FILE:/tmp/krb5cc_[UID]_EfGvpD
>>> ? ? ? Default principal: [USERNAME]@[REALM]
>>>
>>> ? ? ? Valid starting ? ? Expires ? ? ? ? ? ?Service principal
>>> ? ? ? 06/21/11 09:33:01 ?06/21/11 19:33:01 ?krbtgt/[REALM]@[REALM]
>>> ? ? ? ? ? ? ? renew until 06/28/11 09:33:01, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
>>> ? ? ? 06/21/11 09:33:03 ?06/21/11 19:33:01 ?nfs/[server hostname]@[REALM]
>>> ? ? ? ? ? ? ?renew until 06/28/11 09:33:01, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
>>>
>>>
>>> --
>>> 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
>> --
>> 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
> --
> 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
>
When I try the settings you suggest, the mount is actually successful. However, when I login as a normal user and try to obtain a tgt I see the following:
$ kinit
kinit: KDC has no support for encryption type while getting initial credentials
As soon as I add arcfour-hmac to default_tgs_enctypes the kinit then works. However, it doesn't appear that nfs actually work properly until I add both es256-cts-hmac-sha1-96 and arcfour-hmac to this list, tho I haven't tested that extensively.
--Rob
Steve Dickson wrote:
> Hey Rob,
>
> Thanks for the info... I was thought the correct default enctypes
> for Window KDCs where
> default_tgs_enctypes = des-cbc-md5
> default_tkt_enctypes = des-cbc-md5
>
> Maybe we should add this finding to the the NFS FAQ (http://nfs.sourceforge.net/) ?
>
> steved.
>
> On 06/21/2011 09:52 AM, Rob Henderson wrote:
>> We had trouble getting kerberized nfsv4 working in our environment with RHEL5 servers and RHEL6 clients using the campus Windows 2008 AD servers as our KDC. We've resolved the issue now but I just wanted to summarize our solution in case others are fighting the same problem.
>>
>> The key issue seems related to encryption since 1) the older RHEL5 kernels only support DES for nfs and 2) it appears that limiting the keytabs to only DES causes a failure to communicate with our campus Windows KDC. I found a number of discussions that suggested limiting the encryption types to only DES and this seems to be the common fix when using a standard MIT kerberos server. However, in our environment we are using a Windows KDC and that solution did not work for us. I don't know if that is a generic problem with a Windows KDC or something particular to the configuration of our campus servers.
>>
>> Cutting to the chase, here is the configuration in the /etc/krb5.conf on the RHEL6 client that worked for us:
>>
>> [libdefaults]
>> default_tkt_enctypes = des-cbc-crc aes256-cts-hmac-sha1-96 arcfour-hmac
>> allow_weak_crypto = 1
>>
>>
>> All the gory details are below for anyone interested.
>>
>> --Rob
>>
>> Disclaimer: I am not saying this is the only and/or best solution, but it is working for us... :)
>>
>> ===================================================================
>>
>>
>> Keytab Generation
>> =================
>>
>> The campus Windows AD admins generate nfs keytabs for us using the "/crypto ALL" argument to ktpass. They also set the NO_AUTH_DATA_REQUIRED UAC flag on the associated machine accounts. Keytabs are generated using the same procedure for both servers and clients.
>>
>>
>> RHEL5 NFS Server
>> ================
>>
>> The keytabs are installed on the RHEL5 server and look like this:
>>
>> # klist -kte
>>
>> Keytab name: FILE:/etc/krb5.keytab
>> KVNO Timestamp Principal
>> ---- ----------------- --------------------------------------------------------
>> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (DES cbc mode with CRC-32)
>> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (DES cbc mode with RSA-MD5)
>> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (ArcFour with HMAC/md5)
>> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (AES-256 CTS mode with 96-bit SHA-1 HMAC)
>> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (AES-128 CTS mode with 96-bit SHA-1 HMAC)
>>
>> There is nothing special in the /etc/krb5.conf on the server side.
>>
>>
>> RHEL6 NFS Client
>> ================
>>
>> The keytabs for the client are generated in the same way as for the server and look exactly like that for the server (with the exception that the encryption types are displayed differently with the newer version of klist). They look like this:
>>
>> # klist -kte
>> Keytab name: WRFILE:/etc/krb5.keytab
>> KVNO Timestamp Principal
>> ---- ----------------- --------------------------------------------------------
>> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (des-cbc-crc)
>> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (des-cbc-md5)
>> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (arcfour-hmac)
>> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (aes256-cts-hmac-sha1-96)
>> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (aes128-cts-hmac-sha1-96)
>>
>>
>> The following are added to the /etc/krb5.conf:
>>
>> [libdefaults]
>> default_tkt_enctypes = des-cbc-crc aes256-cts-hmac-sha1-96 arcfour-hmac
>> allow_weak_crypto = 1
>>
>> After the mount, the machine credentials on the client look like this:
>>
>> # klist -e /tmp/krb5cc_machine_[REALM]
>> Ticket cache: FILE:/tmp/krb5cc_machine_[REALM]
>> Default principal: nfs/[client hostname]@[REALM]
>>
>> Valid starting Expires Service principal
>> 06/21/11 02:44:18 06/21/11 12:44:18 krbtgt/[REALM]@[REALM]
>> renew until 06/28/11 02:44:18, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
>> 06/21/11 02:44:18 06/21/11 12:44:18 nfs/[server hostname]@[REALM]
>> renew until 06/28/11 02:44:18, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
>>
>> And, the user sees the following:
>>
>> $ klist -e
>> Ticket cache: FILE:/tmp/krb5cc_[UID]_EfGvpD
>> Default principal: [USERNAME]@[REALM]
>>
>> Valid starting Expires Service principal
>> 06/21/11 09:33:01 06/21/11 19:33:01 krbtgt/[REALM]@[REALM]
>> renew until 06/28/11 09:33:01, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
>> 06/21/11 09:33:03 06/21/11 19:33:01 nfs/[server hostname]@[REALM]
>> renew until 06/28/11 09:33:01, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
>>
>>
>> --
>> 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
> --
> 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
Can somone point me to a description of the symptoms you were seeing?
I'd like to better understand what is going on. You say AD doesn't
allow DES, but Rob's tickets had des session keys.
In any case, a keytab with all enctypes is incorrect for a RHEL5 NFS server.
Thanks,
K.C.
On Wed, Jun 22, 2011 at 1:13 PM, Vladimir Elisseev <[email protected]> wrote:
> I had about the same issues and I can prove that the configs posted by
> Rob _has_ to be used in order to get Linux working with AD (the latest
> patches don't allow des) RHEL5 works perfectly fine with arcfour-hmac.
> As for negotiation, theoretically it should work, but not with AD
> AFAIK... The part about nfs, with the latest nfs-utils you can use
> aes-256 without any problems.
>
> Regards,
> Vlad.
>
> On Wed, 2011-06-22 at 12:53 -0400, Kevin Coffman wrote:
>> Rob,
>> I am not clear what initial issues (symptoms) you were seeing. ?In
>> general, it is never a good idea to set default_tgs_enctypes or
>> default_tkt_enctypes in /etc/krb5.conf unless absolutely necessary.
>> The Kerberos libraries will attempt to negotiate the strongest
>> algorithm supported by both sides, and setting these values limits
>> what the Kerberos libraries are able to negotiate for ALL Kerberos
>> services on the machine.
>>
>> If it is necessary to set default_tgs_enctypes or default_tkt_enctypes
>> to get NFS working, then we still have some work to do!
>>
>> I believe that in RHEL5 the nfs kernel code only has DES support, and
>> uses MIT Kerberos 1.6.1. ?If that is true, your keytab generation for
>> your server is incorrect. ?It should only include DES key(s) for the
>> NFS service. ?See
>> https://www.citi.umich.edu/projects/nfsv4/linux/krb5-setup.html.
>> Offhand, I do not know the correct syntax to accomplish this with a
>> Windows KDC.
>>
>> K.C.
>>
>> On Wed, Jun 22, 2011 at 9:44 AM, Steve Dickson <[email protected]> wrote:
>> > Hey Rob,
>> >
>> > Thanks for the info... I was thought the correct default enctypes
>> > for Window KDCs where
>> > ? ?default_tgs_enctypes = des-cbc-md5
>> > ? ?default_tkt_enctypes = des-cbc-md5
>> >
>> > Maybe we should add this finding to the the NFS FAQ (http://nfs.sourceforge.net/) ?
>> >
>> > steved.
>> >
>> > On 06/21/2011 09:52 AM, Rob Henderson wrote:
>> >> We had trouble getting kerberized nfsv4 working in our environment with RHEL5 servers and RHEL6 clients using the campus Windows 2008 AD servers as our KDC. ?We've resolved the issue now but I just wanted to summarize our solution in case others are fighting the same problem.
>> >>
>> >> The key issue seems related to encryption since 1) the older RHEL5 kernels only support DES for nfs and 2) it appears that limiting the keytabs to only DES causes a failure to communicate with our campus Windows KDC. ?I found a number of discussions that suggested limiting the encryption types to only DES and this seems to be the common fix when using a standard MIT kerberos server. ?However, in our environment we are using a Windows KDC and that solution did not work for us. ?I don't know if that is a generic problem with a Windows KDC or something particular to the configuration of our campus servers.
>> >>
>> >> Cutting to the chase, here is the configuration in the /etc/krb5.conf on the RHEL6 client that worked for us:
>> >>
>> >> ? ? [libdefaults]
>> >> ? ? ? ? default_tkt_enctypes = des-cbc-crc aes256-cts-hmac-sha1-96 arcfour-hmac
>> >> ? ? ? ? allow_weak_crypto = 1
>> >>
>> >>
>> >> All the gory details are below for anyone interested.
>> >>
>> >> ? ?--Rob
>> >>
>> >> Disclaimer: ?I am not saying this is the only and/or best solution, but it is working for us... :)
>> >>
>> >> ===================================================================
>> >>
>> >>
>> >> Keytab Generation
>> >> =================
>> >>
>> >> The campus Windows AD admins generate nfs keytabs for us using the "/crypto ALL" argument to ktpass. ?They also set the NO_AUTH_DATA_REQUIRED UAC flag on the associated machine accounts. ?Keytabs are generated using the same procedure for both servers and clients.
>> >>
>> >>
>> >> RHEL5 NFS Server
>> >> ================
>> >>
>> >> The keytabs are installed on the RHEL5 server and look like this:
>> >>
>> >> # klist -kte
>> >>
>> >> Keytab name: FILE:/etc/krb5.keytab
>> >> KVNO Timestamp ? ? ? ? Principal
>> >> ---- ----------------- --------------------------------------------------------
>> >> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (DES cbc mode with CRC-32)
>> >> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (DES cbc mode with RSA-MD5)
>> >> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (ArcFour with HMAC/md5)
>> >> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (AES-256 CTS mode with 96-bit SHA-1 HMAC)
>> >> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (AES-128 CTS mode with 96-bit SHA-1 HMAC)
>> >>
>> >> There is nothing special in the /etc/krb5.conf on the server side.
>> >>
>> >>
>> >> RHEL6 NFS Client
>> >> ================
>> >>
>> >> The keytabs for the client are generated in the same way as for the server and look exactly like that for the server (with the exception that the encryption types are displayed differently with the newer version of klist). ?They look like this:
>> >>
>> >> # klist -kte
>> >> Keytab name: WRFILE:/etc/krb5.keytab
>> >> KVNO Timestamp ? ? ? ? Principal
>> >> ---- ----------------- --------------------------------------------------------
>> >> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (des-cbc-crc)
>> >> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (des-cbc-md5)
>> >> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (arcfour-hmac)
>> >> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (aes256-cts-hmac-sha1-96)
>> >> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (aes128-cts-hmac-sha1-96)
>> >>
>> >>
>> >> The following are added to the /etc/krb5.conf:
>> >>
>> >> ? ? ?[libdefaults]
>> >> ? ? ? ? default_tkt_enctypes = des-cbc-crc aes256-cts-hmac-sha1-96 arcfour-hmac
>> >> ? ? ? ? allow_weak_crypto = 1
>> >>
>> >> After the mount, the machine credentials on the client look like this:
>> >>
>> >> ? ? ? # klist -e /tmp/krb5cc_machine_[REALM]
>> >> ? ? ? Ticket cache: FILE:/tmp/krb5cc_machine_[REALM]
>> >> ? ? ? Default principal: nfs/[client hostname]@[REALM]
>> >>
>> >> ? ? ? Valid starting ? ? Expires ? ? ? ? ? ?Service principal
>> >> ? ? ? 06/21/11 02:44:18 ?06/21/11 12:44:18 ?krbtgt/[REALM]@[REALM]
>> >> ? ? ? ? ? ? ? renew until 06/28/11 02:44:18, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
>> >> ? ? ? 06/21/11 02:44:18 ?06/21/11 12:44:18 ?nfs/[server hostname]@[REALM]
>> >> ? ? ? ? ? ? ? renew until 06/28/11 02:44:18, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
>> >>
>> >> And, the user sees the following:
>> >>
>> >> ? ? ? $ klist -e
>> >> ? ? ? Ticket cache: FILE:/tmp/krb5cc_[UID]_EfGvpD
>> >> ? ? ? Default principal: [USERNAME]@[REALM]
>> >>
>> >> ? ? ? Valid starting ? ? Expires ? ? ? ? ? ?Service principal
>> >> ? ? ? 06/21/11 09:33:01 ?06/21/11 19:33:01 ?krbtgt/[REALM]@[REALM]
>> >> ? ? ? ? ? ? ? renew until 06/28/11 09:33:01, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
>> >> ? ? ? 06/21/11 09:33:03 ?06/21/11 19:33:01 ?nfs/[server hostname]@[REALM]
>> >> ? ? ? ? ? ? ?renew until 06/28/11 09:33:01, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
>> >>
>> >>
>> >> --
>> >> 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
>> > --
>> > 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
>> >
>> --
>> 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
>
>
I had about the same issues and I can prove that the configs posted by
Rob _has_ to be used in order to get Linux working with AD (the latest
patches don't allow des) RHEL5 works perfectly fine with arcfour-hmac.
As for negotiation, theoretically it should work, but not with AD
AFAIK... The part about nfs, with the latest nfs-utils you can use
aes-256 without any problems.
Regards,
Vlad.
On Wed, 2011-06-22 at 12:53 -0400, Kevin Coffman wrote:
> Rob,
> I am not clear what initial issues (symptoms) you were seeing. In
> general, it is never a good idea to set default_tgs_enctypes or
> default_tkt_enctypes in /etc/krb5.conf unless absolutely necessary.
> The Kerberos libraries will attempt to negotiate the strongest
> algorithm supported by both sides, and setting these values limits
> what the Kerberos libraries are able to negotiate for ALL Kerberos
> services on the machine.
>
> If it is necessary to set default_tgs_enctypes or default_tkt_enctypes
> to get NFS working, then we still have some work to do!
>
> I believe that in RHEL5 the nfs kernel code only has DES support, and
> uses MIT Kerberos 1.6.1. If that is true, your keytab generation for
> your server is incorrect. It should only include DES key(s) for the
> NFS service. See
> https://www.citi.umich.edu/projects/nfsv4/linux/krb5-setup.html.
> Offhand, I do not know the correct syntax to accomplish this with a
> Windows KDC.
>
> K.C.
>
> On Wed, Jun 22, 2011 at 9:44 AM, Steve Dickson <[email protected]> wrote:
> > Hey Rob,
> >
> > Thanks for the info... I was thought the correct default enctypes
> > for Window KDCs where
> > default_tgs_enctypes = des-cbc-md5
> > default_tkt_enctypes = des-cbc-md5
> >
> > Maybe we should add this finding to the the NFS FAQ (http://nfs.sourceforge.net/) ?
> >
> > steved.
> >
> > On 06/21/2011 09:52 AM, Rob Henderson wrote:
> >> We had trouble getting kerberized nfsv4 working in our environment with RHEL5 servers and RHEL6 clients using the campus Windows 2008 AD servers as our KDC. We've resolved the issue now but I just wanted to summarize our solution in case others are fighting the same problem.
> >>
> >> The key issue seems related to encryption since 1) the older RHEL5 kernels only support DES for nfs and 2) it appears that limiting the keytabs to only DES causes a failure to communicate with our campus Windows KDC. I found a number of discussions that suggested limiting the encryption types to only DES and this seems to be the common fix when using a standard MIT kerberos server. However, in our environment we are using a Windows KDC and that solution did not work for us. I don't know if that is a generic problem with a Windows KDC or something particular to the configuration of our campus servers.
> >>
> >> Cutting to the chase, here is the configuration in the /etc/krb5.conf on the RHEL6 client that worked for us:
> >>
> >> [libdefaults]
> >> default_tkt_enctypes = des-cbc-crc aes256-cts-hmac-sha1-96 arcfour-hmac
> >> allow_weak_crypto = 1
> >>
> >>
> >> All the gory details are below for anyone interested.
> >>
> >> --Rob
> >>
> >> Disclaimer: I am not saying this is the only and/or best solution, but it is working for us... :)
> >>
> >> ===================================================================
> >>
> >>
> >> Keytab Generation
> >> =================
> >>
> >> The campus Windows AD admins generate nfs keytabs for us using the "/crypto ALL" argument to ktpass. They also set the NO_AUTH_DATA_REQUIRED UAC flag on the associated machine accounts. Keytabs are generated using the same procedure for both servers and clients.
> >>
> >>
> >> RHEL5 NFS Server
> >> ================
> >>
> >> The keytabs are installed on the RHEL5 server and look like this:
> >>
> >> # klist -kte
> >>
> >> Keytab name: FILE:/etc/krb5.keytab
> >> KVNO Timestamp Principal
> >> ---- ----------------- --------------------------------------------------------
> >> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (DES cbc mode with CRC-32)
> >> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (DES cbc mode with RSA-MD5)
> >> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (ArcFour with HMAC/md5)
> >> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (AES-256 CTS mode with 96-bit SHA-1 HMAC)
> >> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (AES-128 CTS mode with 96-bit SHA-1 HMAC)
> >>
> >> There is nothing special in the /etc/krb5.conf on the server side.
> >>
> >>
> >> RHEL6 NFS Client
> >> ================
> >>
> >> The keytabs for the client are generated in the same way as for the server and look exactly like that for the server (with the exception that the encryption types are displayed differently with the newer version of klist). They look like this:
> >>
> >> # klist -kte
> >> Keytab name: WRFILE:/etc/krb5.keytab
> >> KVNO Timestamp Principal
> >> ---- ----------------- --------------------------------------------------------
> >> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (des-cbc-crc)
> >> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (des-cbc-md5)
> >> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (arcfour-hmac)
> >> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (aes256-cts-hmac-sha1-96)
> >> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (aes128-cts-hmac-sha1-96)
> >>
> >>
> >> The following are added to the /etc/krb5.conf:
> >>
> >> [libdefaults]
> >> default_tkt_enctypes = des-cbc-crc aes256-cts-hmac-sha1-96 arcfour-hmac
> >> allow_weak_crypto = 1
> >>
> >> After the mount, the machine credentials on the client look like this:
> >>
> >> # klist -e /tmp/krb5cc_machine_[REALM]
> >> Ticket cache: FILE:/tmp/krb5cc_machine_[REALM]
> >> Default principal: nfs/[client hostname]@[REALM]
> >>
> >> Valid starting Expires Service principal
> >> 06/21/11 02:44:18 06/21/11 12:44:18 krbtgt/[REALM]@[REALM]
> >> renew until 06/28/11 02:44:18, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
> >> 06/21/11 02:44:18 06/21/11 12:44:18 nfs/[server hostname]@[REALM]
> >> renew until 06/28/11 02:44:18, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
> >>
> >> And, the user sees the following:
> >>
> >> $ klist -e
> >> Ticket cache: FILE:/tmp/krb5cc_[UID]_EfGvpD
> >> Default principal: [USERNAME]@[REALM]
> >>
> >> Valid starting Expires Service principal
> >> 06/21/11 09:33:01 06/21/11 19:33:01 krbtgt/[REALM]@[REALM]
> >> renew until 06/28/11 09:33:01, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
> >> 06/21/11 09:33:03 06/21/11 19:33:01 nfs/[server hostname]@[REALM]
> >> renew until 06/28/11 09:33:01, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
> >>
> >>
> >> --
> >> 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
> > --
> > 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
> >
> --
> 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
Hey Rob,
Thanks for the info... I was thought the correct default enctypes
for Window KDCs where
default_tgs_enctypes = des-cbc-md5
default_tkt_enctypes = des-cbc-md5
Maybe we should add this finding to the the NFS FAQ (http://nfs.sourceforge.net/) ?
steved.
On 06/21/2011 09:52 AM, Rob Henderson wrote:
> We had trouble getting kerberized nfsv4 working in our environment with RHEL5 servers and RHEL6 clients using the campus Windows 2008 AD servers as our KDC. We've resolved the issue now but I just wanted to summarize our solution in case others are fighting the same problem.
>
> The key issue seems related to encryption since 1) the older RHEL5 kernels only support DES for nfs and 2) it appears that limiting the keytabs to only DES causes a failure to communicate with our campus Windows KDC. I found a number of discussions that suggested limiting the encryption types to only DES and this seems to be the common fix when using a standard MIT kerberos server. However, in our environment we are using a Windows KDC and that solution did not work for us. I don't know if that is a generic problem with a Windows KDC or something particular to the configuration of our campus servers.
>
> Cutting to the chase, here is the configuration in the /etc/krb5.conf on the RHEL6 client that worked for us:
>
> [libdefaults]
> default_tkt_enctypes = des-cbc-crc aes256-cts-hmac-sha1-96 arcfour-hmac
> allow_weak_crypto = 1
>
>
> All the gory details are below for anyone interested.
>
> --Rob
>
> Disclaimer: I am not saying this is the only and/or best solution, but it is working for us... :)
>
> ===================================================================
>
>
> Keytab Generation
> =================
>
> The campus Windows AD admins generate nfs keytabs for us using the "/crypto ALL" argument to ktpass. They also set the NO_AUTH_DATA_REQUIRED UAC flag on the associated machine accounts. Keytabs are generated using the same procedure for both servers and clients.
>
>
> RHEL5 NFS Server
> ================
>
> The keytabs are installed on the RHEL5 server and look like this:
>
> # klist -kte
>
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Timestamp Principal
> ---- ----------------- --------------------------------------------------------
> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (DES cbc mode with CRC-32)
> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (DES cbc mode with RSA-MD5)
> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (ArcFour with HMAC/md5)
> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (AES-256 CTS mode with 96-bit SHA-1 HMAC)
> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (AES-128 CTS mode with 96-bit SHA-1 HMAC)
>
> There is nothing special in the /etc/krb5.conf on the server side.
>
>
> RHEL6 NFS Client
> ================
>
> The keytabs for the client are generated in the same way as for the server and look exactly like that for the server (with the exception that the encryption types are displayed differently with the newer version of klist). They look like this:
>
> # klist -kte
> Keytab name: WRFILE:/etc/krb5.keytab
> KVNO Timestamp Principal
> ---- ----------------- --------------------------------------------------------
> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (des-cbc-crc)
> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (des-cbc-md5)
> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (arcfour-hmac)
> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (aes256-cts-hmac-sha1-96)
> 3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (aes128-cts-hmac-sha1-96)
>
>
> The following are added to the /etc/krb5.conf:
>
> [libdefaults]
> default_tkt_enctypes = des-cbc-crc aes256-cts-hmac-sha1-96 arcfour-hmac
> allow_weak_crypto = 1
>
> After the mount, the machine credentials on the client look like this:
>
> # klist -e /tmp/krb5cc_machine_[REALM]
> Ticket cache: FILE:/tmp/krb5cc_machine_[REALM]
> Default principal: nfs/[client hostname]@[REALM]
>
> Valid starting Expires Service principal
> 06/21/11 02:44:18 06/21/11 12:44:18 krbtgt/[REALM]@[REALM]
> renew until 06/28/11 02:44:18, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
> 06/21/11 02:44:18 06/21/11 12:44:18 nfs/[server hostname]@[REALM]
> renew until 06/28/11 02:44:18, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
>
> And, the user sees the following:
>
> $ klist -e
> Ticket cache: FILE:/tmp/krb5cc_[UID]_EfGvpD
> Default principal: [USERNAME]@[REALM]
>
> Valid starting Expires Service principal
> 06/21/11 09:33:01 06/21/11 19:33:01 krbtgt/[REALM]@[REALM]
> renew until 06/28/11 09:33:01, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
> 06/21/11 09:33:03 06/21/11 19:33:01 nfs/[server hostname]@[REALM]
> renew until 06/28/11 09:33:01, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
>
>
> --
> 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
Rob,
I am not clear what initial issues (symptoms) you were seeing. In
general, it is never a good idea to set default_tgs_enctypes or
default_tkt_enctypes in /etc/krb5.conf unless absolutely necessary.
The Kerberos libraries will attempt to negotiate the strongest
algorithm supported by both sides, and setting these values limits
what the Kerberos libraries are able to negotiate for ALL Kerberos
services on the machine.
If it is necessary to set default_tgs_enctypes or default_tkt_enctypes
to get NFS working, then we still have some work to do!
I believe that in RHEL5 the nfs kernel code only has DES support, and
uses MIT Kerberos 1.6.1. If that is true, your keytab generation for
your server is incorrect. It should only include DES key(s) for the
NFS service. See
https://www.citi.umich.edu/projects/nfsv4/linux/krb5-setup.html.
Offhand, I do not know the correct syntax to accomplish this with a
Windows KDC.
K.C.
On Wed, Jun 22, 2011 at 9:44 AM, Steve Dickson <[email protected]> wrote:
> Hey Rob,
>
> Thanks for the info... I was thought the correct default enctypes
> for Window KDCs where
> ? ?default_tgs_enctypes = des-cbc-md5
> ? ?default_tkt_enctypes = des-cbc-md5
>
> Maybe we should add this finding to the the NFS FAQ (http://nfs.sourceforge.net/) ?
>
> steved.
>
> On 06/21/2011 09:52 AM, Rob Henderson wrote:
>> We had trouble getting kerberized nfsv4 working in our environment with RHEL5 servers and RHEL6 clients using the campus Windows 2008 AD servers as our KDC. ?We've resolved the issue now but I just wanted to summarize our solution in case others are fighting the same problem.
>>
>> The key issue seems related to encryption since 1) the older RHEL5 kernels only support DES for nfs and 2) it appears that limiting the keytabs to only DES causes a failure to communicate with our campus Windows KDC. ?I found a number of discussions that suggested limiting the encryption types to only DES and this seems to be the common fix when using a standard MIT kerberos server. ?However, in our environment we are using a Windows KDC and that solution did not work for us. ?I don't know if that is a generic problem with a Windows KDC or something particular to the configuration of our campus servers.
>>
>> Cutting to the chase, here is the configuration in the /etc/krb5.conf on the RHEL6 client that worked for us:
>>
>> ? ? [libdefaults]
>> ? ? ? ? default_tkt_enctypes = des-cbc-crc aes256-cts-hmac-sha1-96 arcfour-hmac
>> ? ? ? ? allow_weak_crypto = 1
>>
>>
>> All the gory details are below for anyone interested.
>>
>> ? ?--Rob
>>
>> Disclaimer: ?I am not saying this is the only and/or best solution, but it is working for us... :)
>>
>> ===================================================================
>>
>>
>> Keytab Generation
>> =================
>>
>> The campus Windows AD admins generate nfs keytabs for us using the "/crypto ALL" argument to ktpass. ?They also set the NO_AUTH_DATA_REQUIRED UAC flag on the associated machine accounts. ?Keytabs are generated using the same procedure for both servers and clients.
>>
>>
>> RHEL5 NFS Server
>> ================
>>
>> The keytabs are installed on the RHEL5 server and look like this:
>>
>> # klist -kte
>>
>> Keytab name: FILE:/etc/krb5.keytab
>> KVNO Timestamp ? ? ? ? Principal
>> ---- ----------------- --------------------------------------------------------
>> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (DES cbc mode with CRC-32)
>> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (DES cbc mode with RSA-MD5)
>> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (ArcFour with HMAC/md5)
>> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (AES-256 CTS mode with 96-bit SHA-1 HMAC)
>> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (AES-128 CTS mode with 96-bit SHA-1 HMAC)
>>
>> There is nothing special in the /etc/krb5.conf on the server side.
>>
>>
>> RHEL6 NFS Client
>> ================
>>
>> The keytabs for the client are generated in the same way as for the server and look exactly like that for the server (with the exception that the encryption types are displayed differently with the newer version of klist). ?They look like this:
>>
>> # klist -kte
>> Keytab name: WRFILE:/etc/krb5.keytab
>> KVNO Timestamp ? ? ? ? Principal
>> ---- ----------------- --------------------------------------------------------
>> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (des-cbc-crc)
>> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (des-cbc-md5)
>> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (arcfour-hmac)
>> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (aes256-cts-hmac-sha1-96)
>> ? ?3 12/31/69 19:00:00 nfs/[hostname]@[REALM] (aes128-cts-hmac-sha1-96)
>>
>>
>> The following are added to the /etc/krb5.conf:
>>
>> ? ? ?[libdefaults]
>> ? ? ? ? default_tkt_enctypes = des-cbc-crc aes256-cts-hmac-sha1-96 arcfour-hmac
>> ? ? ? ? allow_weak_crypto = 1
>>
>> After the mount, the machine credentials on the client look like this:
>>
>> ? ? ? # klist -e /tmp/krb5cc_machine_[REALM]
>> ? ? ? Ticket cache: FILE:/tmp/krb5cc_machine_[REALM]
>> ? ? ? Default principal: nfs/[client hostname]@[REALM]
>>
>> ? ? ? Valid starting ? ? Expires ? ? ? ? ? ?Service principal
>> ? ? ? 06/21/11 02:44:18 ?06/21/11 12:44:18 ?krbtgt/[REALM]@[REALM]
>> ? ? ? ? ? ? ? renew until 06/28/11 02:44:18, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
>> ? ? ? 06/21/11 02:44:18 ?06/21/11 12:44:18 ?nfs/[server hostname]@[REALM]
>> ? ? ? ? ? ? ? renew until 06/28/11 02:44:18, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
>>
>> And, the user sees the following:
>>
>> ? ? ? $ klist -e
>> ? ? ? Ticket cache: FILE:/tmp/krb5cc_[UID]_EfGvpD
>> ? ? ? Default principal: [USERNAME]@[REALM]
>>
>> ? ? ? Valid starting ? ? Expires ? ? ? ? ? ?Service principal
>> ? ? ? 06/21/11 09:33:01 ?06/21/11 19:33:01 ?krbtgt/[REALM]@[REALM]
>> ? ? ? ? ? ? ? renew until 06/28/11 09:33:01, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
>> ? ? ? 06/21/11 09:33:03 ?06/21/11 19:33:01 ?nfs/[server hostname]@[REALM]
>> ? ? ? ? ? ? ?renew until 06/28/11 09:33:01, Etype (skey, tkt): des-cbc-crc, aes256-cts-hmac-sha1-96
>>
>>
>> --
>> 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
> --
> 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
>