+++ This bug was initially created as a clone of Bug #837829 +++
Samba 3 generates keytabs for a static list of enctypes (arcfour-hmac, des-cbc-md5, des-cbc-crc). When using krb5 < 1.11.0 to kinit using a keytab on a realm running AD 2008 (which supports AES), the kinit fails due to mismatched enctypes.
This is because the strongest supported enctype is chosen by default. In this case AES is supported by both the client and KDC. However then during preauth krb5 tries to load an AES key entry from the keytab, and it is not present.
This was discussed and patched in krb5 a while back:
Recently a number of corner cases exposed flaws in this patch to do with session keys. Slightly different corner cases exist with both MIT KDC and AD 2008 when DES is in use. Instead of requesting only the enctypes in the keytab, we request all the default enctypes, but sort those in the keytab first, indicating preference.
We may need to backport these patches to earlier packages of krb5, in order to facilitate use of samba3 generated keytabs with AD 2008 (for example in sssd).
In bug #811375 we tried to have sssd work around the problem, but are new unable to fix the corner cases above due to lack of API in krb5:
Stef or Stephen, have you seen this on 6.3? We had a different patch in the queue for the original problem (bug #748528) for 6.3, one that didn't alter the list of enctypes in the AS request.
While this limited its usefulness to cases where preauthentication was used (which is why I ultimately ended up preferring approach which was taken upstream, but not switching to it because what we had had already been tested), it also suggests that we don't (yet) trigger the problem outlined here.
I haven't tested this in RHEL 6.3.
I may be missing something obvious, but couldn't find the link to the patch in that bug. It seems like the krb5.conf workaround listed in that bug would do the trick though. Did you end up deploying that in the default krb5.conf for 6.3?
(In reply to comment #3)
> I haven't tested this in RHEL 6.3.
> I may be missing something obvious, but couldn't find the link to the patch
> in that bug.
It wasn't attached there. See
> It seems like the krb5.conf workaround listed in that bug would
> do the trick though. Did you end up deploying that in the default krb5.conf
> for 6.3?
No, the goal was to avoid depending on the workaround.
The test setup is perhaps best described here:
In its current versions, when a client workstation joins a Windows domain (when "net join" is used), Samba will only store RC4 and DES keys for the client in the system's keytab, and more importantly, it will not store any AES keys (this latter point should be verified by running "klist -k -e").
If you then attempt to run "kinit -k" to get credentials using the system's keys, the default encryption type support and preferences on the client and server should cause AES to be the selected encryption type. The client, however, will fail to authenticate to the KDC because of a combination of things: 1. that there is no AES key in the keytab, and 2. that while both client and server support other encryption types for which they have keys (RC4, at least), none of the other types are used.
We've gone through multiple approaches to fix this, but the end result when it's fixed is that the "kinit" command (and by extension, routines in applications which also attempt the same thing) should succeed.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.