Error: The security database on the server does not have a computer account for this workstation trust relationship - Windows 2008 Server

Today I tried to login one of the windows 2008 server with my domain user id and password, suddenly appeared one error message on the screen as like below -

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

 

Here goes the details information about this error -

Cause

Starting with Windows Vista and Windows Server 2008, Winlogon will only attempt Kerberos logon. The change was made to achieve higher security in logons that happen across forests. Logon problems may also be caused by the following issues:

1. The trust was created a long time ago, and the NETBIOS name was used to create it resulting in the name resolution used on the trust being NETBIOS, and not DNS.
   
2. The firewall rules don't allow the Kerberos protocol to pass the firewall, and also not the domain controller locator to find a domain controller (UDP/389).
   
3. You have already passed the problems above and logon errors are still happening. In this case, the syntax contoso\user works, but a UPN like user@contoso.com does not work.
   

Workaround

For a resolution you can remove the external trust and replace it with a forest trust created between the forest root domains of either forest. You may use selective authentication so still only the users can logon to your system that had the ability to do so before. Alternatively, you can take the following steps

1. When you inspect the trusted object for the trusted domain in the domain, you will see an attribute TrustType = 1 which sets the trust to NETBIOS name resolution and hence no Kerberos. You can inspect the value in ADSIEDIT.MSC in the System container. The object will be named after the NETBIOS name of the remote domain.
   
   

   Note
   To solve this problem, re-create the trust using the Trust Wizard for Windows Server. This will create the trust using the DNS names of the domains and then TrustType = 2, thus DNS and Kerberos can be used on the trust.

2. The network data flow for Kerberos is quite different, and requires port 88 for UDP and TCP to work, and also port 389 in UDP to locate the domain controller. If you are using Windows Vista systems to change the user passwords, you need to open the Kerberos change password port, 464, for both UDP and TCP.
   
3. Because the trust is an external trust, the suffix routing options you have with a forest trust are not available, because of this, custom UPN suffixes will not work. User@contoso.com will not work when the domain FQDN name is contoso-ad.com.
   
   

   Note
   In order to log on, you need to use the real fully qualified domain name(FQDN)@ like user@contoso-ad.com. This is called the implicit user principal name (UPN).

4. A similar problem with UPN suffixes may also happen with a forest trust. If you have custom UPN suffixes (not matching a domain name in the forest), you need to register it on the forest. The local forest admin also has to enable the suffix, so the suffix can be used on computers in another forest across the forest trust.

source