Windows Server Summit 2024
Mar 26 2024 08:00 AM - Mar 28 2024 04:30 PM (PDT)
Microsoft Tech Community

The security database on the server does not have a computer account for this workstation trust..

Brass Contributor

We have a single Site single Domain (xyz.com) which contain following 3 Domain Controllers:

 

1- DC1 (PDC, windows server 2012 R2, a hyper-v virtual server)

2- DC2 (Secondary DC, windows server Ent 2008 sp2, physical server)

3- DC3 (Secondary DC, windows server Ent 2008 sp2, a vmware virtual server)

 

Problem:

The error message "The security database on the server does not have a computer account for this workstation trust relationship" is coming while end users attempting to change their password who are controlled by a domain password policy.

 

Action Taken:

1

When i chech the computer account, i found following result:

C:\Windows\system32> NETDOM VERIFY computer_name
The secure channel from computer_name to the domain XYZ has been verified. The connection is with the machine \\DC3.xyz.com

 

2

Then i do force to RESET the secure channel to DC1:

C:\Windows\system32> NETDOM RESET computer_name /domain:xyz /server:DC1

 

3

After restart the computer, user able to change without any error message!!!

 

Now My Question is:

Why the error message "The security database on the server does not have a computer account for this workstation trust relationship" appear while those computer's secure channel is connected to DC2/DC3 only?

 

Why those client computer's Secure Channel is automatically registered to either DC2 or DC3?

18 Replies

Could be a firewall issue, could be a replication issue, could be a configuration issue. Have a look at the following article with suggestions on how to resolve either of those:

Error: The security database on the server does not have a computer account for this workstation tru...

Let me know if that helps you, or what issues you could identify by using that article.

 

 

Kind regards,

 

Jaap Brasser

jaapbrasser.com

 

Thanks for your reply. But the link doesn't helped me.

Mohammed

 

Sounds like a replication issue.  I would Stop and then force replication. 

Perhaps you could try disconnecting the Ethernet cable then input your user credentials again and then plug in the Ethernet cable back@Mohammed Ullah 

I'd agree, I'd check health and replication are 100% using (dcdiag / repadmin) tools. If you wanted some help then please run;

  • Dcdiag /v /c /d /e /s:DCName >c:\dcdiag.log
    (please replace DCName with your domain controller's netbios name)
  • repadmin /showrepl >C:\repl.txt
  • ipconfig /all > C:\dc1.txt
  • ipconfig /all > C:\dc2.txt
  • ipconfig /all > C:\dc3.txt
  • ipconfig /all > C:\problemworkstation.txt

then put files up on OneDrive and share a link.

 

 

 

Regard cmd "ipconfig /all > C:\problemworkstation.txt, currently i do not have any problemworkstation. i will send the result as soon as i got one.

"@Dave Patrick 

Looks pretty good to me although there are some system event log issues to look into on ZAHRANIDC2

 

 

 

@AmogelangThis worked splendidly - coupled with a domain disjoin/rejoin. 

@Amogelang Disconnecting the ethernet worked perfectly by using cached credentials and then bringing back on the network coupled with a domain disjoin/rejoin. Thank you.

While this didn't answer my issue directly, it did point me in the right direction, so thank you!  I was having trouble getting remote desktop to work on a machine I had just converted from physical to a VM.  Even though I could log in using the HyperV Connect, it wasn't letting me RDC.  It didn't even occur to me that it wasn't on the domain correctly. Thanks again! @Mohammed Ullah 

I've just logged in to say thankyou for this. Unplugging the ethernet sounds really lame, but that did the trick. I was able to log on, still with my domain credentials, and go through the domain joining procedure again. It worked after a reboot. I don't know what caused this, possibly the primary user changing their domain password earlier in the day.
The same thing just happened to me this morning. I didn't think the "unplugging" method would work but it sure did the job. I just plugged it back in after my computer loaded.
Unfortunately, the ethernet unplug and re-plug did not work for me, it's a first time login on this laptop so it says "We can't sign you in with these credentials because your domain isn't available. Etc. etc."

This was the answer for me the AD object for the computer existed on DC0 and did NOT exist in DC1 or DC2 !!!!!!!!!!! so I ran repadmin /syncall /AdeP on DC0 and now there is a computer object replicated to DC1 and DC2.

 

In other words the computer used DC0 for the domain join but was trying to use DC1/DC2 for the auth so because the AD object for the computer did not exist in DC1/DC2 the auth was failing and the force replication command worked liked a charm. Now we need to figure out why the replication is not working in the first place.

 

@Mohammed Ullah