Partager via

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

  • Article

Applies To: Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Vista

This article details known logon issues that can occur for users of computers with one of the operating systems listed below when attempting to join a trusted domain using external NTLM trusts.

  • Windows Vista®

  • Windows Server® 2008

  • Windows® 7

  • Windows Server® 2008 R2

Symptoms

When you introduce computers that have one of the applicable operating systems to your domain, you may see unexpected logon errors for users from a domain you have an external trust with. When this occurs, the following error can be seen during interactive logon:

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

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.

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

  2. 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)<samaccountname>@<FQDN> like user@contoso-ad.com. This is called the implicit user principal name (UPN).

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

Additional information

For more information, see Interactive logon styles and Key Distribution Center account lookup in Windows Server 2003 in the Microsoft Knowledge Base (https://go.microsoft.com/fwlink/?LinkId=178039).

For more information, see Service overview and network port requirements for the Windows Server system in the Microsoft Knowledge Base (https://support.microsoft.com/kb/832017).