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

    Discuţie generală

  • Hi

    Please help - I'm getting crazy. Four machines, after SP1, two with this login problem. I'm getting the message "The security database on the server does not have a computer account for this workstation trust relationship.". I updated the network card driver, I removed computer from domain and rejoined. Nothing helps.

    First login works fine, second one gets the error message again. Please help. User and I don't know what to do!

    Any help would be appreciated.

    Best wishes

    Roberto
    4 aprilie 2008 09:36

Toate mesajele

  • Having same issue.  The same system is OK on a simple domain (no special GPOs) but our work domain has this issue.  The work domain has some "special" things.

     

    Do you by chance have a GPO which changes the primary domain suffix?

     

     

    14 aprilie 2008 19:31
  • a few people (including myself) seem to be having this problem.

    http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=2875206&SiteID=17


    I have a GPO that does set the primary domain suffix.. ill try and kill the setting and see if it changes anything.
    15 aprilie 2008 02:20
  • The problem was indeed the domain suffix. Thank you.
    15 aprilie 2008 12:44
  • This was the fix for me as well! thanks!!
    • Propus ca răspuns de kelly719 22 iunie 2010 19:12
    16 aprilie 2008 01:24
  • sorry for an uninformed question but how do you kill the setting exactly? I cant find that GPO?

    thanks

    peter

     

     

    18 aprilie 2008 03:21
  • ok, so i found in computer configuration/administrative templates/network/dns client/primary DNS suffix ... but it is not configured. am i looking in the wrong place?

     

    18 aprilie 2008 03:54
  • no, that's the right place.

    on a PC that's having trouble, go

    start -> run

    rsop.msc

    it will probably bring up a UAC thing, just login with any admin user.

    then go the the above place (
    computer configuration/administrative templates/network/dns client/), and see if the Primary DNS suffix is set.  If it is, then you have another policy somewhere that's setting it.. if its not set... then you might be stuck Smile
    18 aprilie 2008 06:01
  • removed the computer from the Active Directory on the SBS2003, then rebooted the workstation (actually also rebooted the server) and was able to login again. ugh ... thanks guys ... this at least put me in the right direction. as an fyi, my bluetooth (logitech) and radiocontrolled (SONY) keyboards and mice on multiple machines stopped working last week with some odd incompatibility/Win95 error. i was hoping that SP1 fixes it, which it did!

     

    • Propus ca răspuns de Ohanga Ooko 24 iunie 2010 08:29
    18 aprilie 2008 14:30
  • Hi

    I'm getting the exact same problem on a Vista Business PC/SBS2003 setup. Before I updated to VistaSP1, I'd get this, but after 4 or 5 goes it would eventually connect. However, I've just finished upgrading to SP1 and nothing will work. I've tried removing PC from Active Directory and the resetting it, I've tried just removing it from AD, I've checked RSOP (no settings there at all), still nothing works!! Does anyone have any other ideas I can try.

    Cheers

    MannyW

    29 aprilie 2008 00:17
  • Manny,

    try to remove the workstation from the domain and make it a 'workgroup' box. then restart and rejoin to the domain. then restart and see if it works (I am not saying that this is pretty but the only way to make it work for me on one of the machines).

    peter

     

     

    29 aprilie 2008 03:58
  • Hi Manny

    Try this out on your Domain Controller:

    A) Start > Run > ADSIEDIT.MSC

    B) Go to Domain Partition and mark the affected computer

    C) Rightclick and Properties.

    D) Doubleclick ServicePrincipalName

    E) Add new value: HOST/yourcomputername.yourdomain.xyz or whatever HOST is missing.


    Best wishes


    Roberto
    • Propus ca răspuns de Ender16 21 ianuarie 2010 23:50
    29 aprilie 2008 07:24
  • Peter

    Thanks for this, I did get round to doing exactly that and, yes it does work and yes, it's seriously not pretty!!

    Although this issue has gone and login is now ok, I've ended up with a new user, in the format username.domainname.local.001. As all my settings are with the prior user, big problem!! So I'm going to uninstall SP1 and System Restore back to yesterday and hope I get my original user back!

    I'm really not sure why Vista invents a new user and doesn't give you the option to connect to the prior one and I'm still no nearer to figuring out what is behind this login issue; is there a setting on the Vista PC that holds the PC/Server relationship settings?

    Anyone any further ideas?

    MannyW

    PS I'm also going to try Roberto's idea and see if that helps

    29 aprilie 2008 09:17
  •  

    Roberto,

    This worked perfectly.  it appears that the Domain Suffix GPO was doing it's job, but the SPN wasn't being updated properly.

     

    Obviously, this is a workaround, not a fix, but it'll do in the meantime.  We won't be able to roll out SP1 in our environment until this bug is fixed.  Bummer.

     

    Thanks again!

    -Bozford

    29 aprilie 2008 15:53
  • Just curious as to if anyone else out there is still seeing this issue.  We still are at Princeton. If we either send SP1 via WSUS or even have someone manually apply it about 1 out of every 5 installs gets the "The security database on the server does not have a computer account for this workstation trust relationship" after SP1 install.  We do have a premier ticket in with Microsoft, but no answers yet.

     

    Princeton IT

    7 iulie 2008 01:36
  • Peter, this works fine in my case but after two reboots the problem comes back. I'll try the ASDI solution below also.

     

    Vista Business, the problem appeared right after applying SP1.

     

    Thanks,

     

    Antonio.

     

    6 august 2008 14:54
  • I found the solution. Just revert to XP. Smile

    ALL the solutions on this forum and others have no permanent solution. There is an update from Microsoft that still doesn't fix the problem.

    In my case, all work-arounds failed. Apparently I just have to wait till MS gives this better attention -though I doubt they will now with 2008 and all.
    9 august 2008 18:31
  • probably there is a user domainName\MachineName in your local administrators, remove it from the administrators group,

    this is works for me,

     

     

    13 august 2008 09:21
  • Im having the same error problem while connecting a terminal session to a domain. Its not an issue that can be changed by adding/removing this 'computer' from the domain. Is there an account policy setting im missing in Server 2008? Or how do i find a computer account for a Terminal session? Is this an authentification issue because there is none setup on the server as yet. It will not be possible to add the user as an administrator, the user is a member of Remote Desktop Users and Domain Users group. Have i missed something?

    2 septembrie 2008 02:38
  • Hi I'm still stuck with this problem!! What was the MS update, do you have the KB number for this (or any other ID)?

    I'll give anything a try !!

     

    Cheers

    MannyW

    4 septembrie 2008 19:39
  •  

    solution: 

    Computer to computer properties

    Select the Tab which allows you to change the computer Name.

    Ensure the computer name domain and suffix are in sync with the Domain (name).

    Good Example>

    Full  Computer Name: DougLubeyComputerName.mydomain.com

    Domain: mydomain.com

     

    BAD example> (WHICH WILL CAUSE THE ERROR after upgrading to Windows vista SP1)

    Full Computer Name: DougLubeyComputerName.mydomain

    Domain: mydomain.com

     

    Bad example is missing the ".com" after the "mydomain". 

    to note:  the old style/old procedure on our network was to use the bad example becuase our computers would

    not properly join the domain if we used the fully qualified domain name "mydomain.com".  We had to use just

    "mydomain" for the computer name, while full qualified domain name was automatically picked up whether or not

    we entered "mydomain.com" or just "mydomain".

     

    Anyhow...it was pretty simple fix.....my just adding ".com" in the computer name. Did not have to rejoin the domain or delete computer account names or edit the registry or anything......some a 30 second fix.

     

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

     

     

    Thanks,

    Doug Lubey of Louisiana

    www.douglubey.com

     

    2 octombrie 2008 21:01
  • - My network settings are perfect.  xxx.xxx.loc and DNS is perfect

     

    - Installed Vista SP1 (reformatted my system, because of other Vista problems - Previous Vista Ultimate SP1 did not have this issue)

     

    - I can join domain, but get the error

     

    - I have no GPOs in use

     

    My last Vista system ran fine with SP1, this one does not... nice! I can't take the Vista pain anymore... I hate to say this since I have been so die hard microsoft, but this is ridiculous, so buy a computer that works... aka NOT Vista

     

    If anyone actually knows what causes this, please let me know... thanks....

    3 octombrie 2008 04:49
  • I'm not sure it would work with the vista problems above, but i solved my Server 2008 Terminal issue, "the security database.........".. By luck we stumbled upon the local policy account setting (gpedit.msc) and had to add the terminal users group to the remote desktop policy; or the other way around (i forgot, it was a couple of weeks ago). With the Vista problems mentioned above it would be advisable to go through the different security policies on the server side of your domain and check to make sure you have all the relevant permissions associated with your account profile. Good luck!!

     

    3 octombrie 2008 05:12
  • This is a problem with Windows Vista when you update to SP1.

    Rejoining the Domain (reregistering) may solve the problem.

     

    Click on Computer.

    Right Click Properties.

     

    Under Computer name, domain, and workgroup settings-

    Change Settings

     

    Under to rename this computer its domain or

    workgroup, Click Change.

     

    Under member of:

    Domain

    Enter your domain name.

     

    Click O.K. and restart system.

     

    You haven't changed anything, but reregistering your system with your domain MAY solve the problem (it did with my system).

     

    There obviously are issues when you update the OS that caused the problem.

     

    As I always say, if in doubt, reboot.  Cleaning out the system by doing this seems to work in many cases.

     

    13 octombrie 2008 16:33
  •  

    I experienced a similar problem with our Terminal Server 2008 farm, i could log on using a domain account from the host domain but when trying from a trusted domain it failed with the above error.

     

    What Microsoft implemented in SP1 for both Vista and Server 2008 was a design change to address security concerns regarding a downgrade attack. Therefore, if the type of domain trust is NT4, no failover to NTLM authentication will be performed after the Kerberos authentication failed, which results in the logon failing with the above message.

     

    Upon checking the trust status using replmon all the failing domains were of the type DOWNLEVEL, i.e. NT4, rebuilding the 2 way trusts from a Windows 2003 DC and enabling SID filtering allowed trusted domain accounts to log on to the Terminal Server 2008 farm.

     

    So check any domain trusts, especially if they were in place prior to Windows 2000 SP4 and make sure the type is NT5 i.e. UPLEVEL

     

     

    14 octombrie 2008 13:40
  • I just encounter this problem too but what i did was, I checked my computer name/hostname on my Active Directory if my hostname still exist but unfortunately it was gone. So i tried to disjoined my PC to the network and joined again and it works.

    If you see your computer name/hostname on the AD by searching on the computers and still the error will appear just delete your computer on the AD list of computers then try to disjoin and join on the network.

    My OS is a VISTA PC also.


    mykeel
    13 noiembrie 2008 07:19
  • Join to Workgroup

    reboot

    log in as Administrator

    Change computer name

    Join to domain

    reboot

    Login to domain

     

    5 decembrie 2008 19:52
  • works very well,

    we have an non rfc compatible domain name because of the company owner ...

    dhcp an dns is running under linux, the domaincontroller is an dns slave (all so stupid, i know but not my work!)

    so if i added a vista busines computer to the domain you could login after the first reboot (no domainsuffix registed) but not after the second reboot because of the domainsuffix is added later by the domaincontroller

    thanks a million!


    6 working hours to solve the problem because of non rfc compatible installations in our network
    9 decembrie 2008 14:00
  • Roberto Pascolo said:

    Hi Manny

    Try this out on your Domain Controller:

    A) Start > Run > ADSIEDIT.MSC

    B) Go to Domain Partition and mark the affected computer

    C) Rightclick and Properties.

    D) Doubleclick ServicePrincipalName

    E) Add new value: HOST/yourcomputername.yourdomain.xyz or whatever HOST is missing.


    Best wishes


    Roberto

    Thanks Roberto.  I still can't understand why this is the fix for the problem I had.  
    I am also confused on why it does that both for Vista and Windows 7.  XP Worked just fine.
    What is the reason behind these messages?

    30 decembrie 2008 23:48


  • PaulJSO said:

    Roberto Pascolo said:

    Hi Manny

    Try this out on your Domain Controller:

    A) Start > Run > ADSIEDIT.MSC

    B) Go to Domain Partition and mark the affected computer

    C) Rightclick and Properties.

    D) Doubleclick ServicePrincipalName

    E) Add new value: HOST/yourcomputername.yourdomain.xyz or whatever HOST is missing.


    Best wishes


    Roberto

    This solution worked for me also.

    Note: Problem was caused when the primary DNS suffix was changed from the default Domain suffix.

    Rblend

    30 ianuarie 2009 04:41
  • Greetings all,

    I detected this issue too after rebuilding one of my development servers.  I had a server named USTRSCTC002 that belonged to my development domain dct.com.  I unjoined the machine from the domain when it still had Windows Server 2003 on it, and then rebuild the machine to Windows Server 2008.  Do bear in mind that Windows Server 2008 RTM is actually Server 2008 Service Pack 1, released in conjunction with Vista SP-1.

    When I rejoined the machine to the domain, I was greeted with the error message "the security database on the server does not have a computer account for this workstation trust relationship."

    I also noticed that for every logon attempt with a domain ID, I'd get a Kerberos error in the log.  I originally didn't pay much attention to this error, but after trying everything that folks said to try (including multiple domain unjoin/rejoin attempts), and having nothing work, I decided to look into the Kerberos error some more.

    Description:
    A Kerberos Error Message was received:
     on logon session
     Client Time:
     Server Time: 11:28:8.0000 6/25/2008 Z
     Error Code: 0x7  KDC_ERR_S_PRINCIPAL_UNKNOWN
     Extended Error: 0xc0000035 KLIN(0)

    I looked up the KDC_ERR_S_PRINCIPAL_UNKNOWN and got hits across the board.  There were no quick solutions there.  But the 0xC0000035 error provided a much faster insight.  0xC0000035 maps to the symbolic name STATUS_OBJECT_NAME_COLLISION.  That was interesting...where did I have a conflicting named object in my Active Directory?

    This thread shed some light on the subject, and also provided a command to check for dupes:  http://social.technet.microsoft.com/Forums/en-US/systemcenter/thread/be6fcac4-7310-42d1-980e-e1725b464756/

    This command was in the above mentioned thread and is provided here for convenience:
    ldifde -f C:\SPNs.txt -t 3268 -d dc=domain,dc=com -l serviceprincipalname -r (serviceprincipalname=*) -p subtree

    I went through the results and checked for the conflicting name, in this case "ustrsctc002" or "ustrsctc002.dct.com"

    Several years ago we were beta testing Windows Vista and had rebuilt this machine to Vista build 5270, and after having problems with it, we rebuilt it to Server 2003--and forgot to unjoin it from the domain.

    Years later, the old Vista Dev Server computer record was still lingering in the AD.  I was able to find it in ADSI Edit.  Basically I had two different Computer objects possessing the same servicePrincipalName value(s).  My USTRSCTC002 machine object was correct:

    HOST/USTRSCTC002
    HOST/USTRSCTC002.DCT.COM
    TERMSERV/USTRSCTC002
    TERMSERV/USTRSCTC002.DCT.COM

    But my old Vista Dev Server had the following for servicePrincipalName:

    HOST/Vista Dev Server
    HOST/USTRSCTC002.DCT.COM
    TERMSERV/Vista Dev Server
    TERMSERV/USTRSCTC002.DCT.COM

    It was the instance of HOST/USTRSCTC002.DCT.COM that was the killer.

    It is my understanding that Vista SP-1 and Server 2008 have an affinity for Kerberos over NTLM, and will use it if available.  That said, since this was a fresh Server 2008 build which wanted to use Kerberos, the old computer record that was hanging around was the downfall.  Once I deleted the offending computer object (the Vista Dev Server), life was good. :)

    Best regards,
    Matt
    10 martie 2009 15:06
  • hi..dear...

    I used your idea..it is working....thnks man..keep in touch..my id us shuanak312@gmail.com
    22 aprilie 2009 05:34
  • This is a reply to the post by Matthew Sawyer...YOU ARE THE MAN!  Thank you!!

    I ran ldifde -f C:\SPNs.txt -t 3268 -d dc=domain,dc=com -l serviceprincipalname -r (serviceprincipalname=*) -p subtree on my DC and I found the problem.  Once I deleted the offending computer, I was able to login to my other DC.

    12 mai 2009 18:41
  • Could someone sujjest.

     what will be resolution for Windows 7

     

    18 iunie 2009 16:37
  • That Ldifde command is awesome, many thanks!
    18 iunie 2009 21:35
  • Hey, I seemed to have found the fix to my problem.

    My situation:

    Old staff file server was renamed in AD to SSS4-OLD from SSS4 and then rebooted as well as IP changes, etc.   I then made a new server (in our VMWare cluster) as a Server 2008 SP2 Standard Edition named SSS4 (replacement server).

    I could join the domain, but not login getting that server security database error.  Thanks to the some of the other posters here, I checked the SPN on the new SSS4, and it was fine, however, the old SSS4-OLD had not changed it's SPN.  Upon changing the SPN and rebooting the new SSS4, everything is now fine.

    Thanks for the help in pointing me to the right direction.
    • Propus ca răspuns de tzappa 10 septembrie 2009 18:49
    17 iulie 2009 18:31
  • I've been building out over 30 2008 servers and have been encountering this problem with about half of the servers.  At first, I would unjoin, reset the computer account, then rejoin which seemed to resolve the problem.  Then it happened to a new DC - That was a pain in the %$#@.  After promoting the server, there was no local account to log back into.  I found a duplicate entry for that one in AD and eventually resolved the issue.

    I've seen this error come up and resolve itself after renaming a computer, re-joining it to thedomain and I've seen it just go away on it's own.  I don't have a single clue as to what is going on?  Has Microsoft chimed in on this yet?

    The are 3 domains in the forest I'm working in.  All servers are 64bit 2008 standard. There is a trust with another forest hosting 1 domain. Computer accounts are typically created in AD first. These are new machines in a new domain using a new naming scheme.  I know there are no duplicates.

    10 septembrie 2009 19:01
  • Hi, I came accross this issue, but now I resolved it, I changed my computer name and then restart it, then it could be log on with my domain account, I think this will help you to resolve this issue.
    Good luck,
    Paul Li
    11 septembrie 2009 05:06
  • That worked in most cases but it doesn't help when it happens to a domain controller.  After you promote a machine, it removes the local user accounts so the only account you can log in with is a domain account. Of course when you try to log in with a domain account you get the "Security Database" error and your totally screwed.  Even if you could get in and change the name, (which is not something you want to do with a DC) you would have to spend the next 5 years cleaning out rogue ADSI and DNS entries.

    Fortunately I was able to get back in using Safemode (no networking) which allowed me to access the event logs.  The event logs indicated Kerberos errors and I ended up have to shut off the Kerberos and DNS services to get back in. Later I did find a rogue AD entry that looks like it was create when the server was promoted. Removing that resolved the issue.

    The fact is that a lot of people are having this issue and no-one has a clear reason why it's happening or a sure fire fix for all situations. This appears to be a pretty big bug and I'm amazed it hasn't been addressed yet.
    11 septembrie 2009 20:07
  • Leaving and re-joining the domain did it for me. Check the Event Viewer on the server for a NETLOGON notiifcation and it will tell you to try re-joining the domain if the machine should have access.
    9 octombrie 2009 06:18
  • Tried all the workaround you peeps posted, nothing worked.

     Even tried to upgrade to SP2 the Vista PC and still not able to join the domain. Will try a format on the PC even i cannot find anything soon, and prolly will install winXP,
    15 octombrie 2009 06:32
  • I recently performed a 20+ Server 2008 SP2 install and had this happen on about 1/3 of the machines. I most cases I was able to unjoin and then rejoin.  This even happened to 2 newly promoted DC's so I didn't have the luxury of logging in with a local admin account (that wasn't fun). I attempted to look at the ADSIedit fix others mentions and didn't find anything out of the ordinary.

    During this project I noticed some of the servers exhibiting these symptons just fixed themselfs after about half a day which to me strongly suggests a replication issue. I was pretty careful to make sure I was only making changes on the DC the servers were logging into however this problem still occured. After a while, this problem stopped happening altogether.

    The only thing can think of was I made some major changes to AD sites and services. Sites and Services was selecting replication partners that physically couldn't talk to either due to firewall policies or lack of established tunnels. I gave the default site link a ridiculously high cost and then started modelling out the perferred replication paths so the DC's could actually communicate with each other. (It's also neccessary to delete the automatic links that couldn't communicate - If they keep reappearing then you have more work to do.) This smoothed out almost all of the AD replication issues and I haven't seen the security error on the last 8 server installs.

    I don't know if this is the end all solution, but it's another avenue you can explore.
    20 octombrie 2009 18:04
  • Hello,

    I found myself in the same situation. In fact I have renamed a decomissioned server but I omit to do a restart and just did a lazy shut down. After lookin at your post and the event viewer I found a eventID 11 from Kerberos-Key-Distributoin-center (source). The source of my problem was a duplicate SPN on the DC (SBS 2K8). I found a procedure to fix the problem from microsoft here:

    http://technet.microsoft.com/en-us/library/cc733945(WS.10).aspx


    Hope this help.

    Best regards,
    Pierre


    Pierre Sioui
    23 octombrie 2009 00:58
  • Try to remove the records of this computer from active directory --> Computers and also remove the entry from DNS (Forward lookup zones). After this, remove the system from domain and join as a work group, once restarted, join again in domain
    7 decembrie 2009 05:17
  • I had the same problem after changing IP address of Windows 2008 Server Std. Quick solution in my case was the following:
    1. Delete primary DNS suffix in Computer Name dialog window and reboot.
    2. Set primary DNS suffix equal to domain suffix and reboot server again.
    After these steps I was able to logon with domain user credentials on that server.
    • Propus ca răspuns de Mike114327 16 februarie 2010 16:40
    14 decembrie 2009 15:33
  • Roberto, you rock!!
    4 martie 2010 03:01
  • Another case:

     

    It's computer conflict in Domain, so just change the computer name unique and rejoin the domain, the problem will be solved.

     

    Cheers Roberto,

     

    Kevin

    1 aprilie 2010 00:14
  • The time was not set correctly on mine.
    22 aprilie 2010 21:21
  • I spent a week and  a half on this issue, only to find out how silly my situation was. In my office I have to use a switch so that I can work on different PCs at the same time. It finally donned on my that maybe the switch was the problem. Sure enough, I took the Vista SP1 laptop that into the server room and connected directly to the network from a main switch and now everything is just fine. I've not had problems with XP being setup in my office over the secondary switch, but for whatever reason Vista wouldn't function properly...

    fat

    1 iunie 2010 21:56
  • Dear Matthew,

    Thanks for your explanation. My problem are the same, but the problem resides on duplicate SPN in the Active Directory Objects.
    I have 2 SPN pointed to SMTPSVC/COMPUTERNAME, thats cause the 2 Exchange Servers do not communicate each other.
    The problem get 2 days of my work and your ldifde command saves more works days.

    Thanks again.

    Paulo Hecko
    MCSE, MCP, MCTS.

    4 iunie 2010 18:14
  • Surely just the simple way as I have just done for two machines that I have the issue with is to run the joining network wizard within change settings for domain/computer name etc.

     

    As long as you know the name of your domain and know the username and password of an administrator of that domain it will then re-add the machine to the domain.

    13 august 2010 11:20
  • I got this issue on a WS08 R2 DC at a branch site after changing my password and trying to log on too soon before replication had sorted itself out. No action required apart from waiting in this case.
    16 septembrie 2010 09:10
  • I was able to fix this issue on a laptop with windows 7 Pro 64bit OS by logging-in as another user with administrative rights and simply detaching and re-joining the domain.   
    22 septembrie 2010 07:30
  • I had the same issue on one of my remote site domain controller (it was a new installation). After my R&D I found one thing, in AD there were two computer accounts for single domain controller. First one is displayed as "workstation or server" and second one is dispalyed as "writaable domain controller". I just deleted the computer account which is having a machine role of "workstation or server" then   immediately I was able to login.


    Santhosh Sivaraman MCITP: Microsoft Exchange Server 2007/2010 | MCSE/MCSA
    25 septembrie 2010 09:25
  • I had the same issue on one of my remote site domain controller (it was a new installation). After my R&D I found one thing, in AD there were two computer accounts for single domain controller. First one is displayed as "workstation or server" and second one is dispalyed as "writaable domain controller". I just deleted the computer account which is having a machine role of "workstation or server" then   immediately I was able to login.


    Santhosh Sivaraman MCITP: Microsoft Exchange Server 2007/2010 | MCSE/MCSA
    25 septembrie 2010 09:25
  • Hey

    Good News. I just have sorted the problem out.

    I have one dedicated server for file, application and print services on Windows Server 2008 R2 Enterprise 64 bit. I normally joined this member server under our Domain. Suddently i was facing this problem while i started workshop. I could not join the server under domain after doing lots of changes. Everytime the same messege appeared "The security database on the server does not have a computer account for this workstation trust relationship."  While i was going through MSDN this problem blog i was trying to solve this issue and i solved it.

    I just simply joined the computer under workgroup and than restarted.

    Than i logged on locally as an administrator and changed the computer name to a different name and clear the dns suffix and netbios computer name.

    Than again i restarted the computer and logged in as local administrator.

    Than i tryed to join the computer under domain and it allowed me join under domain but you have to put administrator previleges.

    Than restarted the computer again and put domain administrator account and logged in under domain. I logged in successfully.

    I think this will help you a lot. If you do lots of changes on your domain controller or dns server than server holds the old legacy cache information sometimes even after flashing the cache information from the server it doesnot help us to get rid of the old information.

    Anyway i solved my problem the way i explained you. Try it hopefully it will work. Good Luck

    Best Wishes

    Abu Tareq Mohammad Zobayer

     


    30 septembrie 2010 00:20
  • I have about 150 users that authenticate with cross forest. There is password policy change for these users, where they are required to change password every 4 weeks. Every time I change password, I cannot login because of this error. Very soon I will need to upgrade all users to Windows 7, and if I have to rejoin computer to domain every time one of them changes password that will be a disaster. There must be a permanent fix for this? C'mon Microsoft!
    • Propus ca răspuns de -midiman- 24 noiembrie 2010 10:30
    23 noiembrie 2010 04:59
  • Hello,

    There are, unfortunately, a number of factors that contribute to this error being generated. Although the Win7 machine may have *looked* like it successfully joined the domain (after all, a Computer object exists in AD), in fact the joining wasn't entirely succuessful. That is, yes, the Computer object gets created, but it is not fully and correctly configured. This can be due to myriad reasons - firewalls enabled, cloned machines, conflicting product keys/sids etc. etc.

    When joining Win7 machines to a pre-AD2008 domain, always make sure all Windows firewalls are turned off on the machine, and have one and only one network route to the domain controller (e.g. don't enable the wired network and wireless).

    If you get this error: "The security database on the server does not have a computer account for this workstation trust relationship." when attempting to login, this is usually because the Computer object creation did not complete (you may have seen a DNS or similar error after joining the domain). This means the object is created, but important LDAP attributes are not set in the object. So...to set these, try this:

    On your Domain Controller, get hold of ADSIEDIT.MSC. If you don't have it, you can download it from the Microsoft Support Tools site.

    RUN: Start -> Run> ADSIEDIT.MSC

    Under the Domain tree, find the Computer object in question and select Properties. When you see the list of attributes for the machine - and it should be a fairly long list - you need to change these 2 attributes:

    dNSHost

    If you've seen the trust error, this attribute's value will probably be blank or incomplete. Change the value to the fully-qualified DNS name of the machine as shown in the machine's System properties - e.g. mywin7box.mycompany.domain

    servicePrincipalName

    This attribute takes multiple values. Again, if you've seen the trust error, it will likely be blank. You need to add 2 values to this attribute:

    1.     HOST/the computer's MACHINE NAME in all capitals (NOT the FQ DNS name) - e.g. HOST/MYWIN7BOX

    2.     HOST/the computer's fully qualified DNS name - e.g. HOST/mywin7box.mycompany.domain

    NOTE the use of a FORWARD slash, NOT a BACK slash, as is often used in MS naming (thankfully, this is LDAP)

    Press OK to save the changes, and you should then be able to login via the domain on the Win7 box.

    I really hope this horrible hack helps people get to grips with the 'new and improved' Win7 (Vista.1) networking.

    -midiman-

     

    24 noiembrie 2010 10:29
  • what is this bullcrap! this is happeing with windows 7 all the time on our domain! i have to keep changing it to workgroup then back onto the domain with a changed name. Please is there a way to prevent this from happeinging when setting up a pc with windows 7?!
    29 noiembrie 2010 01:24
  • This problem was resolved with the below simple steps.

    1) REmove the system from Domain.

    2) Set the DNS suffix correctly. Ensure that you have all the suffix set correctly especially for the domain where you log in.

    3) Add the system back to domain.

     

    My guess is, if the DNS suffix is set up correctly before adding the system to the domain, this error/problem can be avoided.

     

    Regards,

    Chandan Patralekh

    18 februarie 2011 14:51
  • I have run into this issue repeatedly on Server 2008 R2 and Windows 7 machines. Checking the DNS suffix with ADSIEDIT showed that both the correct entries were there.  There are a few ways I have found to resolve this issue.

     

    1.  Reboot the 2008R2 DC - not  the best of fixes as it will cause other issues

    2.  Reboot the computer - seems to fix the issue 90% of the time, until it happens again.

    By far the easiest way I have found to get around this issue:

    When logging into your domain.  When you receive this error, Instead of using user/pass/domain change your login name to user@domain/pass, or vice-versa This little work around has worked for me every time.

     

    Hope this will help some folks, I was hoping SP1 would have fixed this issue, but no, its still around.

     

     

    7 aprilie 2011 19:32
  • For some reasons, I needed to format and re-install my Windows 2003 Enterprise server. I re-setup it with same fqdn name and other stuffs alongwith AD as they were before.

    Now, all clients (WinXP) can connect and use the server resources but everytime they connect to sever, following errors are logged:
    Event ID: 5513
    The computer COMP1 tried to connect to the server \\SERVER using the trust relationship established by the EXAMPLE domain. However, the computer lost the correct security identifier (SID) when the domain was reconfigured. Reestablish the trust relationship.
    Event ID: 2723
    The session setup from computer 'COMP1' failed because the security database does not contain a trust account 'COMP1$' referenced by the specified computer.
    
    Event ID: 5805
    The session setup from the computer COMP1 failed to authenticate. The following error occurred: 
    Access is denied.
    I tried to re-join the client machine from client, but by doing so it creates separate user profile folder in 'Documents and Settings', and user's earlier preferences are gone.

    Will solution suggested by Roberto.Pascolo solve my problem? or  Is there any other way to re-join client machines to the domain?

    Thanks in advance.
    20 aprilie 2011 08:46
  • Hi Manny

    Try this out on your Domain Controller:

    A) Start > Run > ADSIEDIT.MSC

    B) Go to Domain Partition and mark the affected computer

    C) Rightclick and Properties.

    D) Doubleclick ServicePrincipalName

    E) Add new value: HOST/yourcomputername.yourdomain.xyz or whatever HOST is missing.


    Best wishes


    Roberto
    Helped to cope with the problem in my case.
    Are there plans to release fixes?
    10 mai 2011 15:06
  • Hi Everybody,

    I do have the same problem with different Windows 7 machines. Once in a while different workstations can´t log on. they get the error:

    The scurity database on this server does not have a computer accout for this workstation...

    The Computer account is there, also the right ServicePricipalName.  This happens one day and then for weeks there is no problem with the logon. Then again, and next day everything is fine. I tried all the different sollutions provided here. But the problem stil persists.

    Does anybody have an idea?

    Thanks

    Juergen

    11 mai 2011 11:39
  • Hi,

    we had a same problem with couple of (virtual) servers.  These was cloned, from the one working host, and had some SPN:s was setup for the servers.  After rejoining from domain (several times....) did not help (with the same name) we changed the name of the servers and then (from server-x to server-xx) they started working.  Reason was propably that, the SPN holds the SID information, and therefore those servers could not login with old name.

    Now servers are workig fine.  Just needed to reconfigure SPN:s to get services working as expected.

     

    19 mai 2011 08:16
  • Manny,

    try to remove the workstation from the domain and make it a 'workgroup' box. then restart and rejoin to the domain. then restart and see if it works (I am not saying that this is pretty but the only way to make it work for me on one of the machines).

    peter

     

      


    This worked for me!

    Thnx

    23 mai 2011 21:44
  • If you can't logon, how would you achieve this?

     

     

    24 mai 2011 18:33
  • Sure to change the name and rejoin the domain works for a while, but than all of a sudden, the workstation can´t log on. Than for one or two weeks it works again, and the again I get the error that no computer account is there.

    Since months I look for a solution, so far without success.

    If someone out there has an idea it would be great.

    Juergen

    25 mai 2011 09:07
  • Hello PKSB

    Can you point me to exactly where the computer configuration is? I just see system configuration which does not contain administrative templates... please excuse my slowness :)

    25 mai 2011 10:11
  • Hello all, hope my little contribution may help someone.

      I started getting this error after cloning a member server.  When I cloned my 02 server to create a replacement for my ailing 03 server, I ran into this error when I turned off the ailing server and renamed the new one with the name and ip of the original sick server.

    - after reboot, my application would no longer work on the new server.  The client would give a generic aspx error, and say unavailable.
    - Discovered that although the server indicated it joined the domain, it would not allow logons with any domain accounts.  It gave the error above that brought us here.

    - discovered that AD would not/could not create a computer account for the new server.
    - finally decided to create a computer account manually in AD.  Tested, but it still didn't work.

    - Then using info from the posts here, edited the serviceprinciplename value in the manually created AD account, using the ADSIEdit tool.  I also edited some other values that involved server names, etc. 
    - after editing the values for the new server, using another good server as a guide, saved the changes and I tested again and the server worked.

    Thanks to Roberto for mentioning the servicenameprinciple in his post, that guided me to what was wrong.

    29 iunie 2011 21:04
  • Hi All,

     

    I am getting this error for past few days on Windows 7 .At the time of giving the credentials just off the wireless and you can bypass this error.But this is a temporary solution.Once you have access you can look for a permanent solution.

    Looking for a permanent solution.Can anybody help me out (:

    2 iulie 2011 18:49
  • I found I needed to do this to get it all working

     

    From a DC/AD server

    ldifde -f C:\SPNs.txt -t 3268 -d dc=domain,dc=com -l serviceprincipalname -r (serviceprincipalname=*) -p subtree

    In the above command, replace DC=domain,DC=com with the DN of the domain. To check if duplicate SPN is present.

     

    for me the issue was a duplicate HOST/ entry for the server found in a service account

    Found from this link - the link has more steps if needed
    http://social.technet.microsoft.com/Forums/en-US/systemcenter/thread/be6fcac4-7310-42d1-980e-e1725b464756/?prof=required

    6 iulie 2011 14:18
  • 1. Try to login with Local Administrator/User and remove current machine from the domain and restart the machine. 2. Again join the domain and restart the machine, now you can login with domain Users 3. it will work OK.
    9 iulie 2011 05:37
  • Hello, during some troubleshooting of mscrm, I messed up our dc itself with setspn command. please tell me what spns should be configured for dc in adsiedit.msc
    13 iulie 2011 16:21


  • PaulJSO said:

     

    Roberto Pascolo said:

    Hi Manny

    Try this out on your Domain Controller:

    A) Start > Run > ADSIEDIT.MSC

    B) Go to Domain Partition and mark the affected computer

    C) Rightclick and Properties.

    D) Doubleclick ServicePrincipalName

    E) Add new value: HOST/yourcomputername.yourdomain.xyz or whatever HOST is missing.


    Best wishes


    Roberto

    This solution worked for me also.

    Note: Problem was caused when the primary DNS suffix was changed from the default Domain suffix.

    Rblend

    Hey, Rblend, How Can I change primary DNS suffix on a DC?
    14 iulie 2011 06:26
  • start to change the network id of client and login as admin and follow the wizard.
    26 iulie 2011 12:10
  • Hi Roberto,

     

    I just tried your workaround and it worked perfectly.

    Many thanks!

    Kind regards,

    Buz


    Phil. B.
    4 august 2011 09:00
  • Thanks Peter. This worked for me.
    8 august 2011 17:40
  • Just a follow up to the cause of this error for our Agency.

     

    Some of our Agency computers were connecting to remote portals using Connectix or Citrix software.  What was happening was the remote location was adding a "Domain" suffix to the computers that were connecting.  These computers would then try to login using the "default" domain suffix that was now incorrect.

     

    I fixed this issue by using a GPO and forcing our domain suffix to be the primary suffix.  I have not seen this error since I have made this change.

     

    If you were to look in the computers "Advanced TCP/IP" DNS settings you will probably find the offending domain suffix.

     

    Might not be everyones problem but it sorted mine out. 

    10 august 2011 19:36
  • Hi

    Please help - I'm getting crazy. Four machines, after SP1, two with this login problem. I'm getting the message "The security database on the server does not have a computer account for this workstation trust relationship.". I updated the network card driver, I removed computer from domain and rejoined. Nothing helps.

    First login works fine, second one gets the error message again. Please help. User and I don't know what to do!

    Any help would be appreciated.

    Best wishes

    Roberto


    I have an easier way.  Log into the AD server goto workstations and manage that computer.  In there you can add a local user or enable/reset the password on that workstation.  If you can NOT find the workstation name Add it (the same one that it used to have)  You cna tell what that is by trying to log into the computer that is giving you the Security error.  Choose other user and you'll see what the computer name was

     

    Now once you have enable the admin account or found what another local account was you can go back to the workstation login locally and then re-add yourself to the domain.  One reason the security database lost the computer account is because there might be two computers with the same name.  maybe the old one was recently turned back on??

    Goodluck!

    9 octombrie 2011 00:27
  • How I fixed it:

    I had this problem on a Windows 7 workstation, connecting to a Windows 2008 SBS server.  I could only login to the workstation by unplugging the network cable, then plugging it back in once the PC logged in.  But once on I couldn't access that server.

    I could ping the server's IP address, but I couldn't see the server at all.  I could see other computers on the network, just not the server controlling the domain.

    I Googled the problem and followed various solutions, none of which worked.  (Like disconnecting it from the domain, renaming the computer, then reconnecting it to the domain... which didn't work because it couldn't find the domain controller.  After this I did a System Restore to put things back to how they were.)

     

    I finally modified the hosts.ini (C:\Windows\System32\drivers\etc\hosts.ini)

    In my case, with the server's IP being 192.168.0.200 and the server name being TrackServer I added the following line to the hosts.ini file:

    192.168.0.200 //Trackserver

     

    Poof!  After that it worked beautifully.  I could login to the domain and access the server fine.

     

    I assume something screwy happened to the DNS on that computer.  This system has about 15 computers on it, and all but 4 have XP.  This is the only one of the 4 Windows 7 PC's that have had the problem.

    10 noiembrie 2011 00:49
  • Any update from Microsoft as to when we can expect a permanent solution to this problem? Also maybe a reason for why this is happening?

    I have this problem on my networt on different PC's at random times.


    CVR
    13 ianuarie 2012 07:29
  • I am running into this issue with a Windows 7 Enterprise machine. Problem is that when I try to log into the local machine with the administrator account, it tells me the account is locked. I was able to get into the computer and take it off the domain by disconnecting the network cable and having the user login with the local administrator account (this is at a an office 3 hours away with no IT people in house). Now that I have restarted with the workstation on the work group, I cannot login using the administrator account anymore. Also, the computer was not listed in the Active Directory or the DNS Manager. Ideas?
    • Editat de C_J_GO 6 februarie 2012 17:50
    6 februarie 2012 17:47