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.