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

This is an error that can come up from time to time for a variety of reasons. When you get this error, usually you cannot access the system in any way: local login, terminal services, RPC connections, shared folder access, etc. When this happens, the computer account may have been deleted, the system may have failed to update its password properly (memory problems, network problems, offline too long, etc). But, what if you can access the server remotely and login, but local logins and terminal service logons are failing? You may see this problem with newer OS's (WIN7 and 2008, or vista) if you are using a disjointed dns namespace.

First of all, what is a disjointed namespace? If you domain is: mycorpdomain.com, and you have other dns zones that different sites use in that same domain, such as east.mycorpdomain.com, and west.mycorpdomain.com, these are disjointed namespaces with subdomains. In the example I will provide, let us assume that the "primary dns suffix" setting of a machine is being pushed through group policy, either at an OU level or at an AD site level.

Let's explain the primary dns suffix setting a little bit. This can be set in the same place that you would set the computer name or change the domain membership, just click the "More" button on this form. The primary dns suffix is an attribute that exists on the computer account in AD, and it is also related to the machine's service principal names (used by kerberos).

When GPO's are used to update primary dns suffix, there are occasions where a machine does not properly update its machine account information. You can see this by looking at the machine details with any AD search tool or ADUC (General tab -> dns name attribute), and the setspn.exe tool.

When the machine fails to update its information, it may show up in two places. To start with you want to look in ipconfig /all from that machine. See what the primary dns suffix is for that machine:

C:\>ipconfig /all

Windows IP Configuration

Host Name . . . . . . . . . . . . : MYMACHINE
Primary Dns Suffix . . . . . . . : east.mycorpdomain.com


Here we see the machine is set to use east. We can use Joeware's adfind to read the other important attributes

C:\>adfind -b dc=mycorpdomain,dc=com -f "cn=MYMACHINE" dnshostname serviceprincipalname

AdFind V01.37.00cpp Joe Richards (joe@joeware.net) June 2007

Using server: myserver.mycorpdomain.com:389
Directory: Windows Server 2003

dn:CN=MYMACHINE,OU=Computers,OU=east,DC=mycorpdomain,DC=com
>dNSHostName: MYMACHINE.mycorpdomain.com
>servicePrincipalName: HOST/MYMACHINE.mycorpdomain.com
>servicePrincipalName: RestrictedKrbHost/MYMACHINE.mycorpdomain.com
>servicePrincipalName: TERMSRV/MYMACHINE.mycorpdomain.com
>servicePrincipalName: TERMSRV/MYMACHINE
>servicePrincipalName: RestrictedKrbHost/MYMACHINE
>servicePrincipalName: HOST/MYMACHINE


If you see here, the dnsHostName attribute is not using the same primary dns name that my machine is using. You may also see some mixed up ServicePrincipalName attributes or some combination of the two. The important ones are the that dnsHostname matches, and the RestrictedKrbHost and HOST serviceprincipalnames match what the machine says its primarydnssuffix is. If they don't, the machine fails to find itself in AD and thinks it doesn't have a computer account, while all the time still acting like it can authenticate to the domain in most cases. This can typically be fixed with some manual Setspn -A commands to add the valid serviceprincipalname attributes to the machine, then reboot.

The problem gets caused somewhere in the delay of change for the primarydnssuffix attribute (only takes effect after reboot) and updates to the machine. I have been told that spn updates may be done as more than one transaction and its possible they were written in more than one place, causing a last writer to win situation that overwrites some of the other updates. That is why you may see some SPN's with the correct disjointed dns name, and some are missing them.

To mitigate this problem, if the computer account's dns suffix is correct (you will see this mostly in vista machines), you can script a job that checks machine accounts for mismatches and fix them proactively. For Windows 7 and higher it is more difficult as the computer account dns suffix is wrong. Generally though you will see this problem on newly built machine as the problem only occurs just after group policy first applies. So spreading the knowledge of the problem to people that build machines is a useful tool to fixing the problem before users see it.