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

[Mohammed Ullah]

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?

[#2]

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

[#3]

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

[#4]

Mohammed

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

[#5]

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

[#6]

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.

[#7]

https://alzahraniholding-my.sharepoint.com/:u:/g/personal/mullah_alzahrani_com_sa/EXVpOruXjO1JhoIMI2...@Dave Patrick 

[#8]

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 

[#9]

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

[#10]

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

[#11]

Thank you @Amogelang !!! This worked for me!

[#12]

@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.

[#13]

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 

[#14]

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.

[#15]

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.

[#16]

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."

[#17]

Thank you!!

[#18]

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 

[#19]

This is the way, thanks very much

[#20]

I removed the ethernet cable and was able to login. @Amogelang