Replication server has exceeded the tombstone lifetime and Secure channel between the DC’s broken
I asked myself what was the last thing done to the servers before I left yesterday and that was me restarting a somewhat dormant domain controller which was down for several days. I logged into that and went to the event viewer to see what the issue was and I noticed a crap load of Microsoft Event ID 4 error.
Apparently, Microsoft’s Kerberos Event ID 4 is cause by replication issues between both domain controllers, a broken secure between both domains or removing lingering objects between one of the domain controllers. With my problem, I had the replication issue and the broken secure issue between both domain controllers. I had to get my users online quick, so a dirty work-around was to shutdown the machine and restart [this work for some], remove the computer from the domain [last thing to do if everything fails] or reset their password and do the reset on the domain that is working correctly [this worked 75%].
If you have Windows Resource Tools installed on your server you can run a repadmin /showrepl serverName and check the status of your replication between your DC [Domain Controllers]
Also, I checked the operations master on domain controller that was having issues and the RID, PDC and Infrastructure were stating that the Operations master: “ERROR”. This wasn’t a good thing at all.
So how do you fix this problem?
Well, I had to do two things on my server to get it to start replicating again and letting users log into their machine without getting that trust issue warning.
First step was resetting KDC password within the domain controllers.
1. Stop the Key Distribution Center (KDC) service on the server you are having the replication issues on. To do so, open a Command Prompt, type net stop KDC, and press Enter.
2. Load Kerbtray.exe. You can do so by clicking Start, clicking Run, and then typing c:\program files\resource kit\kerbtray.exe and pressing Enter. You should see a little green ticket icon in your system tray in the lower right corner of your desktop.
3. Purge the ticket cache on Server2, right-click the green ticket icon in your system tray, and then click Purge Tickets. You should receive a confirmation that your ticket cache was purged. Click OK.
4. Reset the Server domain controller account password on the server that is working, which should be the active PDC emulator.
To do so, open a command prompt and type: netdom /resetpwd /server:server2 /userd:domain.com\administrator /passwordd:password, and then press Enter.
5. Synchronize the domain. To do so, open a command prompt, type repadmin /syncall, and then press Enter.
6. Start the KDC service on Server2. To do so, open a command prompt, type net start KDC, and press Enter. This completes the process, and the domain controllers should be replicating success-fully now.
The next approach that I did, which I strongly believe worked was forcing the replication process between both domain controllers.
I tried forcing the replication within Active Directory Sites and Services, but a nasty error popped up:
To fix this issue you have to modify the registry to allow for replication to happen when the tombstone lifetime is exceeded. You have to perform the following steps on both machines, DC1 and DC2.
1. Logon to the virtual machine domain controller using an account with administrator rights.
2. Open the Registry Editor.
3. Navigate to following registry key: HKLM\System\CurrentControlSet\Services\NTDS\Parameters.
4. Right-click in the right pane of the Registry Editor, point to New, and then click DWORD Value.
5. For the name of the value type the following name and then press Enter. “Allow Replication With Divergent and Corrupt Partner ”
6. Double-click the new value, enter 1 in the Value data text box, and then click OK.
7. Close the Registry Editor.
No need to restart your server because this registry change takes effect immediately. Once the change is implemented the tombstone lifetime error has occurred issue will stop and the next replication will be successful. You can check it with the repadmin /showrepl command:
Leave a Reply