Ramblings, ideas, problems, and solutions

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

When working in a corporate environment with Active Directory, you may, from time to time, encounter computers that users cannot log on to, as they receive an error message saying:
 

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

 
Though there can be several reasons for this, I have found that the quickest fix for this is to remove the computer from the doman, and then rejoin it. Here is how:
 

  1. Right-click the computer, choose Properties
  2. Under “Computer name, domain, and workgroup settings”, click “Change Settings”
  3. In the system properties dialog that pops up, click the “Change” button after “To rneame this computer or change its domain or workgroup click Change
  4. Toggle the radio button for Workgroup, then enter any name (we will be changing this back in a few steps anyway)
  5. Click OK to save the change, then reboot the computer
  6. Repeat steps one through three
  7. Toggle the radio button for Domain, then enter the domain name
  8. Click OK to save the changes (When prompted for a user name, use a user that has domain administrative privileges)
  9. Reboot the computer

 
If the above process does not solve the problem, delete the computer account from AD and repeat.

Posted

in

, , , ,

by

Aleksander Nordgarden-Rødner

Tags:

, ,

Comments

52 responses to “Fixing “The security database on the server does not have a computer account for this workstation trust relationship””

  1. Uncle Reggie

    Yeah right, and lose your entire profile and everything you have ever installed. Oh, sure, there are ways to get it back (most of it), but it isn’t pleasant. If you follow this advice, don’t be surprised when you log in to find a brand-spanking new desktop and all of your programs and documents and favorites gone.

    Reply
    1. razumny

      Now, that is an interesting assertion, though it seems to me to be very flawed, and without any basis in reality.

      I have resolved the problem in this manner in excess of two hundred times, and I have never seen a profile deleted, nor programs removed. The reason is simple: All the process described above does, is change how the computer relates to the Domain Controller and whether or not it is a member of Active Directory. It does NOT delete your profile folder, and I have yet to see one become corrupted as a result of this method.

      As for the assertion that installed programs would disappear, I am incredulous as to how that would supposedly work. Again, the method does not do anything other than delete and establish the connection between the computer and Active Directory. This is a fairly simple flag in a config file, and I fail to see how it would do what you claim it does.

      The ball is in your court, “Uncle Reggie” – as the claimant, the burden of proof falls on you.

      Reply
      1. Zark

        Well you are right in a sense it does not delete anything. However a previous associate at my office set my computer up incorrectly on the network and it wasn’t establishing a secure relationship with the server. When i did the fix it worked and i now have a secure relationship but my desktop is empty. This is because it has two profiles for me now one with a lock(the new one) and one without. I just went to users and accessed the old profile and moved everything onto the new one with a matter of a couple clicks and a 45gig transfer.

        Reply
      2. Lewis

        I think Unclue Reggie is confusing user accounts (which have profiles, etc. associated) with computer accounts. However, there are certain circumstances where deleting a computer account may cause extra work.

        One example would be if you use SCCM, deleting and recreating the computer account in AD in this scenario might create two computer objects with the same name, that may need some tidy up in SCCM.

        Also, some services require that you nest objects inside AD computer objects or vice versa. In this instance, the relationships may be broken

        Reply
      3. Syed

        Thanks Razumny its worked for me just change domain to workgroup and workgroup to domain restart and login with user account– Thanks

        Reply
    2. Andy

      Basically the message says that AD doesn’t have account of the computer in its database, therefore; it doesn’t trust it. You need to disjoin and re-join the machine to the network again and that should take care of the problem.

      Reply
  2. Jeb Owens

    Uncle Reggie seems to be clueless. This fix works fine, with no harmful side effects.

    Reply
  3. Rick

    I have done this many times and DO end up with a new profile. If your profile was Name.DOmain, after the fix when you log in a new profile will be created called Name.DOmain.000. The original profile remains so you can get your files and folders form there (they are not deleted). As this is the only way I know of fixing the trust relationship problem, dealing with the profiles is the cost of doing business.

    Reply
    1. razumny

      It is not the only way, but it is certainly the simplest one. As for fixing the rename problem, I believe that you can solve that by renaming the profile folder to its original name. Have you tried that?

      Reply
      1. Ben

        I’ve used this many times with success. Renaming profiles I’ve found to be dangerous with lots of very unexpected results. That said it’s just the way it is, it takes work to fix. If it happens once odds are it will happen again though, so be braced for needing to do something more extreme.

        Reply
  4. BartManDude

    razumny – I have to say that I was pretty sure thatfollowing your instructions would create a new profile for my user and not allow me to reconnect the original again because that has always seemed to happen to me in the past.
    I was dead wrong — and after leaving the domain rebooting and then rejoining the domain the problem went away and I was looking at the appropriate profile again. THANK YOU SO VERY MUCH. after reading your feb 2nd post I figured I would go ahead and try it but I didn’t even need to rename the profile folder.
    Thanks again man, the web needs more people like you 🙂
    BartManDude

    Reply
  5. raja reddy

    thanks it will working

    Reply
  6. XPD / Gavin (@DemiseNZ)

    Applications will not be touched by this solution, nor should profiles really, I’ve done it many many times as well and not had any profile issues.

    Reply
  7. sam

    Findout your Computer name in your Active Directory Server and delete, rejoin domain that PC problem. It will work

    Reply
  8. mnabor

    this discussion help me a lot, thanks

    Reply
  9. Justin

    This worked for me just fine. Thank you very much!

    Reply
  10. don

    This fix will work if you can login.

    Reply
  11. Garrett

    Solution worked fine for me. Profile, data, and applications preserved.

    Reply
  12. Lois

    Thank you, thank you, thank you! Worked like a charm!

    Reply
  13. Doug

    This solution will resolve the issue but it will NOT prevent the issue from happening again. We need to determine WHY the issue is happening so we can resolve the root cause and not get use a ban-daid and just remove and add it to the domain.

    Reply
    1. Jane

      Doug, we are in the same boat. It keeps happening to us too. Any solution you have found?

      Reply
  14. Kumarikandam

    after adding to workgroup and then adding back to the domain resolved the issue. Thanks very much !

    Reply
  15. Stanley Sikondwama

    This can work just fine if you can log in! If you cannot (because the administratot account has been disabled) then you have had it! What is the solution in a situation like that?

    Reply
    1. Richard Ryan Grove

      I am in a similar boat. I can log in to the users account by unhooking the networking cable but the user does not have Administrator privileges so I cannot remove the computer from the domain. I’m stuck with a computer that will work if they unhook the Ethernet cable before every log in but will not let them do anything that requires admin access or domain access overall.

      Reply
  16. Rocketman

    @StanTheMan, download Ntpass at http://pogostick.net/~pnh/ntpasswd/ and create a bootable CD from the ISO. Boot from the CD which will allow you to change passwords and also enable disabled account.

    Reply
    1. razumny

      Nice one, @Rocketman, hadn’t seen that one before.

      Reply
  17. StraleZ

    It works! Thank you a lot.

    Reply
  18. Santosh Kumar

    What if we get this error on a Virtual Machine ??

    Reply
    1. razumny

      The steps to resolve do not hinge on a physical computer, and are the same regardless of whether the machine is virtualised or not.

      Reply
  19. Phil

    If one cannot log on to the computer this entire fix is irrelevant. Any other suggestions?

    Reply
  20. Jane

    It appears that nobody has identified the true source of why the problem returns to same computer or other computers in the enterprise.

    Reply
  21. Techgeek

    Hello,

    I am facing the same issue in my organization. Everyday in the first login it prompts with this error and I have to do manually remove from Domain and again join in to the domain. After reboot it logs in to the domain with AD username and password.

    I have renamed the computer name in the workstation, and I have deleted and added newly to the domain, but still the same error is happening everyday after a reboot.

    Could someone help me on this issue If you have any detailed steps.

    Reply
  22. Mike

    It won’t even let me log into safe mode

    Reply
    1. razumny

      Mike: Check @Rocketman’s comment from October 16th. His solution might help you, too.

      Reply
  23. Donald

    This wont help everyone, but, IF you can log in as a user and IF you can access the domain controller; you can then enable the local administrator account:

    1 – type “cmd” in the windows start menu search box. Right click on cmd and click run as administrator.

    2 – assign a password to the local administrator account by typing “net user administrator Password1234”

    3 – enable administrator account by typing “net user administrator /active:yes”

    I have found that logging the computer back into the domain with the domain administrator account BEFORE logging into the actual user you want tends to fix the issue of the computer not wanting to stay logged into the domain.

    Still a bandage, not fixing the original problem, but a more permanent workaround.

    **** your mileage may vary *****

    Reply
    1. Jane

      Thank you, Donald. I will surely try that next time it comes up.

      Reply
  24. instantcomputing

    Worked perfectly for me! Thank you so much!

    Reply
  25. Colin (@ColinTyrrell)

    Thank you; this worked perfectly for me. And it saved my ass.
    I did know the local admin password, and the user affected has a roaming profile.

    Reply
  26. another IT-Guy

    thank you. that was helpful . keep it up.

    Reply
  27. Kavya R

    Thank you. The second solution helped

    Reply
  28. boyd

    This really helped! Great stuff!

    Reply
  29. Jasper

    Thanks, worked perfectly for me – had to delete the old AD Server Object manually though, before re-joining the server to AD 🙂

    Reply
  30. Simbarashe Musikavanhu

    Had two machines with the same error message. I managed to resolve the error by logging in as the local administrator and took the computer off the domain and enrolled it back on to the domain on the first machine. The other one fortunately i could log in as the domain administrator, so I when to network ID and clicked Next next following the defaults and it worked.

    Reply
    1. JumpStartComputing.comGeekAtLarge

      Hello, Simbarashe. I understood your description of what you did to the first machine, but your English is broken, and I did not understand what you did to the second machine. You logged in with the domain administrator credentials and then what did you do?

      Reply
  31. Bill

    PERFECT!!

    I have been going round in circles for 2-hours trying to fix this!

    Thank you so much!

    Reply
  32. Navaneet

    But Here issue is with AD server itself. I am getting error The security database on the server does not have a computer account for this workstation trust relationship” while trying to login to AD server. Help appreciated

    Reply
  33. ezsp

    For people’s information, this method isn’t possible on a Domain where the workstation has had elevated privileges revoked and the local admin account disabled. If the trust relationship breaks then there is no way to rejoin the domain from either machine and it’s a case of reinstalling the profile. Be very aware of disabling local admin accounts in this respect!

    Reply
    1. Aleksander Nordgarden-Rødner

      Good point. This is also the reason why most people advocate not only disabling the built-in admin account, but also replacing it with another one, with a different user name.

      Reply
    2. Michael

      If the device is a Windows 7 machine, you can actually renable the local admin and set the password to something useful. If a device falls of the domain, and there is no local admin, follow these instructions to save the machine http://www.pcworld.com/article/249181/how_to_reset_your_windows_password.html

      Reply
  34. David Sheehan

    I have done this remove from domain, add to workgroup then back to domain on 2 computers and it created a new profile on both computers. I have to log back in locally to try and recover the missing data on the new profile. This is gonna be a pain on 33 machines.

    Reply
  35. Francois

    These are not “Fixes” but rather workarounds. The same problem could easily (and likely) happen again in the future with the same computer (or other computers) depending on what settings are not correct (could be workstation or server).

    Reply
  36. Ferdinand

    Sometimes the best solution is to restart the computer.

    Reply

By posting a comment, you consent to our collecting the information you enter. See privacy policy for more information.

This site uses Akismet to reduce spam. Learn how your comment data is processed.