KRB5KDC_ERR_ETYPE_NOSUPP and enctype negotiation in mixed windows environments

[Ben H]

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.

Well known issue:
2003 = Does not support AES
2008 = Supports AES (support for TGT only if Domain Functional Level >=2008)

Problem is compounded by scenario:
PDC Emulator is 2003R2, but other DCs are 2008....
http://technet.microsoft.com/en-us/library/cc780271(v=ws.10).aspx -
Section:How Domain Controllers Verify Passwords

"When a domain controller detects that an authentication attempt did not
work and a condition of STATUS_WRONG_PASSWORD, STATUS_PASSWORD_EXPIRED,
STATUS_PASSWORD_MUST_CHANGE, or STATUS_ACCOUNT_LOCKED_OUT is returned, the
domain controller forwards the authentication attempt to the primary domain
controller (PDC) emulator operations master. Essentially, the domain
controller queries the PDC to authoritatively determine if the password is
current. The domain controller queries the PDC for this information because
the domain controller may not have the most current password for the user
but, by design, the PDC emulator operations master always has the most
current password."

What happens here with an MIT client is that if the initial AS-REQ exchange
happens between a 2008 system, AES will be negotiated.  If the user
principal's account is set to one of the above values
(STATUS_PASSWORD_MUST_CHANGE would be the most problematic one), the 2008
DC "queries the PDC to authoritatively determine if the password is
current."  In actuality, what the 2008 system does is proxy/forward the
client's AS-REQ over to the PDC, which will reply to it as if it were a
standard client.  The 2008 system will then proxy/forward that response
back to the client.  The issue is that although the 2008 KDC properly
negotiated AES, the 2003R2 PDC/KDC does not support that enctype and will
reply to the 2008 with KRB5KDC_ERR_ETYPE_NOSUPP which is then sent back to
the originating MIT client and the login/kinit fails.

Windows clients, it appears, when receiving the KRB5KDC_ERR_ETYPE_NOSUPP
will attempt a new AS-REQ using a different enctype (RC4 it seems -
http://bit.ly/1ua440o).  This AS-REQ will once again be forwarded from the
2008 KDC receiving it to the 2003R2 PDC which, since it can support that
enctype, respond with the appropriate KRB-ERROR code ( KRB5KDC_ERR_KEY_EXP
NT Status: STATUS_PASSWORD_MUST_CHANGE).  This will then be sent to the
client which will perform the appropriate password change (kpasswd/464
usually) and then perform a new AS-REQ which can complete over AES since
there are no longer any account restrictions.

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.

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

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?
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?

Thanks for all input!

BH