Fix Kerberos & NTLM Auth Errors: Duplicate SID Issue
Why This Is Happening
I've seen this exact problem paralyze entire teams , users suddenly can't log in to shared resources, mapped drives drop silently, and the error messages Windows gives you are maddeningly vague. "The trust relationship between this workstation and the primary domain failed." "There are currently no logon servers available to service the logon request." Sound familiar? If you're running Windows 11 version 24H2 or the newer 25H2 preview builds and you've deployed machines from a master image, the root cause is almost certainly a duplicate Security Identifier , a duplicate SID.
Here's what a SID actually is. Every Windows machine, every user account, every group gets a unique Security Identifier, a string like S-1-5-21-3623811015-3361044348-30300820-1013. The domain controller uses this SID as the definitive identity token when issuing Kerberos tickets and validating NTLM challenges. It's not the computer name. It's not the IP address. The SID is what Active Directory trusts. When two machines on the same network carry the same SID, which happens when you clone a VM or deploy a disk image without running Sysprep first, Kerberos gets confused. The Key Distribution Center (KDC) sees a ticket request from what looks like a machine it already authenticated. Conflicts cascade fast.
On Windows 11 24H2 and 25H2 specifically, Microsoft tightened the Kerberos validation pipeline. Earlier builds were more forgiving about SID collisions in certain edge cases, particularly in workgroup and hybrid Azure AD join scenarios. That tolerance is gone now. The stricter enforcement is actually correct behavior, but it means environments that were quietly broken before are now visibly broken. You may have had duplicate SIDs for months without knowing it.
Who sees this? Predominantly IT admins who deployed Windows 11 24H2 images at scale using tools like MDT, SCCM, or VMware vSphere without generalizing the image first. It also hits home lab users who duplicated a VM and forgot that Sysprep step. In enterprise environments, the symptoms spread, one cloned machine breaks authentication for nearby machines because the KDC gets contradictory session data from what it believes is the same computer account.
The error messages don't help at all. Windows doesn't say "you have a duplicate SID." You get Event ID 4771 (Kerberos pre-authentication failed), Event ID 4776 (NTLM credential validation failed), or a generic Netlogon error pointing at the domain controller, none of which mention SIDs directly. That's exactly why this issue stays unsolved for so long on most machines.
Browse all our Microsoft fix guides → if you're dealing with related Windows 11 authentication or Active Directory issues.
The Quick Fix, Try This First
Before going deep into troubleshooting, confirm whether duplicate SIDs are actually the problem on your machine. Open an elevated PowerShell prompt (right-click Start → Terminal (Admin)) and run this:
whoami /userThat shows your current user SID. To check the machine SID specifically, the fastest method is using Sysinternals PsGetSid. Download it from the Sysinternals suite, then run:
psgetsid.exe \\COMPUTERNAME-1
psgetsid.exe \\COMPUTERNAME-2Compare the base SID (everything before the last dash-number). If two machines on your network return the same base SID, that's your answer. You have a cloned image problem.
For a single machine that needs immediate remediation, the fix is Sysprep with generalization. This resets the machine SID and clears the computer's identity so Windows generates a fresh unique one on next boot. Open an elevated Command Prompt and run:
C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /shutdownThe machine will shut down. When you power it back on, Windows will run the Out-of-Box Experience, generate a new unique SID, and prompt for initial setup. After that, rejoin the machine to your Active Directory domain via Settings → Accounts → Access work or school → Connect → Join this device to a local Active Directory domain.
One important note: generalize removes installed drivers and resets some configurations. For a production machine, do this during a maintenance window and have your application inventory ready.
Don't skip this step. Assuming you have a duplicate SID and running Sysprep on the wrong machine wastes time and can cause unnecessary disruption. Let's get proof first.
On the affected machine, open an elevated PowerShell window. Check the machine's own SID by querying the local SAM:
# Get machine SID via WMI
(Get-WmiObject -Class Win32_ComputerSystem).Name
$sid = (New-Object System.Security.Principal.NTAccount($env:COMPUTERNAME + "$")).Translate([System.Security.Principal.SecurityIdentifier])
$sid.ValueAlternatively, use PsGetSid from Sysinternals (free download, no install required). Copy PsGetSid64.exe to a folder and run from an admin prompt:
PsGetSid64.exeIt will output something like: Machine SID: S-1-5-21-1234567890-0987654321-1122334455
Run the same command remotely on every machine you suspect is a clone of the same image:
PsGetSid64.exe \\192.168.1.50
PsGetSid64.exe \\192.168.1.51If the S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX portion matches between any two machines, you've confirmed the problem. Document every affected machine hostname before moving to the next step. You'll need that list.
What you should see if it's working: Each machine returns a different 10-digit numerical sequence in the S-1-5-21 portion. No two machines should ever match.
Event Viewer gives you the exact authentication failure signatures. This confirms not just that SIDs are duplicated, but that active authentication failures are occurring as a result, which matters for documenting the incident and understanding scope.
Press Win + R, type eventvwr.msc, and hit Enter. Navigate to Windows Logs → Security. You're looking for these specific Event IDs:
- Event ID 4768, Kerberos TGT request. Look for failure codes
0x6(client not found in Kerberos database) or0x12(client credentials revoked). - Event ID 4771, Kerberos pre-authentication failed. Failure code
0x18means wrong password;0x6means the machine account isn't resolving correctly, a SID conflict symptom. - Event ID 4776, NTLM credential validation. Error code
0xC000006D(logon failure) or0xC0000064(user name does not exist) here often signals a SID resolution mismatch. - Event ID 5805, Session setup from a computer failed because the computer doesn't have a machine account. This one is almost always SID-collision-related on cloned machines.
To pull these without scrolling manually, use this PowerShell filter:
Get-WinEvent -LogName Security -FilterXPath `
"*[System[(EventID=4771 or EventID=4776 or EventID=5805)]]" `
| Select-Object TimeCreated, Id, Message | Format-ListWhat you should see if it's working: No new Event ID 5805 entries, and Event ID 4768/4771 entries should show success (0x0) rather than failure codes.
Before running Sysprep to regenerate the SID, cleanly remove the machine from the Active Directory domain. If you Sysprep while still joined, you can leave a stale computer account in AD that causes its own headaches later, duplicate computer objects, lingering DNS records, or Kerberos tickets bound to the old SID that linger in cache.
Go to Settings → System → About → Domain or workgroup. Click Change settings, then Change.... Select Workgroup, type a temporary workgroup name like WORKGROUP, and click OK. You'll be prompted for domain admin credentials to remove the account from AD, use them. This removes the machine account from the domain controller properly.
Alternatively, from an elevated PowerShell:
Remove-Computer -UnjoinDomainCredential (Get-Credential) -WorkgroupName "WORKGROUP" -Force -Restart:$falseDon't restart yet. After you get the "successfully removed" confirmation, also go to Active Directory Users and Computers on your domain controller and delete the old computer account manually. Navigate to the OU where the machine lives, right-click the computer object, and select Delete. This prevents the stale account from conflicting when you rejoin after Sysprep.
What you should see if it's working: The system properties dialog confirms the machine is in a workgroup, not a domain. The computer object is gone from ADUC.
Now the safe part. With the machine off the domain and your hypervisor snapshot taken, run Sysprep with the generalize flag. Open an elevated Command Prompt, not PowerShell, Command Prompt specifically, as Sysprep has historically been finicky about being launched from PS sessions.
cd C:\Windows\System32\Sysprep
sysprep.exe /generalize /oobe /shutdownThe /generalize flag is what actually regenerates the SID. It removes machine-specific data from the Windows installation. /oobe sets the machine to boot into the Out-of-Box Experience on next start. /shutdown powers the machine down cleanly when Sysprep finishes.
Sysprep logs its activity to C:\Windows\System32\Sysprep\Panther\setupact.log. If Sysprep fails, and it can fail when third-party software hasn't been properly generalized, check that log. Common blockers include Windows Store apps that can't be uninstalled (look for SYSPRP Package ... was installed for a user errors) and certain AV products. If you see those, run this first to clean up provisioned app packages:
Get-AppxPackage -AllUsers | Where-Object {$_.NonRemovable -ne $true} | Remove-AppxPackage -AllUsersAfter Sysprep completes and the machine shuts down, power it back on. Windows will boot into OOBE and generate a brand-new unique SID.
What you should see if it's working: The machine boots into the Windows setup/OOBE screen, prompts for region, keyboard layout, and user setup. When setup completes, PsGetSid should return a completely different SID than before.
After OOBE completes and you've set up the local admin account, rejoin the machine to your Active Directory domain. Go to Settings → Accounts → Access work or school, click Connect, then select Join this device to a local Active Directory domain. Enter your domain name (e.g., corp.contoso.com), provide domain admin credentials, and complete the join. Restart when prompted.
After the reboot and domain login, verify that authentication is working correctly. From an elevated PowerShell on the newly rejoined machine, run:
# Test Kerberos ticket acquisition
klist purge
klist get krbtgt
# Verify machine account in AD
nltest /sc_verify:corp.contoso.com
# Test NTLM fallback path
Test-ComputerSecureChannel -Verboseklist get krbtgt requests a Kerberos Ticket Granting Ticket from the KDC. A successful output shows a valid TGT with an expiration time roughly 10 hours out. If it returns error 0x6 or 0x7 here, the machine account in AD isn't right, go back to ADUC, check if there's a duplicate computer object, and delete the stale one.
nltest /sc_verify checks the secure channel between the machine and the domain controller. You want NERR_Success 0x0 back. Anything else means the Netlogon service can't establish trust, rerun Test-ComputerSecureChannel -Repair -Credential (Get-Credential) to reset the secure channel without re-imaging.
Also confirm the new SID is unique by running PsGetSid one more time and cross-referencing against your list of other machines from Step 1. The base SID must now be different from every other machine on the network.
What you should see if it's working: nltest returns NERR_Success, klist shows a valid TGT, and users can authenticate to shared resources without errors.
Advanced Troubleshooting
The five steps above handle the majority of duplicate SID cases. But in larger enterprise environments, or in scenarios where Sysprep isn't an option, you need more surgical approaches. Here's what I reach for when the standard path is blocked.
When Sysprep Is Blocked: NewSID Alternatives
Sysinternals NewSID was deprecated back in 2009 and Mark Russinovich himself stated that SID duplication isn't actually a security problem on workgroup machines, but on domain-joined machines with Kerberos in play, it absolutely is. In Windows 11 24H2/25H2, Microsoft's own guidance confirms this. Since NewSID is officially dead, your alternatives are: Sysprep (covered above), deploying a properly Sysprepped image, or using the Windows System Image Manager unattend.xml with <CopyProfile>false</CopyProfile> to ensure generalization happens at deploy time.
Group Policy and Kerberos Policy Adjustments
If machines are intermittently failing Kerberos authentication even after SID remediation, check your Kerberos policy in Group Policy. Open Group Policy Management Console → Default Domain Policy → Computer Configuration → Windows Settings → Security Settings → Account Policies → Kerberos Policy. The key setting is Maximum tolerance for computer clock synchronization, it defaults to 5 minutes. A time skew greater than 5 minutes between a client and KDC will cause Kerberos to reject tickets outright, with error code KRB_AP_ERR_SKEW (0x25). Run w32tm /query /status on affected machines to check time sync status.
Registry, Where the Machine SID Actually Lives
For reference, the machine SID is stored in the registry at:
HKEY_LOCAL_MACHINE\SECURITY\SAM\Domains\Account
Value: F (binary)Do not manually edit this value. It's mentioned here for diagnostic purposes only, Sysprep handles the regeneration correctly and safely. Manually editing binary SID data in the SAM is how you brick a machine.
Netlogon Debug Logging
For stubborn cases where authentication fails after SID remediation, enable Netlogon debug logging to capture exactly where the handshake breaks:
nltest /dbflag:0x2080ffffLogs write to C:\Windows\debug\netlogon.log. Look for lines containing LOGON_FAILURE or ACCOUNT_DISABLED. The machine name next to those entries tells you which computer account in AD is causing the conflict. Disable debug logging when done:
nltest /dbflag:0x0Azure AD / Hybrid Join Considerations
If your Windows 11 24H2 machines use Hybrid Azure AD Join, duplicate SIDs break both the on-prem Kerberos path and the Azure AD device trust simultaneously. After Sysprep and domain rejoin, you also need to re-register the device with Azure AD. Run from an elevated prompt:
dsregcmd /joinThen verify with dsregcmd /status, you want AzureAdJoined: YES and DomainJoined: YES both showing.
0x12 (account revoked) or 0x18 (wrong password when password hasn't changed), escalate to Microsoft Support. These codes can indicate a corrupted KRBTGT account password or a KDC certificate problem in certificate-based Kerberos (PKInit) environments, both of which require Microsoft's backend tooling to diagnose safely.
Prevention & Best Practices
I know it feels like this should be obvious in retrospect, but the duplicate SID problem catches experienced admins off guard constantly, especially as teams scale deployment and automate imaging pipelines. The fix is easy once you know the cause. Preventing it from happening again just takes building the right habits into your deployment workflow.
The single most important rule: always Sysprep before capturing an image. Every imaging tool, MDT, SCCM/MECM, Packer, Clonezilla, Veeam, VMware Snapshot clones, should have Sysprep generalization as a mandatory final step before capture. Never capture a running machine. Never clone a running VM by taking a snapshot and deploying it directly without generalizing first.
In MDT and SCCM task sequences, the Prepare Windows for Capture task runs Sysprep automatically if configured correctly. Double-check that your task sequence includes this step and that it runs before the Capture the Reference Machine task. It's easy to accidentally bypass it when customizing task sequences.
For VMware environments, use the Guest Customization Specification when deploying from templates. This runs Sysprep automatically on first boot. In Hyper-V, the equivalent is using differencing disks from a properly generalized parent VHDX rather than copying the VHDX directly.
In Windows 11 24H2 specifically, Microsoft added stricter enforcement for Autopilot pre-provisioned deployments, make sure your Autopilot profiles include "deviceNameTemplate" with a unique naming pattern. Duplicate device names won't cause SID duplication on their own, but they're a signal that your deployment pipeline isn't generating unique identities properly, which often correlates with SID problems.
- Add a PsGetSid scan to your post-deployment checklist, run it on every newly deployed machine and compare against the previous machine before adding to the domain.
- Set a Group Policy alert: use a scheduled task via GPO to run
nltest /sc_verifyweekly and log failures to the Application event log with Event ID 1000, you'll catch SID conflicts before users notice them. - Keep your Sysprep answer file (unattend.xml) in source control alongside your image build scripts, this ensures the generalization step is never accidentally removed from the pipeline.
- For VDI environments with non-persistent desktops, use a dedicated machine account pool in AD rather than re-using the same computer object, each pool slot needs its own unique, pre-created computer account to avoid SID collisions at scale.
Frequently Asked Questions
How do I check if two Windows machines have the same SID without downloading extra tools?
You can do it with built-in PowerShell. On each machine, run (New-Object System.Security.Principal.SecurityIdentifier([byte[]](Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Cryptography" -Name MachineGuid).MachineGuid, 0)).Value to get the machine GUID, though for the actual SAM SID, PsGetSid from Sysinternals is more reliable. Alternatively, query WMI: Get-WmiObject -Class Win32_Account | Where-Object {$_.Name -eq $env:COMPUTERNAME + "$"} | Select-Object SID. If any two machines return matching S-1-5-21 base values, you have a collision.
Will Sysprep /generalize delete my files and installed applications?
Sysprep with /generalize removes hardware-specific configuration, resets Windows Activation, and strips out machine-specific security identifiers, but it does not delete user files or uninstall applications in most cases. However, it does remove driver packages from the driver store, which means some hardware may require re-detection after the next boot. On domain-joined machines, user profiles stored locally may behave unexpectedly post-generalize. Always take a full system backup or hypervisor snapshot before running it, especially on production machines.
My Sysprep is failing with error "Sysprep was not able to validate your Windows installation." What now?
Check the Sysprep log at C:\Windows\System32\Sysprep\Panther\setuperr.log, that file has the specific failure reason. The most common culprits on Windows 11 24H2 are: Windows Store apps installed for a specific user account that can't be generalized (fix by running Get-AppxPackage -AllUsers | Remove-AppxPackage -AllUsers), third-party antivirus products with kernel-level drivers, and Microsoft Office Click-to-Run installations. For Office specifically, run the Office Deployment Tool with a <Remove> element in the config XML to uninstall before Sysprep, then redeploy from your RDS/Intune pipeline post-image.
Is this the same issue as the "trust relationship between workstation and primary domain failed" error?
Not always, but duplicate SIDs are one of the causes for that error, yes. The more common cause of the trust relationship error is a machine secure channel that has expired because the computer account password hasn't synchronized with the domain in over 30 days (the default rotation cycle). You can fix the secure channel quickly without Sysprep by running Test-ComputerSecureChannel -Repair -Credential (Get-Credential) in PowerShell. If that command fixes the login but the error returns again within days, that's a stronger signal pointing to the SID collision problem described in this guide.
Does this affect Azure AD Joined machines or only on-premises Active Directory?
It affects both, but differently. Pure Azure AD Joined machines use a different device identity mechanism, the Azure Device ID, and are somewhat less susceptible to the classic SID collision issue. However, on Windows 11 24H2, Hybrid Azure AD Joined machines (joined to both on-prem AD and Azure AD) are fully affected because they rely on on-premises Kerberos for internal resource access while using Azure AD tokens for cloud services. After Sysprep and domain rejoin, run dsregcmd /join to re-establish the Azure AD device trust separately, then verify with dsregcmd /status.
We have 50+ cloned machines affected. Is there a way to batch-fix this without doing each one manually?
Yes, if you can push commands remotely, use a combination of PowerShell Remoting and your deployment tooling. First, create a new properly-Sysprepped reference image immediately and halt further cloning. For the 50 affected machines, you have two paths: redeploy from the clean image (fastest if you have MDT/SCCM in place and machines have minimal customization), or script the unjoin/Sysprep/rejoin process using SCCM or Intune's remote script execution feature. Schedule it as a maintenance window task, target the machines by their matching SID, which you can enumerate with PsGetSid across the subnet. Expect each machine to need roughly 20–30 minutes of downtime for the Sysprep cycle.