Windows 11 Printer “Access Denied” in Domain Environment caused by Identical Machine SID

by

In a large corporate domain environment, several Windows 11 workstations suddenly stopped connecting to shared USB printers hosted on other domain-joined PCs.

When attempting to connect to USB Printer:

  • “Access Denied”
  • Unable to install printer
  • Connection refused during \hostname\printer mapping

The issue appeared after Windows 11 updates.

Before the update everything worked normally.

Initial Checks (All Looked Fine)

We verified:

  • NTFS permissions
  • Share permissions
  • Print spooler service
  • Firewall rules
  • DNS resolution
  • Domain trust status
  • SMB connectivity

Everything was correct.

Yet the printer connection failed with “Access Denied”.

The Root Cause

After deeper investigation, we discovered:

Two domain-joined computers had identical Machine SID values.

This was likely caused by:

  • OS cloning without proper Sysprep
  • Image deployment without /generalize
  • Legacy backup/restore methods

Even though both machines were properly joined to the domain, their local machine SID was identical.

Why It Broke After Windows 11 Update

Recent Windows 11 security updates introduced stricter validation in:

  • RPC authentication
  • Print Spooler security
  • Access token validation
  • SMB identity checks

When one machine attempted to connect to the printer on the other:

  • Security token validation conflicted
  • SID collision broke identity trust evaluation
  • Windows rejected access

Essentially, the system could not properly distinguish the machines during authorization checks.

Older Windows builds were more tolerant.
Windows 11 security hardening exposed the issue.

The Fix

Since the Machine SID was duplicated, we regenerated it on one of the affected machines.

After generating a new SID and rebooting:

  • the machine received a new unique base SID
  • local security identifiers were rebuilt
  • printer connection immediately started working
  • “Access Denied” disappeared

No domain rejoin was required.
No GPO changes.
No permission modifications.

Only the affected workstation needed restart.

How We Verified the Local Machine SID

After excluding permissions, GPO and spooler issues, we checked the local Machine SID on both affected computers.

Method 1: Using PowerShell (Built-in Method)

On each machine we ran:

PS C:\Users\user> Get-LocalUser | Select Name, SID

Name                    SID
----                    ---
Uaer1                   S-1-5-21-3233462353-1395252782-2869473667-1001
Administrator           S-1-5-21-3233462353-1395252782-2869473667-500
DefaultAccount          S-1-5-21-3233462353-1395252782-2869473667-503
Guest                   S-1-5-21-3233462353-1395252782-2869473667-501
user                    S-1-5-21-3233462353-1395252782-2869473667-1004
WDA                     S-1-5-21-3233462353-1395252782-2869473667-504

The important part is the base portion of the SID:

S-1-5-21-3233462353-1395252782-2869473667

The last number (-500, -501, etc.) is only the RID of the local account.

If the base part is identical on two different machines, the Machine SID is duplicated.

On the affected systems, the base SID was exactly the same.

Method 2: Using PsGetSid (Sysinternals)

For additional verification, we used PsGetSid from Microsoft Sysinternals: https://learn.microsoft.com/en-us/sysinternals/downloads/psgetsid

Running:

PS C:\PS> .\PsGetsid.exe

PsGetSid v1.46 - Translates SIDs to names and vice versa
Copyright (C) 1999-2023 Mark Russinovich
Sysinternals - www.sysinternals.com

SID for \\WS-PC320:
S-1-5-21-3233462353-1395252782-2869473667

Regenerating the Machine SID Using SIDCHG

After confirming that both computers had identical local Machine SID values, we regenerated the SID on one of the affected systems using SIDCHG from Stratesave.

Utility page:
https://www.stratesave.com/html/sidchg.html

Procedure

  1. Downloaded SIDCHG from the official Stratesave website.
  2. Extracted the utility on the affected workstation.
  3. Launched SIDCHG with administrative privileges.
  4. Selected the option to generate a new Machine SID.
  5. Confirmed the operation.
  6. Rebooted the computer when prompted.

The process completed without errors.

After restart, we verified the Machine SID again. The base SID was now different from the second machine.

Important Notes for Enterprise Environments

  • Duplicate SIDs in domain environments are not officially supported
  • Modern Windows security mechanisms are less tolerant to identity conflicts
  • This may impact:
    • Printer sharing
    • Remote access
    • SMB shares
    • Local security token evaluation

If you are deploying images, use:

sysprep /generalize

before capturing the image.

Leave a Comment