An AS-REQ contains (in the KDC-REQ-BODY) an etype field containing "the desired encryption algorithm to be used in the response" (RFC 4120 section 5.4.1). The KDC must choose three keys for the response: 1. The reply key, which must be a key the client possesses or can compute. 2. The ticket session key, which must be of an enctype supported by the client and the server. 3. The ticket encryption key, which must be a key the server possesses. The KDC-REQ-BODY etype list is used for the first and second keys, while the server's supported enctypes (either from its set of keys or a string attribute) is used for the second and third keys. If a client possesses a limited set of possible reply keys, the implementor may restrict the etype field to the set of enctypes corresponding to those keys. Heimdal does this when getting initial credentials with a keytab. MIT krb5 briefly did this for kinit -k on the master branch between 1.10 and 1.11, but now sends all supported enctypes with the keytab key enctypes moved to the front (see issues 2131 and 7190). Based on http://mailman.mit.edu/pipermail/kerberos/2016- November/021521.html it appears that Windows clients also do this: at login time they compute a key set from the password and ETYPE-INFO-2 information, and then when refreshing tickets they send an etype list containing only the enctypes of those keys. If a client does this, session key negotiation may fail if the server's supported enctypes (as determined by the KDC) do not intersect with the client's transmitted etype list. The fault here likely belongs to the krb5 protocol or to the client, but with many Windows clients in the field exhibiting this behavior, our KDC should try to work around the issue. The Windows interop case is exacerbated by the change in the MIT krb5 1.14 KDC to send only one etype-info entry in AS-REPs (ticket 8199). With only one etype-info entry sent, the client computes only one reply key, and sends an even more restricted etype list for ticket refreshes than it did when talking to previous versions of the MIT krb5 KDC. We briefly had a workaround in the KDC (from ticket 7190) which fell back to assuming that local TGT principals have support for all permitted enctypes. The code for that workaround could be improved (it should not use the realm-global variable tgs_server), but the general idea should address most cases where this issue arises. This workaround will not address AS-REQs where the server principal is different from the local krbtgt principal, but those cases should be rare.