Windows Server: Identify and Repair a Broken Secure Channel on an Active Directory domain controller

• Replication fails between an affected DC and others in the domain. The reason given for the failure may vary, but "The target principal name is incorrect" is a strong indicator of a broken secure channel.
  • Result codes associated with this error include -2146893022 and 0x80090322. These codes may appear in repadmin output or events in the Directory Service event log.
• "The trust relationship between this workstation and the primary domain failed" is another error associated with a broken secure channel.
• If the affected DC is a DNS server, the DNS Manager console may produce an "Access denied" error when connecting to that DC.

The DC's own copy of its computer account password does not match the corresponding password stored in the Active Directory (AD) database. When these passwords differ, a secure channel cannot be established. More information about computer account passwords in AD can be found in Additional Info below.

The Test-ComputerSecureChannel PowerShell command with the -Repair switch can repair a broken secure channel on a DC. (There are other methods, but this command is simple and straightforward.) Perform these steps on the affected DC to repair its secure channel:

1. Skip this step if there is only one DC in the domain. Stop the Kerberos Key Distribution Center (KDC) service and set its startup type to Disabled.
   It may also be necessary to do this on other DCs in the domain, but the service must be left running on at least one DC. See Additional Information below.
2. Launch an elevated PowerShell prompt.
3. Run klist purge to delete existing Kerberos tickets.
4. Run Test-ComputerSecureChannel -server <good_dc> -repair -verbose.
   Replace <good_dc> with the name or IP address of a DC on which the KDC service is running.
5. The output of the command should indicate that the secure channel was successfully repaired:
   Figure 1: The secure channel was successfully repaired.
6. Force AD replication to and from the affected DC and confirm that it succeeds.
7. Reset the startup type of the KDC service to Automatic on all DCs and start the service. (In other words, undo what was done in step 1.)

Computer Account Passwords in Active Directory

Every domain-joined machine has a computer account in the AD database. Like user accounts, these computer accounts have passwords associated with them. These passwords are used to establish a secure communication path (a secure channel) between devices in the domain. Each machine stores a copy of its password locally, and another copy is stored in the AD database. Computer account passwords do not expire and do not require manual maintenance by users. They are exempt from password policies established for user account passwords.

By default, a domain-joined machine attempts to change its password every 30 days, though this interval can be changed. A password change is initiated by the domain-joined machine, not by a mechanism within AD. If a DC can be contacted, the machine's local copy of the password and the copy stored in AD will both change. If the machine cannot contact a DC, it does not change the local copy of its password.

These principles apply to DCs as they apply to other domain-joined machines. It is possible for a DC's local copy of its computer account password to be out of sync with the copy stored in AD. This is even possible, though rare, in a single-DC domain.

Stopping the Kerberos Key Distribution Center (KDC) Service

If there are multiple DCs in the domain, the KDC service must be stopped on the affected DC. Setting the service's startup type to Disabled is also recommended, to prevent the service from starting. Depending on the extent of the issue and the number of DCs in the domain, the service may need to be stopped on other DCs as well. If all other DCs in the domain are synchronized with each other (replicating without errors), stop and disable the service on the affected DC only. Otherwise, stop and disable it on any DCs that are failing to replicate. It must be left running on at least one DC. If possible, stopping the service on all DCs but one and specifying that DC as the target of the -server switch in step 4 should give good results.