Bug 837855
Summary: | Mismatch of enctypes between principal and princpal | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Stephen Gallagher <sgallagh> |
Component: | krb5 | Assignee: | Nalin Dahyabhai <nalin> |
Status: | CLOSED ERRATA | QA Contact: | Zbysek MRAZ <zmraz> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6.3 | CC: | dpal, ebenes, jplans, nalin, nathaniel, sgallagh, stefw |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
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 08:37:08 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 837829 | ||
Bug Blocks: |
Description
Stephen Gallagher
2012-07-05 15:23:28 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. 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 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. 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. 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 |