We recently ran into an issue where some of our domain controllers would get stuck in reboot loops in one of the child domains. The domain controllers were recently upgraded to 2022. Not all domain controllers in the domain would do it either; it was random, but once it started, it persisted. The only way we found to stop the reboot was to disconnect the NIC so the machine didn’t get any traffic.
Symptoms
Domain controller would pop up a message saying this machine will reboot in 1 min.
In the event log, event ID 1000 thrown
Faulting application name: lsass.exe, version: 10.0.20348.4163, time stamp: 0xf055926b
Faulting module name: ntdll.dll, version: 10.0.20348.3932, time stamp: 0xc75bbaae
Exception code: 0xc0000005
Fault offset: 0x0000000000072eb0
Faulting process id: 0x330
Faulting application start time: 0x01dc3f6cd20cb038
Faulting application path: C:\WINDOWS\system32\lsass.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report Id: 16d31b63-2138-4bea-9ac3-d19e62f7170b
Faulting package full name:
Faulting package-relative application ID:
Issue found
Opened a ticket with Microsoft to troubleshoot as everything we tried failed. Rebuilding the domain controllers would help for a short while, but the problem would resurface. After many memory dumps and sessions with tech support, we found the issue.
The problem was with a shortcut trust that was established 20+ years ago when the domain was created. This shortcut trust was missing the securityIdentifier attribute and, under very specific circumstances, would cause lsass to crash. This is an issue that Microsoft admitted is a known issue, but not many customers have created the perfect set of conditions to trigger the bug (lucky me!). It is an issue that started with 2022 and newer domain controllers.
To check for this issue, run the following command. You can also look using adsiedit connected to default naming context, trust will be in the system container.
ldifde -f c:\temp\trusts.txt -r “(&(objectClass=trustedDomain)(|(trustType=1)(trustType=2)))” -t 3268
Open the trusts.txt file which will output like below. Look for a securityIdentifier. If its missing that is a problem.
dn: CN=root.com,CN=System,DC=child,DC=root,DC=com
changetype: add
objectClass: top
objectClass: leaf
objectClass: trustedDomain
cn: root.com
distinguishedName: CN=root.com,CN=System,DC=child,DC=root,DC=com
instanceType: 4
whenCreated: 20020314230047.0Z
whenChanged: 20251014125300.0Z
uSNCreated: 18653
uSNChanged: 3818287685
name: root.com
objectGUID:: fGv6ZUgwSUCMfaf3FWIhYw==
securityIdentifier:: AQQABBAAAAUVAAAArEm1Z0g6xjUnNbxw
trustDirection: 3
trustPartner: root.com
trustType: 2
trustAttributes: 4194304
objectCategory: CN=Trusted-Domain,CN=Schema,CN=Configuration,DC=root,DC=com
The Solution
Simple. Delete the shortcut trust and add it back. This will create the missing security identifier and the reboots will stop. I deleted this in the middle of the day on a very busy domain with no issues. Auth will continue to function as you still have your trust chains to your root domain. In fact, one must wonder, why do we need this shortcut trust at all? Evaluate your environment and make the call.
Jonathon Harper 