none
Kerberos

    Question

  • Hi,

    We made a mistake with a GPO which was supposed to have just adjusted the Kerberos settings for Windows 7 computers, unfortunately it has changed the settings on all servers and computers in the domain.

    No we are getting issues with not being able to log into member servers with the a domain username and password. This occurs now and then and a reboot of the machine fixes the issue for a period of time. We get Event ID 4625 when the Security Log with NULL SID login failures and in the System Log we are getting KRB_AP_ERR_MODIFIED errors every 120 minutes when it tries to refresh the Group Polices. My investigation has showed a few people have had this issue due to making the same mistake.

    So we had a GPO that set following:

    Network security: Configure encryption types allowed for Kerberos

    DES_CBC_CRC                            Enabled

    DES_CBC_MD5                           Enabled

    RC4_HMAC_MD5                         Enabled

    AES128_HMAC_SHA1                  Disabled

    AES256_HMAC_SHA1                  Disabled

    Future encryption types               Disabled                      

    This was only supposed to run on Windows 7 computers only but there was a mistake. So we now have the following registry entry on all servers and computers:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\kerberos\parameters

    supportedencryptiontypes=7

    This did not exists previously.

    So my method to fix this is:

    1.       Disable the GPO causing the issue

    2.       Login into each Domain Controller and run GPUPDATE/FORCE, then delete the registry entry and the keyname's Kerberos\parameters

    3.       Re-boot the Domain Controller

    4.       Repeat the exercise on all member servers.

    5.      For the workstations create a registry file that deletes the registry entries detailed above and add to login script processing.

    6.      Correct the GPO to only work on Windows 7 computers and re-enable.

    Please could those in the know please comment on my process as I don't want to make things worse!

    Thanks

    Andy

    Friday, June 21, 2013 6:19 AM

Answers

  • Hi,

    in regard of dns be sure to check forward and reverse lookup is ok for any affected server.

    In regard of the logon issues; did you find any other event ins ecurity log?

    I understand your primary goal for now is reversing the gpo you applied? The most common way to do this is applying a gpo that sets back the default settings. This gpo can be set to 'not configured' once the setttings are reapplied to all systems.

    This blog gives good insight on what happens behind the scene. So you can define the best value to configure.

    If you would like to continue the way you described, I see no real issue appearing from it. But do not forget to test this before implementing it on al your servers and clients!


    MCP/MCSA/MCTS/MCITP

    • Marked as answer by Ted Xie Friday, June 28, 2013 9:05 AM
    Friday, June 21, 2013 1:57 PM

All replies

  • Hi,

    my best recommendation would be to setup a test environment to avoid costly mistakes!

    Check the recommendation in http://technet.microsoft.com/en-us/library/jj852180(v=ws.10).aspx . It seems the configured policy is not incorrect and should be applicable from Windows 200 on. (However, it should not be needed either.)

    KRB_AP_ERR_MODIFIED errors are most commonly related to dns issues or due to duplicate sid's (cloned computers? Try this tool to find out)

    In my opninion you should take another look for security events that occur when a user login failed. please elt us know what you find!


    MCP/MCSA/MCTS/MCITP

    Friday, June 21, 2013 9:24 AM
  • Hi,

    Yes I have checked the DNS and everything looks fine. In regards to duplicate sid's the fact that the computers being affected is random and a few of them are physical computers that have been built from scratch would point away from duplicate sid's. I will double check with the tool though.

    The issues we are having did start after this GPO was put in place. the only other change was the password of the built in Domain Administrators password was changed.

    Thanks

    Andy

    Friday, June 21, 2013 1:32 PM
  • Hi,

    in regard of dns be sure to check forward and reverse lookup is ok for any affected server.

    In regard of the logon issues; did you find any other event ins ecurity log?

    I understand your primary goal for now is reversing the gpo you applied? The most common way to do this is applying a gpo that sets back the default settings. This gpo can be set to 'not configured' once the setttings are reapplied to all systems.

    This blog gives good insight on what happens behind the scene. So you can define the best value to configure.

    If you would like to continue the way you described, I see no real issue appearing from it. But do not forget to test this before implementing it on al your servers and clients!


    MCP/MCSA/MCTS/MCITP

    • Marked as answer by Ted Xie Friday, June 28, 2013 9:05 AM
    Friday, June 21, 2013 1:57 PM
  • I see a reason for KRB_APP_ERR_MODIFIED due to Encryption types supported on the server.

    When a TGS is issued to a client, it contains a ticket  for the server with a session key encrypted with the long term key of the server using the Encryption Type(as defined in the msDS-SupportedEncryptionType) attribute in AD.

    KDC read msDS-SupportedEncryptionType attribute and found that this server support AES and it encrypt the ticket with the AES. But on the client machine we have disabled the AES, so client failed to decrypt the ticket and logged an event id 4, KRB_APP_ERR_MODIFIED.

    I would suggest, recreate the issue in your test environment and apply above process to resolve it.

    Saturday, June 22, 2013 5:54 PM