On 11/18/2016 12:15 PM, Dameon Wagner wrote: > Before I explain why I think we're seeing issues, it might be simplest > if I first ask: Is there a configuration option that we can set to > use the "old behaviour", and have multiple PA-ETYPE-INFO2-ENTRY items > returned?
No; we didn't expect the change to cause problems, and making it configurable would have mostly defeated the purpose of making the change. > Clearly, in this example, because the client is asking effectively for > AES256, and the krbtgt only has AES128, the KDC correctly responds > with KDC_ERR_ETYPE_NOSUPP. My gut feel is that the Windows client > code is at fault for not AS_REQ'ing with it's full set of supported > enctypes in later attempts, but the chances of getting that fixed are > ... shall we say very small? I agree that the Windows client is at fault. The AS-REQ supported enctype list is used to negotiate both the reply key and the ticket session key. If the client has a notion of what the reply key enctype should be, it can put that enctype first, but it should not omit other supported enctypes from the list. We discovered this ourselves when changing the behavior of kinit -k in MIT krb5 (see http://krbdev.mit.edu/rt/Ticket/Display.html?id=2131 ). Getting this fixed on the Microsoft end might be possible, but it's certainly not likely to be the path of least resistance for you at this time. Unfortunately, neither backporting the 1.14 tgt rekeying fixes nor forward-porting the 1.13 pa-etype-info2 behavior is likely to be easy, so I can't offer a solution better than the ones you've already determined. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
