Event ID 6167 LSA

Question

I'm having trouble installing six new PCs on a client network. I can't access the shared folders on the six new PCs. When I try to log in to the PC with the shared folder, I get the following event: 6167, LSA - Partial Computer ID Mismatch. This indicates that the ticket has been modified or belongs to a different startup session. Authentication error.

Answer 1

Hello Rep. Hardware,

Following up on your issue and reevaluating the previous answer, there is absolutely no supported Group Policy or registry mitigation that securely bypasses Kerberos Ticket Granting Ticket (TGT) validation failures caused by duplicate Machine SIDs. The Event ID 6167 LSA authentication error you are experiencing confirms these six newly cloned PCs share identical Security Identifiers and machine account hashes, causing the domain controller's Key Distribution Center (KDC) to reject their mismatched session tickets during the SMB handshake for shared folder access.

The only official Microsoft best practice to resolve this architecture flaw without completely re-imaging the drives from scratch is to disjoin the six affected workstations from the domain and execute the command C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /reboot directly from an elevated prompt. While I previously cautioned against this due to the ensuing Out-Of-Box Experience reset and driver stripping, it is the strict technical requirement to force the kernel to generate a new, unique local Machine SID upon the next boot sequence. Any reliance on deprecated third-party SID-changing utilities violates Microsoft support boundaries and will permanently corrupt the local SAM database. Ensure you back up any critical local user data, execute the generalization process, and then rejoin the PCs to the Active Directory to establish healthy trust relationships and unique Service Principal Names (SPNs).

Hope this answer brought you some useful information. If it has, please consider accepting the answer so that other people sharing the same issue would benefit too. Thank you :)

VP

Answer 2

Hello Rep. Hardware,

Starting with cumulative updates released around August and September 2025 for Windows 11 versions 24H2, 25H2, and Windows Server 2025, Microsoft enforced strict Kerberos and NTLM security protections that block authentication handshakes between devices sharing the same SID. C:\Windows\System32\Sysprep\sysprep.exe /generalize directly on your currently deployed endpoints is highly destructive. Running this command on live machines strips hardware drivers, removes machine-specific configurations, and forces an Out-Of-Box Experience (OOBE), which disrupts any existing user profiles or software installations. Furthermore, your description lacks the exact operating system version and build number; verifying this is critical to confirm if your environment falls under this specific update enforcement.

Could you confirm the exact Windows version and build number on these six PCs? If you are running the affected builds, the officially supported permanent resolution is to entirely rebuild these systems from a newly created, properly generalized master image, rather than attempting to sysprep live machines. You must run Sysprep on the master virtual machine or reference image prior to capture to ensure unique SID generation during deployment. If rebuilding the workstations immediately impacts your project timeline, Microsoft provides an official interim mitigation. You must contact Microsoft Support for Business to request a special time-limited Group Policy specifically designed to temporarily bypass this SID uniqueness check (which also frequently logs SEC_E_NO_CREDENTIALS) while you prepare a compliant master image.

Hope you found something useful in the answer. If it helped you get more insight into the issue, please consider accepting it. Thank you and have a nice day!

VP

Answer 3

The Event ID 6167 indicates a partial mismatch in the machine ID, which suggests that the Kerberos ticket may have been manipulated or belongs to a different boot session. This can occur when the system's Security Identifiers (SIDs) or Universal Unique Identifiers (UUIDs) are not unique, especially in a virtualized environment where cloning may have occurred without proper SID generation.

To resolve this issue, you can try the following steps:

1. Ensure that each new PC has a unique SID. If you used cloning to set up the PCs, consider using sysprep to generate new SIDs.
2. Check for any recent updates or patches that might have affected Kerberos authentication, as sometimes uninstalling a problematic update can resolve authentication issues.
3. If the problem persists, reinstalling the operating system on the affected PCs may be necessary to ensure all identifiers are unique and correctly configured.

These steps should help you address the authentication errors you're encountering with the shared folders on the new PCs.