Category: Active Directory

Error message

Error “Trust Relationshitp between Workstation and Primary Domain failed”, is the most encountered message when you are dealing with Active directory domain services.

If the Secure Channel is Broken between Domain controller and workstations

When a Computer account is joined to the domain, Secure Channel password is stored with computer account in domain controller. By default this password will change every 30 days (This is an automatic process, no manual intervention is required). Upon starting the computer, Netlogon attempts to discover a DC for the domain in which its machine account exists. After locating the appropriate DC, the machine account password from the workstation is authenticated against the password on the DC.
If there are problems with system time, DNS configuration or other settings, secure channel’s password between Workstation and DCs may not synchronize with each other.

A common cause of broken secure channel [machine account password] is that the secure channel password held by the domain member does not match that held by the AD. Often, this is caused by performing a Windows System Restore (or reverting to previous backup or snapshot) on the member machine, causing an old (previous) machine account password to be presented to the AD.

Resolution

Most simple resolution would be unjoin/disjoin the computer from the domain and rejoin the computer account back to the domain.
(this is a somewhat similar principle to performing a password reset for a user account)

Or.

You can go ahead and reset the computer account using netdom.exe tool
netdom reset ‘machinename’ /domain:’domainname

 

How to fix a USN Rollback condition

a USN Rollback condition that had been caused by some virtualization work.  There has been some discussion in the comments in that post about what to do when you have a single domain controller that thinks it is in a USN Rollback condition (eg has disabled outbound replication and paused the Net Logon service).

First Demote all but one DC by force if necessary and it will most likely be necessary go to the last remaining DC launch computers and users, go to domain controllers and delete there computer objects, at that point any FSMO services will be transferred to the last DC.

Logic would suggest that once a DC knows it is the only DC in the Forest that it would shake off the USN Rollback blues and start humming away normally again.  Not the case unfortunately.

Apparently this fix is quite dangerous and not for the faint of heart.  My heart is not the least bit faint, particularly when it comes to my VMWare test environment, so I didn’t mind testing this out.  At the very least you should make sure you have a backup of the server you can go back to if this doesn’t work.

To get a single domain controller out of USN Rollback:

1. Open Regedit
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
3. Locate the key “Dsa Not Writable”=dword:00000004
4. Delete the entire key
5. Enable replication by running repadmin /options servername -DISABLE_OUTBOUND_REPL and repadmin /options servername -DISABLE_INBOUND_REPL
6. Reboot

Once your domain controller has rebooted you should find that NetLogon is running again and repadmin /options no longer shows replication as being disabled.