Win 10 The Security Database on the Server does not have a Computer Account for this Workstation Trust Relationship after update 20H2

Question

Hi, I've seen other questions regarding this issue but the solutions there have not resolved my issue. I'm wondering if someone can help?

I have a small home network, comprised of 2 Server 2016 Domain Controllers and 15 workstations. I recently installed Windows Feature Update 20H2 on a desktop system and a laptop. These machines have always been part of the domain and have not had issues prior to this update.

After if was installed when a valid user tries to login they see a message "The Security Database on the Server does not have a Computer Account for this Workstation Trust Relationship". If I disconnect the LAN cable, or disable WiFi, they can login just fine with cached credentials and can browse to all the network resources without issue one the network connection has been restored.

Here's what I have done to troubleshoot:

1. Run an nslookup on each of the problem machines. It successfully resolves the primary and secondary DCs
2. Reset the computer accounts for the problem machines in ADUC
3. Verified replication is taking place on both DCs
4. Verified that the time and date are set automatically on the workstations and that time synching is successful
5. Reviewed entries in the Event Viewer
6. Ran an ipcongig /all on both machines

The Event Viewer shows an audit failure for both machines (it's the same for both), so I looked to see if there were any stored credential in Credential Manager that may have been causing the problem. I didn't find anything. Below are the results of the ipconfig and Event Viewer errors. I'm hoping someone has come across this before and can help me figure this out (I've deliberately removed details of the account name and domain in the results below)

ost Name . . . . . . . . . . . . : Studio
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . :

Ethernet adapter Ethernet 2:

Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel(R) Ethernet Connection (7) I219-V
Physical Address. . . . . . . . . : 00-D8-61-70-8B-93
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IPv4 Address. . . . . . . . . . . : 192.168.1.125(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Lease Obtained. . . . . . . . . . : Monday, March 29, 2021 1:03:34 PM
Lease Expires . . . . . . . . . . : Wednesday, March 31, 2021 9:29:13 AM
Default Gateway . . . . . . . . . : 192.168.1.1
DHCP Server . . . . . . . . . . . : 192.168.1.1
DNS Servers . . . . . . . . . . . : 192.168.1.12
192.168.1.13
Primary WINS Server . . . . . . . : 192.168.1.12
NetBIOS over Tcpip. . . . . . . . : Enabled

An account failed to log on.

Subject:
Security ID: SYSTEM
Account Name: STUDIO$
Account Domain: LO
Logon ID: 0x3E7

Logon Type: 7

Account For Which Logon Failed:
Security ID: NULL SID
Account Name:
Account Domain:

Failure Information:
Failure Reason: An Error occured during Logon.
Status: 0xC000018B
Sub Status: 0x0

Process Information:
Caller Process ID: 0x5d0
Caller Process Name: C:\Windows\System32\lsass.exe

Network Information:
Workstation Name: STUDIO
Source Network Address: -
Source Port: -

Detailed Authentication Information:
Logon Process: Negotiat
Authentication Package: Negotiate
Transited Services: -
Package Name (NTLM only): -
Key Length: 0

This event is generated when a logon request fails. It is generated on the computer where access was attempted.

The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).

The Process Information fields indicate which account and process on the system requested the logon.

The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The authentication information fields provide detailed information about this specific logon request.

• Transited services indicate which intermediate services have participated in this logon request.
• Package name indicates which sub-protocol was used among the NTLM protocols.
• Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

Answer 1

Had to remove the machine from the domain and rejoin. Created a copy of my old profile before doing that, so I could copy a lot of things back but still had to reinstall and reconfigure numerous apps. Luckily, I always copy the apps and serial numbers to my NAS when I purchase them, so I had a good start in doing this

Answer 2

Hi,
Welcome to share here!
After the updates , did all the clients have the issue or some specific clients.
If only the specific computers , i would suggest you remove the computers from the domain and join it again.
If all the clients have the issue, i would suggest you check the DC status and the replication by command :
Dcdiag /v >c:\dcdiag1.log
Repadmin /showrepl >C:\repl.txt
Repadmin /showreps * 

Best Regards,

Answer 3

Hi,
Thanks so much for following up.

Only 1 so far. This machine was cloned (using Macrium Reflect 7) from another workstation that suffered hardware failure. It has been working fine up until this update, then I start seeing the Null SID issues. To me it looks as though Reflect did something during the cloning process and this latest feature update has changed the way authentication is taking place. To the extent that the trust is now broken at login.

The domain replication all seems fine. Repadmin does not cough up any errors and all tests performed under DCDIAG were passed.

It looks as though I may need to drop this thing back into a workgroup, then rejoin the domain to reestablish the trust. I'm extremely hesitant to to this as this computer is my audio workstation. It has a ton of audio and video software configured under my profile and I'm uncertain if removing the machine from the domain and rejoining the SAME domain would in any way adversely affect my profile. I'd hate to lose access to something. In theory it shouldn't but I'm nervous about pulling the trigger
Any thoughts on this, or anything else I should try?

Answer 4

Hi,

Then you can try to repair the security channel by powershell command :
Reset the channel between the local computer and its domain
PS C:\> Test-ComputerSecureChannel -Repair
And check if it can fix the issue.
Then try to reset the computer password with command :Netdom resetpwd /s:target_server /ud:mydomain\domain_admin /pd:*

In my lab: netdom resetpwd /s:dc1 /ud:pki\administrator /pd:123456

Fan