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

18 Feb

 I had to change the Primary DNS suffix to some servers. To do that the server were moved to a separate OU and a Group Policy was applied to that OU to change the DNS suffix.
I’ve issued gpupdate /force command on the servers and restarted them. After restart I was not able to login to some of them with my domain credentials. Only servers with Windows Server 2008 were having this problem. Windows 2003 servers were running as expected. The error that I was getting was: The security database on the server does not have a computer account for this workstation trust relationship.

I was able to login to the servers with local admin account.
On Technet I found the following article it is a security measure that was introduced in later operating systems(Vista, Windows 7, Windows 2008):
http://technet.microsoft.com/en-us/library/ee849847(WS.10).aspx

I have not tried to recreate the trust as described in the article but instead I add Service Principal Name (SPN).
Originally FQDN of my server was server1.domain.local after adding primary DNS suffix the FQDN become server1.subdomain.domain.local. So I had to add this HOST SPN.

There are 2 ways to add SPN, using setspn command or through ADSI Edit console.
Login to the domain controller on the domain to which the server is joined to.
setspn way:
  in command prompt type:
  setspn -L server1
  server1
is the host name that is having problems.
  The command sould show you all the SPNs for this server, like this:
  Registered ServicePrincipalNames for CN=SERVER1,OU=Servers,DC=DOMAIN,DC=local:
      HOST/SERVER1
      HOST/SERVER1.DOMAIN.local

  As you can see the SPN with the new DNS suffix is missing and this is why you are getting the error when trying to login.
  To add the new SPN type:
  setspn -A HOST/SERVER1.SUBDOMAIN.DOMAIN.local server1

  to confirm that SPN was added type the firs command again and you should see this:
  Registered ServicePrincipalNames for CN=SERVER1,OU=Servers,DC=DOMAIN,DC=local:
      HOST/SERVER1.SUBDOMAIN.DOMAIN.local
      HOST/SERVER1
      HOST/SERVER1.DOMAIN.local

ADSI console way:
open ADSI edit by typing adsiedit.msc in run or command prompt.
Now you need to find the computer object that is having the problems. Because my server1 is in Servers OU the path was:
Domain [DC.domain.local]\OU=Servers
There I can see an object called CN=server1 right click on it and select properties
No find and select servicePrincipalName and click Edit button.
In the Values to add field type:
HOST/SERVER1.SUBDOMAIN.DOMAIN.local
click on Add button
Close all the windows by click OK button.

That’s it you should be able now to login ot server. You only need to use one method(setspn or ADSI edit).
Also depending on your domain environment the change my not work straight away give it some time to replicate the change.

Tags: , ,

3 Responses

  1. Oleh says:

    Thanks. It’s really worked!

  2. karthik says:

    just change ur domain to workgroup and restart then convert workgroup to domain. it will work

  3. gjp says:

    Hello all,

    I have same issue with my vista clients which connected 2003 domain… any solution for client s member of server 2003 domain, i saw the above article explains window 2008 server not server 2003. appreciate any help.

    many thanks,

Leave a Reply to karthik

IT Blog

Just another blog on Kozeniauskas.com Network