Bug 837855 - Mismatch of enctypes between principal and princpal
Summary: Mismatch of enctypes between principal and princpal
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: krb5
Version: 6.3
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Nalin Dahyabhai
QA Contact: Zbysek MRAZ
Depends On: 837829
TreeView+ depends on / blocked
Reported: 2012-07-05 15:23 UTC by Stephen Gallagher
Modified: 2013-07-03 13:16 UTC (History)
7 users (show)

Fixed In Version: krb5-1.10.3-5.el6
Doc Type: Bug Fix
Doc Text:
Clone Of: 837829
Last Closed: 2013-02-21 08:37:08 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0319 normal SHIPPED_LIVE krb5 bug fix update 2013-02-20 20:54:56 UTC

Description Stephen Gallagher 2012-07-05 15:23:28 UTC
+++ 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:

Comment 2 Nalin Dahyabhai 2012-07-05 17:44:14 UTC
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.

Comment 3 Stef Walter 2012-07-06 10:38:48 UTC
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?

Comment 4 Nalin Dahyabhai 2012-07-06 14:47:40 UTC
(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.

Comment 8 Nalin Dahyabhai 2012-08-09 22:27:22 UTC
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.

Comment 13 errata-xmlrpc 2013-02-21 08:37:08 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.