Windows Server 2025 Duplicate SID Causes SMB Authentication Failure

Checo7/3/26About 2 min

Windows Server 2025 Duplicate SID Causes SMB Authentication Failure

After Windows Server 2025 installs a cumulative update, SMB access between AMI-cloned instances fails authentication with an "incorrect password" error, even though the password is correct. The root cause is the Machine ID validation mechanism detecting duplicate SIDs.

Symptom

After Windows Server 2025 installs the latest cumulative update, SMB access between instances cloned from the same AMI fails authentication with an "incorrect password" error, even though the password is correct.

The system log records Event ID 6167 (LsaSrv):

There is a partial mismatch in the machine ID. This indicates that the ticket
issued by user S-1-5-21-xxx has either been manipulated or it belongs to a
different boot session. Failing authentication.

NOTE: This can also happen if the machine was cloned without using sysprep.

Prerequisites

Windows Server 2025 with the latest cumulative update installed
Instance created via AMI clone without running Sysprep

Confirmation

Run on both machines:

$sid = (New-Object System.Security.Principal.NTAccount('Administrator')).Translate([System.Security.Principal.SecurityIdentifier]).Value
$machineSid = $sid.Substring(0, $sid.LastIndexOf('-'))
Write-Output "Machine SID: $machineSid"

If the Machine SID is identical on both, the problem is confirmed.

Temporary Workaround

Disable SID uniqueness check via the registry (Known Issue Rollback mechanism). Both SMB server and client need it:

New-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides' -Force
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Policies\Microsoft\FeatureManagement\Overrides' -Name '1517186191' -Value 0 -Type DWord
Restart-Computer -Force

Limitation: Valid until end of 2027; Microsoft will remove this bypass in a future security update.

Permanent Solutions

Option 1: Sysprep to regenerate SID (recommended)

For N machines with the same SID, keep 1 untouched and run Sysprep on the other N-1:

# In EC2, use EC2Launch v2
& "C:\Program Files\Amazon\EC2Launch\EC2Launch.exe" sysprep

Sysprep impact:

Item	Affected
C drive files/data	Not lost
Installed software	Retained (SID-bound licenses may need reactivation)
User profiles	Reset
Computer name	Reset to random
Domain membership	Leaves domain; must rejoin
IP address	Unchanged (EC2 private IP is on the ENI)
Windows activation	Reset (auto-reactivates via KMS on EC2)

Option 2: Third-party SID modification tool

Use SIDCHG to directly modify the Machine SID without unjoining the domain or going through OOBE:

sidchg64-3.0n.exe /R

Caveats: non-Microsoft tool with risk; after changing the SID you must repair domain trust (Test-ComputerSecureChannel -Repair); temporarily disable Defender real-time protection; handle EFS-encrypted files and BitLocker beforehand.

Sysprep Troubleshooting

Sysprep may fail with:

SYSPRP Package AppName_1.0.0.0_neutral__xxx was installed for a user,
       but not provisioned for all users.

Remove the problematic AppX package:

Get-AppxPackage -AllUsers *AppName* | ForEach-Object {
    Remove-AppxPackage -Package $_.PackageFullName -AllUsers -ErrorAction SilentlyContinue
}

Get-AppxProvisionedPackage -Online | Where-Object {
    $_.DisplayName -like "*AppName*"
} | Remove-AppxProvisionedPackage -Online

Prevention

Run Sysprep before creating an AMI to ensure every instance has a unique SID. Make this part of your image-build standard.