Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: binary MIME-Version: 1.0 X-Mailer: MIME-tools 5.427 (Entity 5.427) RT-Send-CC: X-RT-Original-Encoding: iso-8859-1 Content-Length: 1207 This problem typically occurs when both of the following are true: * A client makes an AS-REQ with an overly restrictive (for the session key) set of etypes. * The krbtgt/REALM principal has a small set of keys (perhaps just one key), and no session_enctypes string attribute to override it. Given that session_enctypes can be used to work around the problem, I am now leaning towards documentation rather than a code change. The proposed workaround assumes that the krbtgt service implicitly supports all enctypes permitted by this KDC, rather than the set of enctypes present in the key data (although the enctypes present in the key data take priority). That assumption could make some problems more difficult to diagnose in realms with mixed KDC versions. For example, if a realm has a mix of 1.15 and 1.14 KDCs, and a client makes an AS-REQ with only aes-sha2 enctypes in the etypes field, the 1.15 KDC might issue a ticket that works with the 1.15 KDCs and not with the 1.14 KDCs. That would be a lot more confusing than an ETYPE_NOSUPP error. At a minimum, if we do add a workaround to the KDC, it should strictly respect any session_enctypes attribute on the krbtgt/REALM entry.