Trust relationship of all clients lost after backup restored of DC

Question

heres the issue. We got hit with the perfect storm and lost our only DC (yes I know but I dont get to make thoese decissions). We lost a ton of our backups when a raid array failed and hadent been pushed to the cloud becuase we cant get enough bandwidth to make things work. long story short. the last backup we had was 159 days old. sucks but its what we have. I got it up and running but now nothing trusts it. I tried the test-computersecurchannel -repair and netdom resetpwd. test-computersecurchannel -repair failes but netdom resetpwd succeeds....but doent fix anything. I also tried reseting a computer account in AD but no dice.

any advice to getting computers to trust this backup of a server that is this old?

Answer 1

Hi Scott Guenther,

Thank you for posting in the Microsoft Community Forums.

Confirm the integrity of the backup:

Ensure that the DC data restored from the backup is complete and undamaged.

Check system logs and application logs to confirm that there are no errors related to the backup recovery.

Synchronize time and date:

Ensure that the time and date are synchronized between all client computers and the restored DC. Unsynchronized time may cause Kerberos authentication to fail.

Reset computer passwords using netdom resetpwd:

You have tried using netdom resetpwd, but if it did not resolve the problem, make sure that you run this command as a domain administrator and that you specify the correct domain controller and credentials.

Run netdom resetpwd /Server:<DomainController> /UserD:<DomainAdmin> /PasswordD:<Password> again, where <DomainController> is the name or IP address of the restored DC and < DomainAdmin> is the username of the user with domain administrator privileges, and <Password> is the password for that user.

Check the DNS configuration:

Ensure that the client computer is configured to use the recovered DC as a DNS server.

Check the DNS service on the DC to make sure that it is able to resolve computer names and DNS records within the domain.

Verify the trust relationship using Test-ComputerSecureChannel:

Although you tried and failed before, after performing the above steps, try again to check the trust relationship between the client computer and the DC using Test-ComputerSecureChannel -Verbose.

If it still fails, try using the -Repair option to try to repair the trust relationship. Note, however, that the -Repair option may not solve the problem in some cases, especially if the DC's computer account has been marked as inactive in AD.

Check the computer account in AD:

In the AD Users and Computers console, check if the affected computer account is disabled or marked inactive.

If the computer account is disabled or marked inactive, re-enable it and reset the password.

Consider using Group Policy or scripts:

If multiple client computers are affected, you may consider using Group Policy or scripts to automatically reset computer passwords and repair trust relationships.

Rejoin the domain:

If none of the above steps resolve the issue, you may want to consider removing the affected computers from the domain and then rejoining the domain. This is usually a time-consuming process because it involves reconfiguring user and group policy settings on the computer.

Consider using AD recovery mode:

If your backups are very old and you are concerned about inconsistent data in AD, you might consider using AD's recovery modes (such as non-authoritative restore or authoritative restore) to try to restore AD to a consistent state. Note, however, that these operations carry risks and should be performed by an experienced administrator after careful planning.

Seek professional help:

If you are unfamiliar with the AD recovery process or encounter complex issues, consider seeking help from Microsoft Support or a professional IT service provider.

Best regards

Neuvi