The message “The target account name is incorrect” after restoring a Domain Controller (DC) typically means there’s a Kerberos authentication issue, often caused by a mismatch in machine account passwords or secure channel trust between domain members and the DC.

Let’s methodically go through why this happens and what you can do:

🔧 Common Reasons After a DC Restore

1. USN Rollback or Lingering Metadata

• If the DC was restored improperly (e.g., not using an authoritative restore when needed), Active Directory may detect it as outdated and refuse replication/authentication.
• This leads to trust errors and Kerberos ticket issues.

2. Computer Account Password Mismatch

• Every computer, including DCs, has a machine account with a password. If this DC was restored from an old image or snapshot, the machine account password in AD may not match the one on the local DC.
• Result: Kerberos auth fails with “target name is incorrect”.

3. SYSVOL or NTDS Database Corruption/Mismatch

• If ntds.dit or SYSVOL contents are out of sync, other DCs may no longer trust this one.

✅ How to Fix It

Let’s assume this is not your only DC (multi-DC environment). If it is your only DC, the situation is more recoverable, but you need to treat it differently.

🧪 Step-by-Step Diagnosis:

1. Check Event Logs

   • On the DC you restored, check Event Viewer → System and Directory Services logs.
   • Look for Event ID 5722, 5719, 4, 40960, 40961 – they can tell you if the trust relationship or Kerberos tickets are broken.

2. Check if the DC Can See Other DCs

   • Try to ping or nslookup other DCs and domain services.
   • Run nltest /dclist:yourdomain.local and nltest /dsgetdc:yourdomain.local to check discovery.

3. Test Secure Channel

   nltest /sc_verify:yourdomain.local
   

🔁 Fix Options Based on Cause

✅ OPTION 1: Rejoin the Domain (If not the only DC)

If this is a secondary DC:

1. Demote the DC:

   dcpromo /forceremoval
   

2. Reboot.

3. Rejoin to domain as a member server.

4. Promote again via Server Manager or Install-ADDSDomainController.

✅ OPTION 2: Reset Computer Account Trust

If you suspect only a machine account password mismatch:

Reset-ComputerMachinePassword -Server "OtherDCName" -Credential (Get-Credential)

Or use:

netdom resetpwd /server:OtherDC /userd:Domain\Administrator /passwordd:*

This attempts to reset the trust from the restored DC to another working one.

✅ OPTION 3: Authoritative vs Non-Authoritative Restore (for SYSVOL)

If the restore caused SYSVOL replication to fail:

• Check netlogon and sysvol shares: \\localhost\netlogon
• If they’re missing, follow BurFlags fix in Registry to make it authoritative or non-authoritative depending on scenario.

💣 If This Is the Only DC

If this is a single-DC domain and you restored it from a backup:

• Ensure ntds.dit, SYSVOL, and machine account passwords are consistent.
• Consider using Directory Services Restore Mode (DSRM) to recover.

In extreme cases, you may need to:

• Restore from a newer backup.
• Perform a metadata cleanup and promote a fresh DC.

🔮 Going Forward

If this is part of a larger network and you’re restoring DCs from snapshots or images, always:

• Use non-authoritative restore unless you explicitly need to override others.
• Document backup timestamps and plan around USN rollback issues.
• If using virtualization: avoid snapshot restores of DCs unless you’ve enabled VM Generation ID-aware backups (Server 2012+).

Would you like to walk through the recovery live step-by-step with specific commands based on your setup (e.g., single or multi DC, backup method, OS version)? That way, we can take the cleanest path forward.

Great question — this step must be run on the restored Domain Controller (the one you're having trouble logging into) in order to reset its machine account password with another working DC in the domain.

🧭 Breakdown of the Command:

Reset-ComputerMachinePassword -Server "OtherDCName" -Credential (Get-Credential)

• Reset-ComputerMachinePassword: This resets the secure channel to the domain by syncing the machine account password.
• -Server "OtherDCName": This should be the hostname (NetBIOS or FQDN) of another working Domain Controller that is healthy.
• -Credential: It prompts for domain admin credentials that have permission to reset the trust.

✅ Where to Run It:

Run it in PowerShell on the restored DC that’s showing the error.

🧱 Example:

Assume:

• You restored DC DC2
• The other healthy DC is called DC1
• You’re logged into DC2 (perhaps via local admin or DSRM)

Then you'd run this on DC2:

Reset-ComputerMachinePassword -Server "DC1" -Credential (Get-Credential)

When prompted, enter the credentials of a domain admin account, like:

DOMAIN\Administrator

⚠️ If You Can’t Log Into the Restored DC

If you’re totally locked out:

• Try booting into Directory Services Restore Mode (DSRM) using the DSRM password.
• Or log in with a cached local admin account (if one exists).
• If you can’t do either, you may need to force demote and re-promote as a new DC (we can go through that too if needed).

Let me know:

• What are the names of your DCs?
• Can you log into the restored DC at all (with local or DSRM)?
• Is this a 1-DC or multi-DC environment?

That’ll help chart the next safest step.