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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
