Bug 837855 - Mismatch of enctypes between principal and princpal
Mismatch of enctypes between principal and princpal
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: krb5 (Show other bugs)
6.3
Unspecified Unspecified
medium Severity medium
: rc
: ---
Assigned To: Nalin Dahyabhai
Zbysek MRAZ
:
Depends On: 837829
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-05 11:23 EDT by Stephen Gallagher
Modified: 2013-07-03 09:16 EDT (History)
7 users (show)

See Also:
Fixed In Version: krb5-1.10.3-5.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 837829
Environment:
Last Closed: 2013-02-21 03:37:08 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Stephen Gallagher 2012-07-05 11:23:28 EDT
+++ 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:

http://mailman.mit.edu/pipermail/krbdev/2012-April/010768.html

https://github.com/krb5/krb5/commit/d1da158f47ea604bed4d5db5e98a976a9e54ccd0

https://github.com/krb5/krb5/commit/8230c4b7b7323cdef2a6c877deb710a15380f40f

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.

http://mailman.mit.edu/pipermail/krbdev/2012-July/010998.html

https://github.com/krb5/krb5/commit/61659df1036d1ad6d6891293f5949e720a2028f7

https://github.com/krb5/krb5/commit/7266becb5590fdf5b10463fe22bfd67650e24975

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 13:44:14 EDT
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 06:38:48 EDT
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 10:47:40 EDT
(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
http://pkgs.devel.redhat.com/cgit/rpms/krb5/tree/krb5-1.9-etype-loop.patch?h=rhel-6.3

>              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 18:27:22 EDT
The test setup is perhaps best described here:
https://bugzilla.redhat.com/show_bug.cgi?id=748407#c0

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 03:37:08 EST
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.

http://rhn.redhat.com/errata/RHBA-2013-0319.html

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