none
Event ID 4 - KRB_AP_ERR_MODIFIED

    Question

  • I have two DCs, (let's call them server1 and server2) one of which (server2) had an issue after a reboot and subsequently needed to be restored to a previously created backup (4 months old) using the Windows 2008 system recovery.  After the restoration was complete, the time on server2 was out by a number of hours which resulted in replication problems even when the time was synched between servers.

    Event viewer showed kerberos error ID 4 and I could not access the active directory users and computers console on server1 (resulted in a error message "Target Principal Name is Incorrect").

    After doing some research on this matter, I successfully reset the password on server1 and server2 using the netdom reset password function as described http://support.microsoft.com/kb/325850/en-au I was confused to where I should perform this action, so I went through the process on both servers.

    Replication from server1 to server2 occurred and users are now able to log on, however I am still getting Event ID 4 errors on server1.

    The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server server2$. The target name used was ldap/server2.sta.local. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Please ensure that the target SPN is registered on, and only registered on, the account used by the server. This error can also happen when the target service is using a different password for the target service account than what the Kerberos Key Distribution Center (KDC) has for the target service account. Please ensure that the service on the server and the KDC are both updated to use the current password. If the server name is not fully qualified, and the target domain (STA.LOCAL) is different from the client domain (STA.LOCAL), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

    My instincts tell me that I may not have reset the password correctly (the order and reboot process is tricky) and should do it again, but I was curious to see if anyone had alternative ideas such as looking at PTR records in DNS.

    Many thanks

    Tuesday, May 18, 2010 12:48 AM

Answers

All replies

  • A quick way to resolve your issue would be to demote server2, clean up AD by following http://support.microsoft.com/kb/555846 , and promote server 2 to the DC (which actually you should have done in the first place - considering that your System State backup was 4 months old).

    Otherwise, you might want to try suggestions listed in http://social.technet.microsoft.com/Forums/en/winserverDS/thread/a14187e2-a769-4fb4-8c39-e21654451577

    hth
    Marcin

     

    • Proposed as answer by Meinolf WeberMVP Tuesday, May 18, 2010 11:15 AM
    • Marked as answer by Bruce-Liu Friday, June 04, 2010 6:18 AM
    Tuesday, May 18, 2010 12:59 AM
  • I have some additional questions:

    • What is the recommended procedure for restoring a 2008 server using the built-in Backup and Restore tool? Taking into account that the backup image may be several months old as in my case. The process seems flawed if issues like this can occur.
    • What are the risks involved in demoting and promoting? I have DNS running on server2, will I need to reconfigure DNS?

    Thanks

    Tuesday, May 18, 2010 5:42 AM
  • If you are referring to a full server recovery, the procedure is documented at http://technet.microsoft.com/en-us/library/cc772519(WS.10).aspx

    The backup "useful shelf life" is determined by the tombstone lifetime attribute - more info at http://support.microsoft.com/kb/216993

    As far as risks are concerned - as long as your DC is serving only as a domain controller/DNS server, and you have another domain controller in the same domain serving as a GC/DNS, and they both are in synch (i.e. the DC you are demoting does not contain any recent changes that have not replicated to the other DC), then the procedure should not have any longer term negative consequences. However, obviously during the period during which DC is demoted, it will not be accessible by domain members (both as their authenticating DC and DNS server) - so make sure you carry out the procedure during off hours. In addition, ensure that FSMO roles are transferred to the remaining DC.

    hth
    Marcin

    Tuesday, May 18, 2010 11:07 AM
  • Thanks Marcin, well said.

    I am almost back to normal here without the need to demote and promote, so I will battle on and see how I go. The demotion and promotion process may need to be performed if I don't succeed.

    One thing I am curious about is that I read somewhere that passwords are encyrpted every 7 days, so with that in mind, should a backup be created every 7 days?  In other words, if a back up is older than 7 days (as in my case) then Event ID 4 (kerberos error) will occur because there is a breakdown in trust between DCs.

    Wednesday, May 19, 2010 6:11 AM