KRB5KDC_ERR_ETYPE_NOSUPP and enctype negotiation in mixed windows environments

[Ben H]

Thanks Ben,

I don't know if its fair to label this is a "misconfigured realm"
scenario.  That being said, there are certainly ways around this - at leas
one of which you mentioned:

1) Migrate off 2003 entirely
2) Move your PDC role (and all FSMO roles) onto your 2008+ servers.  This I
believe is arguably the best answer, since if you are introducing upgraded
DCs/KDCs you should move the critical functions to them.
3) Disable AES on your 2008 servers if your domain is still at 2003
Functional Level.  The only drawback here is AES can't be used for session
keys between those systems that support it.

So when we talk about "misconfigured realm" you could argue that it is
misconfigured because one of the 3 above are not being met.  While I could
argue that those could be best practices, they aren't considered
misconfigurations.  While admittedly, this is less likely a problem now
than it was say 5+ years ago when 2008 was first released this is a
relatively straight forward environment: a 2003 Domain that has had one or
more 2008 DCs introduced.  While I do think #2 above is "best practice",
there is nothing that I am aware of that required one to move the PDC (or
any FSMO role) to a 2008 DC introduced into a 2003 environment.

I honestly believe that this is more of a bug/design problem in AD.  When
the 2008 DC forwards the client request to the 2003 DC, it doesn't
negotiate a separate exchange to include enctypes or new keys - it simply
sends the client packet onto the DC only changing the Network and DLL
addresses.  In essence, the 2008 DC assumes that since the client was able
to negotiate AES with it, that some other KDC should also be able to speak
AES, without even asking.

I'll admit I have worked almost exclusively with AD KDCs, though I have
worked with MIT clients as well.  It seems to me from my reading of MIT
documentation that an MIT client and KDC will generally use the same
enctype for both the session keys and the TGT/TGS.  With AD it isn't
uncommon to see a TGT in RC4 format, but AES session keys negotiated.

This (re)negotiation capability described in my link:

"This means that a Vista/Win7 client will initially attempt to use AES when
talking to a Domain Controller during the Kerberos pre-authentication
stage, Windows Server 2003 DC‘s on the other hand don‘t support using AES
with Kerberos which is why they log the event and ask the client to try
again with one of algorithms the DC supports (which usually ends up as RC4)"

Seems to me a poor design decision on MS from the perspective of
inter-operability as it lends itself to other design decisions which can
use a "fall-back" instead of fool proof design.

On Wed, Oct 1, 2014 at 12:45 PM, Benjamin Kaduk <kaduk at mit.edu> wrote:

> On Tue, 30 Sep 2014, Ben H wrote:
>
> > Just discovered an issue in an environment with mixed Win 2003 and 2008
> R2
> > servers that I'm surprised I haven't seen before, nor can find much of
> > anybody reporting it previously.
>
> I would expect that people are trying to migrate off of Win 2003, since it
> goes EoL on July 14, 2015 (less than a year away).
>
> > So the "issue" from a behavioral standpoint is that the Window's Kerberos
> > implementation appears to be able to re-negotiate a lower/different
> > encryption type when presented with ETYPE_NOSUPP, but the MIT
> > implementation does not seem to do this.
>
> I believe that this MIT behavior is deliberate/intentional, in that do not
> generally retry/fallback on KDC requests other than retransmits or
> fallback to master to try and cope with password changes.  (I exclude
> trying different transport protocols from considerations.)
>
> > This can be solved, to the best of my knowledge, by doing one of the
> > following:
> > 1) Move the PDC role to a system that supports AES encyption.
> > 2) Disable AES encryption entirely - either on the 2008 KDCs, or on the
> MIT
> > clients
>
> I believe that either of these will eliminate the failure scenario you
> have described.  But there may be other tradeoffs...
>
> > Neither of these solutions are necessarily attainable in a given
> > environment.
> >
> > It would seem the least impactful change might be to remove AES from
> > default_tkt_enctypes and/or permitted_enctypes.  However, this would mean
> > that AES can never be used.
> > Since some of the DCs (2008+) do support AES session keys, we are in
> > essence weakening some of our potential exchanges.
> >
> > Is there something else that should be happening that isn't on my MIT
> > clients regarding re-negotiating an enctype?  Is there a configuration
> > settings that might help?
>
> My own opinion is that this is an error in the KDC/realm configuration, in
> that the administrator has created (presumably unknowingly) a situation
> where a KDC claims to support an encryption type but then doesn't actually
> fully support it (when it is proxying requests to a PDC that doesn't
> support it).  I'm not really convinced that there's a need to add more
> complexity to the client to work around a misconfigured realm.  (I don't
> think there are any existing knobs that would help other than the blanket
> disabling of AES you already know about.)
>
> > Is this a behavioral difference that is well known and, if so, are there
> > any plans to allow it to behave more like a Window's system in this
> > scenario to allow a more robust behavior?
>
> I don't think there are plans along this line.  Note that your "more
> robust behavior" may well be someone else's "insecure behavior".
>
> (Also, we have talked about deprecating the arcfour enctype entirely for
> kerberos; I expect to see that happen within the next few years.)
>
> -Ben
>