RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 837855 - Mismatch of enctypes between principal and princpal
Summary: Mismatch of enctypes between principal and princpal
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: krb5
Version: 6.3
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: ---
Assignee: Nalin Dahyabhai
QA Contact: Zbysek MRAZ
URL:
Whiteboard:
Depends On: 837829
Blocks:
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
Environment:
Last Closed: 2013-02-21 08:37:08 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0319 0 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:

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 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
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 22:27:22 UTC 
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 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.

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.