none
The trust relationship between this workstation and the primary domain failed - Windows 7 Enterprise joining 2008 Domain, Error 5722.

    Question

  • We have been getting sporadic reports from our users of the error, "The trust relationship between this workstation and the primary domain failed."  The workaround has been to dejoin and rejoin the domain, but it keeps happening and we need a permanent fix.  We are primarily a laptop shop.

    It has been suggested we disable the automatic machine accouint password change on our domain members in GPO.  While this may be a viable option with relatively low security risks, I'd really like to figure out why it's happening and try to fix it. 

    The machines can lose the trust relationship at random.  It can happen overnight, or after going into hibernation.  I've had it happen to me a few times.  The DCs (we have 2) both show error 5722, but one is spitting out a specific Kerberos error that the other one is not:

    While processing an AS request for target service krbtgt, the account kriegesh did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 2). The requested etypes : 18. The accounts available etypes : 23  -133  -128  3  1. Changing or resetting the password of kriegesh will generate a proper key.

    My main issue is trying to determine why this continues happening and if we can resolve it without disabling the account password.  If that IS our best option, then so be it.  Any thoughts are welcome.

    Thank you very much in advance!  ~Sarah

    Friday, January 20, 2012 3:37 PM

All replies

  • Log on locally as a local administrator. In the Network tool of Control Panel, select Change and enter a Workgroup name, leaving the domain. Restart the computer and log on locally as a local administrator. 

    There are two methods to rejoin the domain:
    • You can join the domain from the client if at the same time you can provide an administrator username and password on the domain. 

      -or-
    • You can delete the existing computer account in Server Manager, recreate the computer account, synchronize the domain, and then on the client rejoin the domain.

    Regards, Kalyan.
    • Proposed as answer by foot doc marc Saturday, May 18, 2013 11:33 AM
    Tuesday, January 24, 2012 8:32 AM
  • This solves the problem for each individual machine but does not really address the issue requested.   GP wants to know why it keeps happening to different machines.  The machines were joined successfully.  They worked.   Then they stopped and gave these errors.  They can be "fixed" individually, but unless we know why they broke, they may (and do...) break again.

    What causes a broken trust relationship?

    Tuesday, January 24, 2012 3:06 PM
  • Exactly.  We can fix it for individual machines, but not on a large-scale.  It keeps happening at random.  There seems to be no solid reason why the machines in question are being affected, i.e. some particular reason they get this trust issue.  They can go into hibernation, be locked (not logged off) overnight, or logged off the domain for maybe a week - nowhere near the 30 day expiration MS puts on the system password.

    Thanks for the feedback.  ~Sarah

    Tuesday, January 24, 2012 3:14 PM
  • This article seems to answer your question about how machine account passwords are used and the ramifications of not having them change frequently. 

    http://blogs.technet.com/b/askds/archive/2009/02/15/test2.aspx

    I am having the same problem.   I believe that the problem arises from using imaging software (Ghost in our case).  Windows relies on the fact that either the current OR the previous password will be right.  If an old image has a "wrong" password for a previous password, this might be the problem.  In this case, an image older than 30 days could be considered old...

    I am currently experimenting with setting the password age to a long duration (365+ days) as we rarely use images older than this.

    If anyone can confirm whether this was likely to work, I'd take any information...

     

    • Proposed as answer by Sylvester GGTPC Thursday, September 19, 2013 9:02 PM
    Tuesday, January 24, 2012 3:24 PM
  • Hi there we are having the same issue but it isn't only on Windows 7 machines. It happened on my win 7 laptop but also on a win2008 server we have. Also a number of employees with win 7 laptops are reporting this issue too. Again we have done what you suggested dejoin and rejoin and it resolves the issue but really need to find out if it is a different issue that is causing it. The only thing that I can think of that we have done recently is to apply the latest round of MS patches maybe it was one of these that caused it ?? any thoughts would be very helpful ??

    regards

    Jodie

    Wednesday, January 25, 2012 10:06 AM
  • I am also using Ghost.  I am using the same password and my image is only a day old.  Every time I join a laptop to the domain, it joins fine, restarts, and I go about installed the final software.  Then when I need to restart again, the relationship is suddenly broken.  I can't figure out why or whats doing it.  The only solution is to unjoin the laptop, delete its object in AD, add a new object, and rejoin it.  Then all seems fine.

    Wednesday, January 25, 2012 5:13 PM
  • I have the same issue happening on my network. I am also using ghost. It happened to my laptop and now to a workstation that I restored via a ghost image. The laptop however had not been restored from an image. The trust relationship was just broken from one day to the next. It is very annoying and I would like to know what exactly is causing this issue.

     

    Friday, January 27, 2012 1:11 AM
  • We are seeing this issue randomly as well.  Can anyone report the status of IPv6 on both the clients and the domain controllers?  We have IPv6 enabled on the clients, but disabled on the DC's, and we're starting to wonder if that is possibly causing issues.

    Thursday, February 16, 2012 3:16 PM
  • we are getting the same error.  We do not use Ghost.  The error started appearing after a windows security update which caused problems with RDP connections as well.  After we went back to a restore point to fix the RDP issue, the Trust error continues
    • Proposed as answer by pndukwe Friday, July 25, 2014 1:36 PM
    Friday, March 16, 2012 6:26 PM
  • We are running into those issues too.

    We are using MS Solutions as WDS, WAIK and then all new computers are Syspreped before being joined to our domain for the first time so I don't think it is related to duplicate SID like we can see more often when using Ghost without Syspreping the machine before joining it to the domain.

    I also found this link posted by Mr._Seven above by investigating on my own. It is really interresting so I went through it but that Registry Key they are talking about (ScavengeInterval) does not exist in Windows 7. So I wonder if everything in this article is up to date and can also be applied to W7/W2008.

    For us it seems like the computers are more at risk to loose there trust relationship with the domain when they are working remotely by VPN. We noted, by running a tool/powershell that scans all computers machine password age in AD, that some Windows 7 computers (XP computers too for the record) had exceeded our MAX Machine Password Age policy of 60 days (default is 30). They are connecting by VPN every day for more than an hour and their machine password is not renewed. It should based on the article.

    Some problematic computers are recent, some have been deployed 1 or 2 months ago but we haven't got any machine loosing their trust relashionship once they succesfuly changed it through the normal process of logging into Windows while on the network after the 60 days password age variable. But this is not a good information since we have started migrating to Windows 7 only 120 days ago so the majority of them have not renewed their machine password more than once. We will see soon if it can happen after the computer has maintained his synch with AD by itself...

    We were wondering if the users could do something that would make the computer loose it's trust relationship. Like what will happen if an expired user logged on by VPN then lock his session to go take a coffee and comes back to log in. Then the password is automatically synch with AD and the user gets a "Wrong user name or password" message. If he does not read the message carefully and tries to log in 50 times, will something happens, like will the computer be rejected since too many attempts would have been done from it? We noted that those who got their trust relationship lost have dome more than 20 logon attempts.

    I'll try to be careful at the event viewer next time it happens on the client computer to see if i can find more detials.

    Tuesday, March 20, 2012 6:04 PM
  • I have run into this error on a brand new computer that has not been imaged or ghosted. Freash install, added to the domain and as I'm sure most of you have experienced... my priorities changed and I was unable to work on this computer for over a week. I have not installed any of the corp. software, i'm not sure if I did windows update, I might have installed office... this is the first I've seen it...

    Monday, March 26, 2012 3:21 PM
  • Same issue happening on our network (Win 7 Pro, no imaging - OEM installation).  Only one system reported so far, I find it quite coincidental that the issue starts getting reported so frequently on numerous networks as it appears in this thread.  I've seen this happen in the past, albiet rarely, and local login is the only remedy.  U
    Tuesday, March 27, 2012 12:40 PM
  • We had some suggestions from Microsoft (a tech was in-house and sent us these, we haven't implemented yet, so YMMV and use at your own risk). I just wanted to pass along.  I will report back on any we try.

    1. Some people believe that there is an issue with an imaging process, creating duplicate SIDs. Sysinternals used to have a tool called "NewSID" but it was retired a couple of years ago. Here's a blog post on it:
    http://blogs.technet.com/b/markrussinovich/archive/2009/11/03/3291024.aspx
    2. Others believe the issue may be a corrupt group policy that is being applied. Testing this would of course be extremely time consuming. However, there may be an easy fix for the computers when a problem actually occurs.
    a. GPEdit.msc
    b. Computer Configuration  Windows Settings  Security Settings  Local Policies  Security Options
    c. "Network Security: Configure encryption types allowed for Kerberos"
    d. Check all of the boxes and reboot
    Your mileage of course may vary.
    3. One possible solution is making sure the "Provider Order" in network settings is set to "Microsoft Networks." Here is a blog post on it:
    http://dailyadminlife.wordpress.com/2011/08/05/the-trust-relationship-between-this-workstation-and-the-primary-domain-failed
    4. Some people have been able to successfully re-enable the trust without leaving and rejoining the domain by running the "Join a Domain or Workgroup wizard." I know this won't fix the root cause, but it may keep it from happening again and it is an easier fix than having to rebuild local profiles.
    http://windows.microsoft.com/en-IN/windows7/What-happened-to-the-Network-Identification-Wizard
    NOTE: You may need to unplug the machines from the network to use the cached credentials first.
    5. Symantec and other anti-virus solutions may be the problem, but obviously this creates its own security issues if you have to disable them.
    6. You can disable the machine account passwords as instructed per your Microsoft ticket. Most people believe that removing the passwords won't be a huge security risk, but it will however remove one layer of protection from the equation.

    Please let us all know if you have any luck.

    ~Sarah

    Wednesday, March 28, 2012 2:08 PM
  • This is happening on well over 140 PCs on one floor in our building. The other floors are fine, however the floor with the problems was recently imaged (using ghost) and all the windows updates were up to date on the image.

    Other floors are not affected, yet this trust relationship is coming up randomly on that single floor of 140 pcs.

    Its a complete pain manually going to each PC to rejoin the domain, but having kept logs, some of the ones we have fixed are again coming up with the trust relationship error....

    Nothing in the pc logs, nothing server side. DHCP is the same for all floors, so not that. The client PCs all have a unique SID which is done as part of the sysprep process, so its not that.

    Only thing I can think of is a recent rogue windows update, but i'm getting it in the neck for all these broken PCs. 

    Any word from the Microsoft people on this issue? I can't even test any theories on this because of the complete randomness of this error occuring....

    Monday, April 23, 2012 12:21 PM
  • We are experiencing the same thing with sporadic machines losing their trust relationship periodically.  Our "solution" is to have the users back up their data, and reimage them.  It is absolutely NOT an ideal solution, but it's working for our sporadic problem.  

    Has anyone found a real solution to this, or a cause??

    Wednesday, April 25, 2012 1:30 PM
  • Make sure that you Domain Controller running PDC FSMO role is set to sync the time with reliable time source. Kerbors will always have problem if the computer and DC have time off by more than 5 minutes.

    http://support.microsoft.com/kb/816042

    http://support.microsoft.com/kb/307897

    Wednesday, April 25, 2012 2:02 PM
  • I am getting the same issue.

    Mainly running Windows 7, original deployments are done using SCCM 2007 R3. So no SID issues to get in the way. I am about to do a full review of the GPOs for the workstations so will have to see what is happening.

    Does anyone have some hints where to look to see what is causing the errors?

    Thursday, April 26, 2012 3:28 AM
  • Is there anymore info on this?

    I have just started to have the exact same issue.

    If a Windows Update issue should I be looking on PDC or client?

    We havent changed our GPOs for a while so why would one become corrupt all of a sudden?

    Saturday, May 05, 2012 6:58 PM
  • I am dealing with the same issue as well for the last 5 months. It seems to happen every time a users password expires they get the trust realtionship error, we also get it randomly as well.  I have been just taking the computer off of the domain and deleting their computer account and re adding the computer back to the domain, Its really a pain in the butt. This is not a real solution.

    You can check out this article to see if this will help

    http://portal.sivarajan.com/2010/05/workstation-trust-relationship-issue.html

    I just tried it out on a couple of my computers today. I will just have to wait to see if we get the error again.

    Monday, May 07, 2012 6:36 PM
  • We have proof of this when Win7 clients run windows 7 startup repair tool automatically. When they finish and reboots they get this error because the time is out of sync.

    When the time is out of sync between client and server you then get problems with  the password age for machine accounts.

    ref:

    http://blogs.msdn.com/b/john_daskalakis/archive/2010/02/01/9956266.aspx

    Also we now have disabled  system restore by policy, but it is not stopping restore by startup repair.

    We believe that there are multiple "abnormal" sources to this problem. Therefore we have also deployed http://support.microsoft.com/kb/938449.

    This will probably help if you have this issue on wireless clients that rarely connects on LAN.

    • Proposed as answer by Erich Wehrmann Monday, August 06, 2012 4:46 PM
    • Unproposed as answer by Erich Wehrmann Monday, August 06, 2012 4:46 PM
    Thursday, May 10, 2012 11:29 AM
  • i have the same issue too but i know what i just did!

    active directory users and computers> computers> then right click in my clone7(my computer joined to my domain) then I clicked in reset account.

    now when i try to login in that windows 7 pc, it says the same>> the trusts relationship between this workstation and ....

    but i use the local adminsitrator in that pc i still can see that compyter joined to the domain... any one knows how can i login in the domain with my other user?...reset the pc, the server, disable and enable that pc in the server, still...

    Thursday, May 24, 2012 12:48 AM
  • hi,

    this isn't a lasting solution, but at least you don't have to resoft the computer each time it happens:

    undock and/or disconnect the computer from any network connection and then log in. after you have logged in you can reconnect the computer to any network, cable or wireless. 

    e.g. if you have a laptop, make sure to switch the wireless button off as well as undocking it from any cable. 

    regards,

    untz

    • Proposed as answer by IT_Angie Thursday, May 31, 2012 2:13 AM
    • Unproposed as answer by IT_Angie Thursday, May 31, 2012 2:13 AM
    Tuesday, May 29, 2012 9:19 AM
  • We are having the trust relationship error on our Windows 7 machines only. XP machines don't have the problem. Both XP and Win7 laptops are on the same domain. 
    Thursday, May 31, 2012 2:19 AM
  • hi,

    this isn't a lasting solution, but at least you don't have to resoft the computer each time it happens:

    undock and/or disconnect the computer from any network connection and then log in. after you have logged in you can reconnect the computer to any network, cable or wireless. 

    e.g. if you have a laptop, make sure to switch the wireless button off as well as undocking it from any cable. 

    regards,

    untz

    Same solution here. Laptops only affected, unplug, logon, plug back in. Win 7 only, XP fine.


    Monday, June 11, 2012 2:38 PM
  • We had some suggestions from Microsoft (a tech was in-house and sent us these, we haven't implemented yet, so YMMV and use at your own risk). I just wanted to pass along.  I will report back on any we try.

    "2. Others believe the issue may be a corrupt group policy that is being applied. Testing this would of course be extremely time consuming. However, there may be an easy fix for the computers when a problem actually occurs.
    a. GPEdit.msc
    b. Computer Configuration  Windows Settings  Security Settings  Local Policies  Security Options
    c. "Network Security: Configure encryption types allowed for Kerberos"
    d. Check all of the boxes and reboot
    Your mileage of course may vary.  Please let us all know if you have any luck.  ~Sarah"

    Hi Everyone, Same issues here but a hybrid 2k3 and 2k8 R2 environment where Win7 client and several of the 2k3 servers have the above issues!  I think the Win7 x64 client is pointing me in the right direction in that it is a Kerberos authentication mismatch that occurs.  Win 7 error: "cannot change password, the encryption type specified is not supported on the KDC."  above is the info Sarah G. posted on Mar 28, 2012 the key is SPECIFICALLY - 2 c.  Not necessarily a corrupt policy, but a new default that turns off DES for authentication on the new 2k8 R2 DC's!

    i have found through several tech articles that Win 7 (vista) and 2k8 and up(?) use AES encryption and disable DES encryption by default, but 2k3's use DES and cannot run AES for login/DC access.  Sarah's tech may be on track w/ #2c, but may not be the complete solution.  Any info anyone can add would be appreciated, not a guru on this subject at all.  ~R.Bman  *going to try adding DES to 2k8r2's and Win7 to see what happens.


    • Edited by R.Bman Wednesday, June 20, 2012 9:46 PM incorrect info
    Wednesday, June 20, 2012 8:55 PM
  • I manage several networks both 2008 DC and SBS 2008 and mix of windows xp and windows 7.

    This is getting out of hand.

    Over the last 4 weeks I have had 5 businesses call be up with atleast one machine doing this at each network.

    Thursday, June 28, 2012 1:06 AM
  • I'm not sure this fix will work for everyone. Still have to do the domain off, domain on to get it to connect. But to get it to stop I un-checked the "allow the computer to turn off this device to save power" on the network adapter. I think this is the default value for Windows 7.

    • Proposed as answer by RoufChicago Saturday, June 30, 2012 7:24 PM
    • Unproposed as answer by RoufChicago Saturday, June 30, 2012 7:24 PM
    Friday, June 29, 2012 6:07 PM
  • Hi, I tried to use the method of unplug the network cable, restart the computer and login with user credentials. It fixed the issue of logging. Rejoin domain after that. But here is the other solution to perform at Win 7 machines. Just go to control panel, then users and click on Manage your credentials. Create/ reset / your user credentials there and you will be able to logon.

    Thanks

    Saturday, June 30, 2012 7:27 PM
  • I have seen this issue happen with systems which have identical machine names, you may want to check this and see if this is causing your trust relationship failures. I Hope this helps you.


    Thursday, July 05, 2012 2:16 PM
  • Check to see that these machines do not share a common computername, this has been known to cause trust issues with the server. Click start, right click computer, click properties, click change settings, and change the computername to something unique, you will still have to exit and rejoin the domain but at least you will stop this from happening in the future. Please let me know if you have success with this. Cheers.


    Saturday, July 07, 2012 5:59 AM
  • I have posted the solution on my website: you have to log in with a local user, leave the domain, and rejoin it.  It's not as hard as it sounds, I assure you.  http://nuangel.net/?p=931 - full disclosure: yes, it is my website, but I have gotten very positive feedback that the solution works.  You can see it for yourself in the comment, and if it helps you, don't be afraid to let me know!

    NuAngel


    Don't forget, if you find the help you need, click the "Propose as Answer" link at the bottom of the post containing the solution!
    NuAngel.net

    Sunday, July 22, 2012 5:12 AM
  • Hi R.Bman

    I also have a hybrid domain enviroment.

    I use landesk to copy the netdom files required to reset the machine account password, reboot the machine and the PC can log back in as per normal.

    I agree with your thinking regarding the various authentication types, have you found out any more information on this?

    Cheers

    Chris

    Monday, July 23, 2012 2:35 PM
  • Garrett,

    Read the posts above yours. Everyone here knows how to leave and rejoin the domain. The problem is that the computers keep losing the trust relationship and we a re trying to find a fix to that issue.


    Jeff Speirs

    Tuesday, August 07, 2012 2:49 PM
  • So Microsoft . . . any thoughts?  Want to admit this might be an error or issue and give us an answer?

    Everyone, your ideas are much appreciated, thank you.

    Tuesday, August 07, 2012 2:55 PM
  • Garrett,

    Read the posts above yours. Everyone here knows how to leave and rejoin the domain. The problem is that the computers keep losing the trust relationship and we a re trying to find a fix to that issue.


    Jeff Speirs

    With all due respect, that article is and has been the most popular on my website for months...  and I can even see that at least 10-20 people a day tend to click the link to read the steps, to mention the plethora that come from Bing and Google.  I wouldn't say that "everyone here knows how."  I'm just offering some help to people finding their way in to this thread.

    As far as "why" it happens, I've developed a long list of potential reasons since first running in to the issue several years ago, but I do not think there is any sure fire reason.  If you have a computer that was recently imaged and keeps losing the trust relationship, sysprep it.  If you have a computer that has changed names, delete the old name from the Computers OU in Active Directory.  If you've activated a new domain controller, did you properly DCPromo it or demote the other?  And other times people have sworn to me that absolutely nothing changed...  it's just one of those issues...  like why do I have to restart my print spooler from time to time?  Haha...

    -Garrett


    Don't forget, if you find the help you need, click the "Propose as Answer" link at the bottom of the post containing the solution!
    NuAngel.net

    Wednesday, August 08, 2012 12:27 PM
  • Has anybody tried this?

    Error 1789 when you use the LookupAccountName function on a computer that is running Windows 7 or Windows Server 2008 R2
    http://support.microsoft.com/?id=976494

    -Garrett


    Don't forget, if you find the help you need, click the "Propose as Answer" link at the bottom of the post containing the solution!
    NuAngel.net

    Wednesday, August 08, 2012 12:37 PM
  • Hi Sarah

    In the middle of a MS support case, with a similar problem (not excatly the same as yours).

    I got the important information, that AES is per default enabled on Win 7 Machine Accounts.

    This mean that if you have defined allowed kerberos types, and have not enabled AES128 and 256 as trusted types the you are asking for trouble. Authentication rejection wil happen at random.

    So... If you have defined allowed kerberos types, and have windows 7 in your domain, then make sure you also allow AES 128 and 256

    Regards

    Claus

    Friday, August 10, 2012 7:39 AM
  • Hi Guys,

    I think this has already been posted on here but I found if you login to the local machine (not a domain user) > disconnect from the domain > rename the local machine to something unique > restart as required > log back in to the local machine and join the domain > restart > log in as any domain user. This worked for a problematic windows 7 machine as a permanent fix for me.

    It seemed like it was because this host name had been used on the domain before as an XP machine and only started to happen after the machine had been wiped with Win7 and then named to what it was previous. I think that there may have been something on the DC side that had been missed out before the wipe like the Host had not been removed from the domain before the wipe and the DC was not allowing it to register because it was using a different SID, but this is only a theory I may be worng.

    Thanks

    Anthony-b

    Tuesday, August 14, 2012 7:39 AM
  • I believe the general consensus is to disjoin and rejoin the PC to the domain to correct the issue, but I think I've found the way to prevent this from happening anymore.  You can check out the details here: http://dailyadminlife.wordpress.com/2011/08/05/the-trust-relationship-between-this-workstation-and-the-primary-domain-failed/ but I created a script that does what this article says to do.  The only problem is that you need to do this on all systems that have Win7 or 2008 Server on them.  Another option would be to add this script to a GPO as a login script (just comment out the msgbox lines and remove the comment character on the "On Error Resume Next" line so the users don't call and ask you about the messages).  The code is below, just copy it into notepad and save it as "ProviderOrder.vbs" (with quotes).  *NOTE: You must be logged in as an Admin to run it as a standalone, but it should work in a GPO for anyone who authenticates to the domain.

    'On Error Resume Next  

    const HKEY_LOCAL_MACHINE = &H80000002

    strComputer = "."

    Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" &_ 
    strComputer & "\root\default:StdRegProv")

    strKeyPath = "SYSTEM\CurrentControlSet\Control\NetworkProvider\Order"
    strValueName = "ProviderOrder"
    oReg.GetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,strValue

    arrList = Split(strValue, ",")
    strSelection = False
    If LCase(arrList(0)) <> "lanmanworkstation" Then
    For i = 0 to UBound(arrList)
    If LCase(arrList(i)) <> "lanmanworkstation" Then
    strOther = strOther & "," & arrList(i)
    Else
    strSelection = True
    End If
    Next
    If strSelection = True Then
    strChange = "LanmanWorkstation" & strOther
    oReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,strChange
    msgbox "Modification Complete!", vbokonly + vbinformation, "Complete"
    Else
    msgbox Chr(34) & "Microsoft Windows Network" & Chr(34) & " is not available on this system", _
    vbokonly + vbcritical, "Invalid"
    End If
    Else
    msgbox "This computer does not need this modification", vbokonly + vbinformation, "Not Needed"
    End If

    • Proposed as answer by dustnc Tuesday, August 21, 2012 7:38 PM
    Tuesday, August 21, 2012 7:36 PM
  • Just a question to pose an observation to this thread group - I am performing an Active Directory migration for a enterprise-class client. This isn't my first migration, and I doubt it will be my last. The client AD is 2003 Forest and Domain Functional Levels comprised of both Windows Server 2003 and Server 2008 R2 DCs globally. Client provides both DNS and WINS name resolution. DNS is AD-Integrated for forward lookup and BIND for Reverse lookup.

    Name resolution is always a challange to reach the workstations from our Migration Consoles, but we manage.

    Here's the rub - With every AD Migration I've done, I've seen some fallout. When the Computer joins the Target Domain, sometimes it thinks it's there, but it's like Secure Channel gets hosed and we get a machine with trust relationship issues. Like many on here, our remediation has been to remove the host from the Domain and rejoin it manually. Works like a charm. The problem we're seeing with this migration is that the rate of incident for this is abnormally high. We've got Sites in Canada we're migrating from where the rate of incident is Approx 80%.

    Clients are primarily Win7 with some XP mixed in.

    So, here's what we've observed - If we select the option to "Enable NetBIOS over TCP/IP" the Domain Joins (via Quest RUM Move) are much more reliable. Has anybody else experienced this? (Can I get a witness?)

    Realizing that WINS is theoretically a dated technique for Name Resolution, it appears to me that the Join operation are more reliable when NetBIOS is involved. Now, I've done a bit of reading here at the Microsoft Sites. I found a thread or a Technet Article that mentioned NetBIOS over TCP/IP relies on the standard Windows RPC ports (137, 138, and 139) while operations over "pure" TCP/IP use port 445. I've always understood 445 to be used for file transfer operations, but is SMB traffic used for Domain Joins as well? Is it as reliable a mechanism as RPCs? Am I off-base here?

    Any takers who can explain to me the Domain Join process from a networking level and what implications are added by enabling or disabling NetBIOS over TCP/IP?

    Thanks in advance!

    Kind Regards,

      - Rick Gregson

        rick.l.gregson@hp.com

        rick.gregson@convergenttechonline.com

    Wednesday, August 29, 2012 8:28 PM
  • We have proof of this when Win7 clients run windows 7 startup repair tool automatically. When they finish and reboots they get this error because the time is out of sync.

    When the time is out of sync between client and server you then get problems with  the password age for machine accounts.

    ref:

    http://blogs.msdn.com/b/john_daskalakis/archive/2010/02/01/9956266.aspx

    Also we now have disabled  system restore by policy, but it is not stopping restore by startup repair.

    We believe that there are multiple "abnormal" sources to this problem. Therefore we have also deployed http://support.microsoft.com/kb/938449.

    This will probably help if you have this issue on wireless clients that rarely connects on LAN.

    We had Microsoft to look into the case and they agreed it was the best solution to avoid the problem.

    Ref:

    "Hi,

    I have gathered more information about startup repair, I have seen cases where it brings the system to an old system state , this happens in the background and it is not noticed by the users.

    If repairs are not successful, you'll see a summary of the problem and links to contact information for support. Your computer manufacturer might include additional assistance information. Did you see this when it breaks the secure channel?

    I still think that disabling startup repair is the best way to go in this case

    Best Regards,

    <u5:p> </u5:p>
    Microsoft Premier Platform Desktop Engineer "

    In other words, this is a design failure of win7 because there are no fix to the problem and it's only related to clients in domain.

    Therefore we are now depolying a program to disable startup repair on all our 24.000 Win7 clients.

    Make a package without source files.

    Programs are as follows:

    Command line for x86 without Bitlocker:

    bcdedit /set {default} bootstatuspolicy ignoreallfailures

    x64 without Bitlocker:

    %windir%\sysnative\bcdedit /set {default} bootstatuspolicy ignoreallfailures

    With Bitlocker x86 run 3 steps:

    1. manage-bde -protectors -disable C: (deactivates bitlocker protection)

    2. bcdedit /set {default} bootstatuspolicy ignoreallfailures (disable startup rapair) run with dependency to step 1.

    3.manage-bde -protectors -enable C: (enables bitlocker protection) run with dependency to step 2.

    With Bitlocker x64, 3 steps:

    1. %windir%\sysnative\manage-bde -protectors -disable C:

    2. %windir%\sysnative\bcdedit /set {default} bootstatuspolicy ignoreallfailures (run with dependency to step 1.)

    3. %windir%\sysnative\manage-bde -protectors -enable C: (run with dependency to step 2)

    Program settings:

    specify plattforms on respective clients

    run wheter or not a user is logged on

    with admin rights

    unc name

    Collections:

    You need to find and sort all the clients in the above 4 groups

    Advertisement settings:

    Mandatory, scheduled

    When on LAN

    Run the program from distribution point

    When unreliable

    Run the program from distribution point

    Allow users to run independently

    Allow clients to fall back to unprotected  dps when connection is not available

    I hope this will finally put rest to your minds (and bosses).

    Good luck!

    -Fowler

    Thursday, August 30, 2012 8:02 AM
  • Hey Everyone, I thought I could give a little insight. I ran into this problem recently. However, we can certainly rule out with 100% accuracy any software installs, updates, upgrades etc. The reason I know this is because I have a test server that this just happened to. The good news is that this server is a virtual server, that being said, I just reverted back to a clean server state, with a snapshot after joining the domain.

    Hmmm, still getting the error. Although not resolved, I have eliminated all the above. What I believe it is, is another DC on the domain has lost its trust. This has nothing to do with the PC giving the error, but rather the PDC.

    Thoughts?
    Paul


    Duramaxster

    Friday, September 14, 2012 3:09 PM
  • Hi,

    How can a DC with lost trust communicate at all? Do you perhaps mean that the client has run into a DC that is corrupt? Then you have to look into the clients eventvwr and know exactly when and which DC.

    It has to be related to the PC because the error rate has decreased dramatically in our environment. But as I stated earlier, this is an abnormal symptom. You will always get this error if you have duplicate clients etc.

    Another proof is that we discovered policies run on our clients, was wiped away after the automatic startup repair had run.

    That means that startup repair is wiping and resetting vital elements in order for the client to communicate ok with the DCs.

    Rod

    Thursday, September 20, 2012 10:35 AM
  • Just a note, if it were useful, some manufactures non Microsoft use 445 port as RPC port. I think that, since W2K, Windows uses port 445 for RPC and SMB also, obvius when NetBIOS is not used.
    Tuesday, September 25, 2012 12:41 PM
  • We are running into those issues too. The last two cases: Windows 7, change computername in Active Directory and in client. Everything all right, user is working OK. The client is power down for the ninght. Next day trust relationship with domain is failed: rejoin and OK. In one client the issue run twice.

    Tuesday, September 25, 2012 12:50 PM
  • In my Organization we have insolated and solved the problem: we have a disjoint domain, the problem arises when computer dnshostname is not the same than domain acount dnshostname.

    I think it is a problem with Kerberos and Service Principal Name.

    • Proposed as answer by Baterias Friday, October 05, 2012 7:01 AM
    Friday, October 05, 2012 6:44 AM
  • Easy Peasy:

    http://implbits.com/About/Blog/tabid/78/post/don-t-rejoin-to-fix-the-trust-relationship-between-this-workstation-and-the-primary-domain-failed/Default.aspx

    Reset the machine password...I bet if you look at the machine accounts in LDAP/AD the machine account password has recently been updated.

    Tuesday, October 09, 2012 2:30 PM
  • We also tried to reset the machine account without success.

    This week we had only 1 case with trust relationship and again, the computer had run startup repair.

    We found the minidumpfiles and prooved it again.

    Tuesday, October 09, 2012 9:15 PM
  • The Rich Master!

    This solved it for me, failed at first, when I ran the command against DC1, failed to logon again, then ran it against DC2, worked! Success!

    Regards


    Thomas Balkeståhl - Technical Specialist - SharePoint - http://blog.blksthl.com
    Download 'The SharePoint Branding Project' here
    Download 'The final guide to SharePoint 2010 Site Settings' free whitepaper here
    Download 'The final Kerberos guide for SharePoint technicians' free whitepaper here

    Wednesday, October 10, 2012 8:40 AM
  • Rich Meister, thanks.  I've used netdom in the past using the /reset switch to reset the secure channel, but that hasn't worked when I've had this problem in recent years.  Also, using "Reset Account" in ADUC hasn't worked often and as far as I know, that is the same as using netdom /reset.

    The problem is that netdom /resetpwd must be run locally.  Because for us this problem almost always happens on regular users' workstations, it means every time this problem occurs, you need to download and install RSAT (or Admimpak).  For this reason, I wouldn't call it "easy peasy".  In fact, you might as well just remove/rejoin after using "Reset Account" (to keep the SID from changing) because that will probably take less time.

    Even though that may still be helpful to know, I am more interested in solving the cause of this issue in the first place.  We recently had a very angry director due to about 20 machines in his department having this problem all within a short time.

    Baterias, I'm interested in hearing more about the DNS issue.  It seems to me that I've noticed over the years that when we have this problem, the workstation's DNS record usually is different than the SAM account name in AD.  I need a description of the process and where it is failing, if it's possible to provide that, because our DNS setup is unusual in and how it relates to AD.  If I know where in the AD authentication process the failure occurs, I'll be better able to tell if it's due to our DNS setup.

    Saturday, October 13, 2012 10:06 PM
  • The issue for us was that the internal whole name of computer, for example: mycomputer.microsoft.com,  not be the same name than Active directory DNSHostname attribute, for example: mycomputer.london.microsoft.com.

    If this names are not identicals then the attribute ServicePrincipalName is wrong also. This atribute is very important for kerberos.

    Whe I correct the atributes in AD, then Windows 7 computer be able to logon in domain, without reboot computer.

    Monday, October 15, 2012 11:05 AM
  • Baterias, thanks for the reply.  I think our problem is different
    than the problem you describe.  I believe the DNSHostname attribute
    always matches the SAM account name in our environment because we only
    have one domain, and as far as I know, the DNSHostname is simply the SAM
    account name with the domain name appended to it. 

    In our domain, we just seem to randomly have workstations lose their trust with the domain.

    The workstations themselves have DNS A records on our BIND DNS servers and these records often do
    not match the workstations SAM account names.  These clients resolve names using BIND DNS and there is a delegation in BIND to our AD integrated DNS servers for AD SRV record queries.

    I don't see how the incorrect A records in BIND should cause any problems for the workstations that have these incorrect records.  Can anyone confirm whether or not I am correct that this should not be the cause of the problem?

    Thanks

    Tuesday, October 16, 2012 2:11 AM
  • Really struggling with this issue and it's causing a serious impact to my productivity.

    First of all, I'm aware of the "fix" that is being recommded.  I've contact our CenterBeam tech support center 3 times now over the past 6 months and blown an hour each instance to have someone with network admin rights take me off the domain and rejoin me.  But that is only a temporary fix because the problem keeps recurring.

    Here's what's triggering the recurrence:

    Enterring my domain password incorreclty over a WiFi network.  Once I do this, I get the "trust relationship failed" error even when I enter the password correctly on subsequent logins.  I've repeated this test multiple times and can state with certainty that this is the trigger.

    This error occurs imeddiately after the failed password entry and then every time the computer is locked.

    If I go into sleep and unsleep via the power button, I can circumvent the error. But that increases my startup time and is not an ideal solution.

    So, any suggestions from Microsoft?

    Tuesday, October 16, 2012 8:46 PM
  • I don't see any way mistyping the password for your account can possibly cause the machine's account to lose trust with the domain.  I think what you are seeing is that your machine has already lost the trust with the domain and as long as you type your password correctly, you can log on via cached credentials.  Once you typo on your password, the machine cannot log you on with cached credentials, it tries to check with AD to see if your password has been changed, and that's when it lets you know that the computer has lost its trust with the domain.

    If you want to see when the computer has lost its trust, just check the System Event log for NetLogon errors.  If you read those (and they will always be there after a reboot), you'll see that the trust is broken.  In fact, look backwards in the System Event Log over time and you may be able to tell how long it took for the errors to begin again after the domain rejoin.

    The goal, which seems to be difficult to achieve, is to find out why this happens in the first place even in a healthy AD domain.  This does kill productivity, as you have seen, but you need to be careful about making assumptions about what the cause is.

    Wednesday, October 17, 2012 1:46 AM
  • We ran into a similar issue, with a couple of machines recently. We simply unplugged them (physically) from the network, had the user login and then plugged them back in.  

    The user was able to login fine after that.

    Wednesday, October 17, 2012 12:52 PM
  • We ran into a similar issue, with a couple of machines recently. We simply unplugged them (physically) from the network, had the user login and then plugged them back in.  

    The user was able to login fine after that.

    we had to do the same thing and the user had no issues after either
    Friday, October 19, 2012 5:56 PM
  • This pops up for us from time to time, it seems when an end user gets a new computer and we wish to reuse the old name.  I have made sure that the old PC's name is out of the way (change it, or leave the domain) then go into AD and make sure it is nowhere to be found, then join the new PC with the recycled name.

    This morning I had it happen again.  Everything was fine on Friday but the user reported today that they got the "trust" error msg.  I looked in AD and the name was gone, but I'm 100% positive that I'd seen it Friday and put it in the right container.

    I don't know what's going on.  Just did the leave/rejoin domain thing and all is well now.  Thankfully here it has been an uncommon issue, maybe 5-6 in a year.

    Tuesday, October 23, 2012 12:54 PM
  • The case you describe is a little different.  You said that the computer object was gone.  (I assume you meant gone from the domain, not just moved to a different container.)  If the computer object is actually gone, then someone or something had to have deleted it.  In that case, it's very much expected that the trust would be lost.  Most of the posts above describe where the computer object still exists in AD, but for some reason the trust is still lost.

    Cheers

    Wednesday, October 24, 2012 1:05 AM
  • A computer object can just "disappear" when a new computer is deployed into the domain with the same SID e.g. when an un-syspreped image is deployed.

    Wednesday, October 24, 2012 9:56 PM
  • Yes, multiple computers having the same SID is a real problem.  But are
    you saying that if computer1 is a domain member and computer2, which is a
    clone of computer1 is joined to the domain later, that the computer
    object named computer1 will be renamed to computer2?  We are so careful
    to use Sysprep, I don't think I've ever actually seen what happens when
    you don't use it in an AD scenario.

    Thursday, October 25, 2012 3:28 AM
  • This doesnt work when you've got a domain which holds up to 10,000 workstations and 10+ PC's show these trust issues every day..

    Please do not propose as answer, because its not.

    Tuesday, November 13, 2012 12:22 PM
  • We have about 30 machines, laptops and desktops, connected to AD. We have only recently implemented AD....had it for a couple months....and I'm now seeing this error manifest on one workstation. The user in question switched from a laptop, to a temporary desktop, and then to a new replacement laptop. The user name in AD didn't change. Her password has changed multiple times in the span of a couple weeks due to all the computer switching, temp logins, etc. It seems that this is clearly part of the problem. She can rejoin the domain by unplugging, logging in, and plugging back in. Obviously, this is less than ideal.

    Any new insights on this??

    Tuesday, November 13, 2012 11:53 PM
  • Sarah- Thank you for this information. We are a mixed 2003 and 2008 AD schema and this issue has happened only on our W7's and 2008 server installs.

    We have GFI MailArchive installed on one of our 2008 boxes and this issue was really causing a problem with LDAP auth to our DC's.

    I followed option #2 above and as of now have not had the issue reoccur.

    Thank you again.

    -Derrick

    Friday, November 16, 2012 2:14 PM
  • Hello,

    "we disable the automatic machine accouint password change" Alone with a different password than the first time, you can come back from the backup. What you should do:

    Problemin temel kaynağı olan (computer account password) makine hesabı şifresi ile problemli makinede kayıtlı şifrenin eşleşmemesidir. 

    Aktif dizin’de makine hesabı (computer account) şifresi varsayılan olarak 30 günde bir değiştirilir. Aynı kullanıcı hesaplarında olduğu logon esnasında hesabın bu 30 gün süreyi doldurup doldurmadığı kontrol edilir. Kullanıcılar için şifre değiştirme ekranı gelirken makine hesapları şifresi netlogon servisi tarafından otomatik olarak güncellenir. 30 gün süresi dolan ve aktif olamayan hesaplar, aktif olduğunda güncellenir. 


    Problemin temek kaynakları için birkaç örnek:

    1.Durum: Birden fazla DC'niz var ise ve bunlar arasında replikasyon sorunları var ise olabilir.

    2.Durum: Etki alanı (active directory) ‘de yaşanan bir problem sebebiyle yedekten dönme işlemi yapılmış olabilir.

    3.Durum: Makinenizde yaşanan bir problem sebebiyle yedekten dönme işlemi yapılmış olabilir.

    Her iki durumda da yedekten dönme zamanı, şifre değişim zamanına denk gelmiş olanlar makineler problemden etkilenecektir.

    4.Durum: DC üzeriden veya RSAT üzerinden makine hesabı resetlenmiş olabilir.



    Sorunu asagidaki komut ile giderebilirsiniz. Yalniz "netdom.exe" 'yi bilgisayarına ya RSAT kurarak yada asagidaki linkten download edebilirsin.  Netdom.exe sadece windows'un sunucu versiyonlarında yüklü olarak bulunur.


    netdom.exe resetpwd /s:[server] /ud:[user] /pd:[password]

    [etkialan] = Etki alanı (active directory) adınız veya IP adresi Ör: “Test.com” veya “192.168.100.1″

    [user] = Etki alanı (active directory) yetkili bir kullanıcı. Ör: “sisyon” veya “Administrator”

    [password] = Kullanıcıya ait şifre. Ör: “Aa12345″ veya “*”


    Download netdom.exe and script: http://siberblog.org/wp-content/uploads/2012/10/netdom_trust_script.rar

    Ayrıntılı olarak incelemek istersen: http://siberblog.org/index.php/the-trust-relationship-between-this-domain-and-the-primary-domain-failed/

    Daha da ayrıntılı analiz etmek ve tüm dc üzerinde sorunlu makineleri tespit etmek istersen:
    http://siberblog.org/index.php/active-directory-analysis-the-trust-relationship-between-this-domain-and-the-primary-domain-failed/

    www.siberblog.org



    Sunday, November 18, 2012 10:18 PM
  • My department is dealing with a very similar incarnation of this issue. We manage hundreds of Dell Latitude laptops that are doing this same thing. The problem machines are E5410s, E5420s and E5430s running Windows 7 Enterprise 32-bit connecting to a 2008 domain. We are coming across machines regularly that are giving the "The trust relationship between this workstation and the primary domain failed".

    I've been keeping a list of the machines that do it and so far there have been no repeat offenders. In keeping with what others have said, unjoining and rejoining to the domain clears up the issue.

    One thing we've also been doing is checking the registry key HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets\$MACHINE.ACC\OupdTime

    This gives the time the machine thinks it last set it's AD password. I just got done checking one that was imaged on 9/27/12 and shows the password set on the same date, which is to be expected. AD, however, shows the password was changed on 10/30/12. Despite this discrepancy, the machine was logged into regularly up until 11/14/12. I didn't get the call to come check the machine until 11/29/12. So 30 days after it was imaged, it tried to reset it's password. AD shows that the change completed successfully, yet the machine shows a password set date from when it was imaged. I don't know where machine AD passwords are stored locally, but I suspect something is making the machine restore a backup copy of the registry or go back to a restore point or something. Just a hunch, not sure how I can reproduce it...

    This is where we are with trying to figure this problem out. Just thought I'd contribute.
    Friday, November 30, 2012 1:47 PM
  • Hi

    Re startup repair

    "I have seen cases where it brings the system to an old system state , this happens in the background and it is not noticed by the users"

    Are you saying startup repair can run while the system is in use and without user knowing? I though it only run at boot time.

    Wednesday, December 12, 2012 1:15 PM
  • Try this GPO.. It resolved my issues.. There seems to be an issue with DeepFreeze too. But this GPO should take care of it.

    Computer Config | Windows Settings | Security Settings | Local Policies | Security Options | Domain member: Disable machine account password changes - Enable this policy.

    This will not resolve the issues for machine already having trust issues but will prevent future one.

    Thanks : \ Shah

    Tuesday, December 18, 2012 5:30 PM
  • That certainly should solve the problem going forward, but what about the security risk of having member computers that never change their passwords?

    Tuesday, December 18, 2012 6:00 PM
  • Indeed. But it all depends on the environment and its requirements. This technet article talks about the security risk you broughtup and also talks about when you might consider this "solution'.

    Thanks: \ Shah

    http://support.microsoft.com/kb/154501

    Tuesday, December 18, 2012 10:47 PM
  • There may be numerous reasons why this error occurs but I believe one of them is a timing issue, which has been mentioned that wireless devices seem to be more susceptible and this could be during a reset of the computer account password.  I just had a customer call with this issue, although she had two issues, the primary being her display was only showing a black background and her white mouse pointer.

    Display issue resolved, she could not login to the domain because of a lost trust relationship.  As has been suggested, we turned off the wireless switch, logged in, turned it back on and everything was fine.

    I have done what others have done in the past, removed the workstation from the domain and added it back and of course, you then deal with profile issues.  However a trick has been used to rejoin using the NetBIOS domain name instead of the DNS domain name.

    Ex. domain and domain.local

    Whichever was set previously, use the other one and you would be reconnected and not have to deal with profiles.

    I'm wondering if the issue is the password being changed on the DC and then trying to re-establish from the workstation with the new password and because of a timing/communication issue, not able to connect and thus the infamous error message.  It appears once this happens, it appears to cache it so you cannot recover and by disconnecting from the network so the DC cannot respond, the workstation is forced to use the cached account.

    Maybe someone at Microsoft could confirm the new password is not permanent or will rollback once the user has authenticated with the cached account and perhaps the computer account password is then retried or ignored until the next time it attempts it again.

    It could even be simpler, timing is off and you get the error because it cannot communicate properly with the DC.  Once authenticated via cached account, it gets what it needs to connect and sync with the domain.  I'm throwing out possibilities but if logging into the cached account re-establishes the connection, there doesn't appear to be a permanent fix, without compromising security.

    Tuesday, January 22, 2013 5:10 PM
  • At this point I am throwing in my lot with the idea put forth by Fowler. I don't know if it has to do with the fact that Startup Repair recovers some backup of the registry and that throws it out of whack, but this only happens with Windows 7 and it seems to happen on machines that have gone through Startup Repair.

    Tuesday, January 22, 2013 9:33 PM
  • I would love to hear any further news on this thread as we are having the same issue with Windows 7 machines imaged via SCCM 2007r3 (so no sysprep problems)

    And it seems random - machines working fine one day and not the next.  I'd like to think MS would have picked up on this thread now as it's still current.


    Chris Bilsborough UK NHS Support Technician

    Wednesday, January 23, 2013 4:32 PM
  • We've been seeing this issue sporadically too with our Windows 7 machines (machines "imaged" using OSD in SCCM 2007 R3).  The event log typically shows that after a startup repair has been initiated, the machine then loses the trust relationship.  I've also not been able to logon to the machine using the user's UPN (user@domain) as I've read on a few online articles.

    The Help Desk team used to do the re-join domain trick and then having to fix up the profiles afterwards, but it would also screw up the SCCM client as they were not getting any apps being deployed (that's how the issue got my attention) and they would eventually swap out or rebuild the machine.

    I've only just started investigating this and have used the netdom.exe resetpwd solution and that has worked.  I've not yet tried the unplug network cable trick to confirm that it has worked in our environment (I will try that with the next one I get).  I will also be trying the bcdedit /set {default} bootstatuspolicy ignoreallfailures command too, and will report the findings in a week or so.

    Wednesday, March 06, 2013 7:43 AM
  • Just to throw in another fix I've used successfully with this annoying issue. Unfortunately you need to log in as local admin and have a Domain Admin account ready.

    1. Control Panel - System
    2. 'Change Settings' under Computer Name, domain, and workgroup settings
    3. In System Properties, click 'Network ID...'
    4. 'This computer is part of a business network...'.  Next
    5. 'My company uses a network with a domain'. Next.  Next
    6. Type in Domain Admin credentials
    6a. You should see a dialog that the computer account has been found in domain...'would you like to use this'?  Yes.
    7. Do not add any accounts
    8. Finish and restart

    This just indicates the lost connection between machine and AD object.  Hope it helps in future troubleshooting.

    I check one of the problematic machines with ADSIEdit and found that badPasswordTime was set to 50 minutes after lastLogonTimestamp and badPwdCount was at 20. 


    Windows 7 x64, Forest/Domain 2003, mix 2k3, 2k8 DCs, imaged with SCCM2007
    • Edited by DanArseneau Monday, March 18, 2013 5:54 PM Forgotten details
    Monday, March 18, 2013 3:05 PM
  • Dear All,

    I have faced this issue and came to know that this is happening due to Bios conflicts of pc's within the same network. if the Host name names are matching within the same network then the conflict will raise and it will temporarily resolve when we dis join and rejoin to domain but the permanent solution is to change the host name and make sure that the new name is not matching with any other pc's. hope this will be helpful for you all.

    Thanks & Regards,

    Roopesh

    Saturday, March 30, 2013 3:09 PM
  • Dear All,

    I have faced this issue and came to know that this is happening due to Bios conflicts of pc's within the same network. if the Host name names are matching within the same network then the conflict will raise and it will temporarily resolve when we dis join and rejoin to domain but the permanent solution is to change the host name and make sure that the new name is not matching with any other pc's. hope this will be helpful for you all.

    Thanks & Regards,

    Roopesh

    When you say "BIOS conflicts", what exactly do you mean? I think you are referring to a similar practice in the organization I work at. Our machines pick up their computer names for the domain from the Dell Service Tag in the BIOS. We came across two laptops that were exhibiting symptoms of this trust relationship problem that happened to have duplicate names. However, this has not turned out to be a prevalent cause of the issue in our case. It could be that it was in that case, but we have lots of machines that do this without any relation to duplicate machine names.
    Monday, April 01, 2013 12:38 PM
  • Went through prolonged troubleshooting porcess and ended up running bcdedit /set {default} bootstatuspolicy ignoreallfailures against all Win7 PCs.

    The issue has not happened since then.

    Troubleshooting steps

    For each PC that had this symptom, logged on as local admin and checked hklm\security\policy\secrets\$machine.acc\OupdTime and CupdTime.

    N.B. where value is converted using nltest.exe e.g. OupdTime = 57 ca e6 71 60 39 ce 01 convert with nltest /time:71e6ca57 01ce3960

    Checked the values against PwdLastSet on AD object (use adsiedit to view).

    In all cases OupdTime\Cupdtime was about 30 days behind PwdLastSet

    Next checked $windir\system32\LogFiles\Srt on problem PC and saw that in most cases there was SRT activity around the time the trust relationship issue started.

    By chance I was told about another problem of Win7 machines spontaneously reverting to their SCCM deployment names(minint-xxxxxxx) shortly after they were renamed to "corporate names" - names for corresponding AD objects reverted too.

    Found SRT activity at time machine names rolled back but all affected machines had been deployed within 30 days of problem. All such incidents stopped after deploying bcdedit /set {default} bootstatuspolicy ignoreallfailures

    My take on all this is that SRT ran for some reason and reverted to previous system backup. Where the local machine password did not match machine password in AD, the "...trust relationship between this workstation..." issue occurred.

    Where the local machine password still matched machine password in AD, the machines were effectively renamed to the original machine name at the time the system backup was taken.

    Where the local machine password still matched machine password in AD, and a system backup was taken after the machine acquired its "corporate name", no one even noticed that anything unusual had happened.

    Thursday, April 18, 2013 2:13 AM
  • We are using a vb script to set the bootstatuspolicy and recoveryenabled settings:

    On Error Resume Next
    
    Set WshShell = WScript.CreateObject("WScript.Shell")
    intReturn = WshShell.Run("bcdedit /set {default} bootstatuspolicy IgnoreAllFailures", 0, True)
    intReturn = WshShell.Run("bcdedit /set {default} recoveryenabled No", 0, True)
    We realised that this issue mainly occured when a users laptop had ran out of battery and just shut down (not a clean shutdown).  On next boot up, it would detect that the previous shutdown was not successful, it would then boot into Windows Recovery Environment.  Users would generally call the Help Desk and at the time, the Desk would run through the recovery which would roll back the system to it's last restore point.  In our environment, we disable restore points by GPO, so it's last restore point would have been made when software updates was last run while GPO was not applied, which for us is during SCCM OSD.  This causes the mismatch in machine password and thus trust relationship issue would appear.
    Thursday, April 18, 2013 5:00 AM
  • Doesn't work with win7 virtual machines.  I can't even log on with the local admin you just get the same message.
    Monday, April 22, 2013 5:36 PM
  • Bit hard to do with a virtual machine.  Starting and stopping through the Hyper V console doesn't have the same 'reset' ability as with real machines.

    I've been bashing my head off this most of this afternoon and I think it has something to do with 'identity'.  I've just built a nest of 10 VMs, then they were lost before I could back up [don't ask] so I'm thinking ok at least I know now how to do it and have learned lots so I'll be back up in no time. I don't use sysprep.  I use the hyper v to create a new image from a fresh install then just copy and re-do that.  It worked fine before I just took the new machine off the domain then renamed it and added it back.  No problems and no error messages until today and this afternoon.  I'd built up to number 6 yesterday and today I was going to get through to 10. So I copied [as usual the vhdx file from VM6 into a folder called [imaginatively] VM7 and then pointed the wizard at it when creating a new VM. All fine. I do all the twiddly bits and check various things [nothing major] and then I have cause to go back to VM6 to check something.  That's when the trouble started. Try to connect to it and bang the error message.

    Ultimately I'm going to have to use a much earlier image to create the next few which means that maybe something in the things that have slowly changed over the last couple of days have caused this.  Maybe the last updates to the MS security essentials?  Maybe the the last windows updates [8 as I recall],  but it wasn't to do with the method or the image per se.  Somehow when renaming the machine it hasn't forgotten its previous identity is my guess [yes I know it is a non technical guess but really I haven't the time for in depth 12 month research, I need to know NOW how to get further along].

    I will report back tomorrow when I've tried an earlier image, now I'm going to soak my head in a barrel of cider.


    • Edited by jake6257 Monday, April 22, 2013 7:11 PM typo
    Monday, April 22, 2013 7:09 PM
  • I am having the same problem but this happened after I had run system recovery when a user downloaded multiple viruses. I had a recovery point from 2 days ago so password is still good but now I am unable to login with user nor admin. Have tried to rejoin domain from but also unsuccessful. Any ideas?
    Tuesday, April 23, 2013 9:20 PM
  • Is it a VM Cindy?  If so I just detached the virtual hard drive, deleted it and used an earlier version.  It was a pain to do the updates etc but better than starting from scratch.

    If it is a real machine I can only suggest you power down and unplug the the network cable, then boot back up to force it to use the cached passwords.

    I meant to comment today on how I did fighting the dreaded 'untrustworthy domain monster'.  I managed to get all my VMs back but as I said just using an earlier image.  I'm sure if I had the time, budget and resources [like microsoft] I could be definitive but I haven't.  What I am pretty damn sure of is that it is either the SSID or some other identity criteria that doesn't get forgotten/deleted. I'm near certain it is duplicate identity of some kind.

    This may be significant [if using VMs] but I'm also getting  the 14050 error VMMS admin now, this too dates back to when I first started with the domain error.

    Pretty certain that if I had a brain I'd be able to work it out but we can't have everything we want can we?

    Tuesday, April 23, 2013 10:39 PM
  • It isn't a VM and I tried unplugging the network cable and rebooting - no go. It is a laptop for one of our employees who is having some medical issues so it contects to the network using Remote Access most of the time. My system recovery point was right after the Microsoft update that ran 4/16 so I am a little suspicious that something in that update may be contributing to the problems but this machine was pretty bad when I got ahold of it (24 suspect programs downloaded in a 2 day period). I will probably have to wipe it clean and rebuild the dumb thing - don't like the fact that the admin account was also disabled. Users - can't live with them, don't have a job without them.

    Wednesday, April 24, 2013 2:55 PM
  • Well good luck Cindy.

    I have come across some clever viruses and trojans recently. They close down your anti-virus, switch off the firewall then won't allow you to switch them back on or update. a lot come in the sneaky toolbars that every site wants people to download and if you aren't careful and tick some obscure box you get the toolbar and then a load of trash with it. I did come across one that disabled the admin account too but that was some time ago. I seem to remember we got around that by having another admin account but named rescue or something.  It didn't shut that down.

    Wednesday, April 24, 2013 4:18 PM
  • Ok guys hopefully the end to you misery, I support over 30 different domains on a weekly basis and this problem has occurred in a few of them. The problem is caused by dns records not updating them selves properly let me explain. A computer account needs to update it's self with the domain at a certain number of days. The password for the computer account is changed and the domain controller needs to pass this information back to the work station. This is where it fails as the DC will talk to the wrong workstation. Log on to your machine locally and take a look at the IP address, then log on to a dns server in your domain and you will see that more than likely the dns A record is different from what you are showing.  To stop it happening again you will need to look at the dns server and set scavaging and make sure DHCP is automatically updating DNS dynamically. If you want to prove it delete all the A for workstation records from the server once every 25 days and the problem will go away. Then you can take a look at what is causing the problem.

    Once the pc has lost its trust it will need adding manually.

    • Proposed as answer by mick-uk Friday, April 26, 2013 8:56 AM
    Friday, April 26, 2013 8:56 AM
  • It's weird but I went to the DNS server for something else yesterday and thought I'd clear a few of the old A entries off that were no longer used. I also wondered breifly what would happen if I deleted them all. I didn't have time to experiment then but I can see that from what you've said they are all going to be re-created when the workstation logs on again.  Correct?
    Friday, April 26, 2013 9:35 AM
  • We have a convoluted method of dynamic DNS on our network and I have told people that this does seem more likely to happen when the DNS name doesn't match the NetBIOS/SAM account name on our workstations, and what you're saying seems consistent with that.  However, this is the first time I have heard that a DC needs to initiate a connection to a client.  Are you certain that this happens?  Are there any MS articles that describe this?  I have never heard that DNS records are a requirement for AD clients, but they would be necessary in this scenario.  If you or someone from MS can confirm this, it would be great.

    Thanks.

     
    Saturday, April 27, 2013 4:25 AM
  • Machine account password process:

    http://blogs.technet.com/b/askds/archive/2009/02/15/test2.aspx

    Saturday, April 27, 2013 5:31 AM
  • Thanks for the link.  There is nothing in the article that says the DC needs to initiate a connection to the client in the password change process.
    Tuesday, May 21, 2013 1:07 AM
  • Hi,

    I don't think that's the problem. I have over 300 PC's  and all were installed using Windows CD, and this problem happens randomly.

    What I have noticed, this problem happens now more frequent with Windows 7 deployed. We rarely had this problem with XP.

    Thursday, July 04, 2013 6:53 AM
  • Hi there,

    I've been following this thread for a while now and may have found a solution for the issue.

    Please have a look to see if Windows restore/recovery has been run on the machines dropping off.

    We found that on all the windows 7 machines that threw the error, someone had been doing a dirty shutdown thus causing recovery to run.  As this would restore the machines to an earlier config it was using an old machine password.

    Switching it off has prevented any further occurrences.


    Chris Bilsborough UK NHS Support Technician

    • Proposed as answer by CFS3rd Saturday, October 19, 2013 5:18 AM
    Monday, July 08, 2013 7:29 AM
  • We just had 1 machine with similar behavior of sporadically losing the trust and not being able to login. For us it turned out to be that the pc was randomly losing its network connection and the switchport it was plugged into didn't have cisco spanning tree portfast set. So after it lost connectivity the switchport would block traffic for about 30 seconds and that delay caused the Domain issue. Since fixing the switchport setting the issue has stopped. Just one more thing to check. 
    Wednesday, July 24, 2013 5:17 PM
  • The easiest way to troubleshoot this issue now is with PowerShell and the test-computersecurechannel cmdlet. If needed, here is a guide on how you can troubleshoot the trust relationship and repair it remotely:

    http://deployhappiness.com/the-trust-relationship-between-this-workstation-and-the-primary-domain-failed/ 


    If my answer helped you, check out my blog: DeployHappiness. Subscribe by RSS or email. 

    Friday, October 11, 2013 2:10 PM
  • Here is a quick response, which often fixes the issue. Make sure you know the credentials to a local account with admin privileges. 

    Right click "Computer". Select "Properties". To the right of "Computer name, domain, and Workgroup settings" select "Change Settings". Click "Change". Select "Workgroup". Name it something random. Click "OK". Enter credentials, and restart the PC.

    Once the PC is back up, log in using a local account (not domain). Then follow the previous steps except select domain, and enter your domain. Click "OK". Restart. 

    Now it's fixed.



    Friday, October 11, 2013 4:51 PM
  • Thank you, but the resolution for dejoin/rejoin the computer to the domain has been posted throughout this article in excess of 10 times already.

    However, this is only a bandaid solution, the problem continues to return causing users to have to spend valuable time on repeating the fix every time it occurs.

    What is being discussed here is the root cause of the issue and how it can be permanently circumvented in the future.

    Thus far I see no answer to this. The best suggestion I have seen so far is stale DNS records in the zone list which can be resolved by enabling Scavenging on your DNS servers, or simply use static IP addresses in your organization if possible.

    Would be nice to see MS weigh in on the discussion...


    Network systems and Server 2003 systems administrator.

    Friday, October 18, 2013 5:06 PM
  • I think that this is the most common cause of this issue.  I have begun to realize the same thing on our network where the user says that their machine automatically ran repair before it lost it's domain membership.  We have almost 400 Windows servers and the only time this problem happens to the servers is if we revert to a VM snapshot, or do a full system restore from backup.

    Saturday, October 19, 2013 5:28 AM
  • Hi there,

    I've been following this thread for a while now and may have found a solution for the issue.

    Please have a look to see if Windows restore/recovery has been run on the machines dropping off.

    We found that on all the windows 7 machines that threw the error, someone had been doing a dirty shutdown thus causing recovery to run.  As this would restore the machines to an earlier config it was using an old machine password.

    Switching it off has prevented any further occurrences.


    Chris Bilsborough UK NHS Support Technician

    Further to this, this is the command we are using to do this in our Windows 7 Build (and soon to be pushed out via GPO)

    After monitoring the situation (setting up a problem for our service desk to attach the incident to) we've found that after disabling the restore we have had no further repeat instances of this.

    bcdedit /set {default} bootstatuspolicy ignoreallfailures


    Chris Bilsborough UK NHS Support Technician

    Monday, October 21, 2013 7:11 AM
  • We're in the same boat as many of you.  We are in a hybrid 2003,2008 AD domain (multiple DCs) with one forest and two domains.  I would describe our AD environment as very complex with multiple DCs and hundreds of GPOs.  We are in the midst of our XP-7 migration.  We're using Dell Kace to deploy a scripted install of Windows 7 Pro with post install packages applied after.  This is practically no different than using a real DVD to do all of the installations.  The install re-uses the same machine name to re-add the newly imaged machine to the domain.  AFAIK This only happens on laptops docked(wired) and undocked(wireless). 

    I have been able to reproduce this at will by hibernating the laptop (undocked wireless) overnight and then logging in, locking and logging back in 10 times (which some of you may know is the default number of cached logins allowed by secure channel communication on a 2003 DC and 25 on a 2008 DC).  On the 11th time I purposefully enter my password incorrectly.  It says hey this isn't correct.  Login attempt 12, with correct password, produces the trust relationship error.  The quick resolution to this error is to hard reboot the machine.  I have been able to reproduce this two mornings in a row from a hibernated laptop over wireless. 

    Kerberos ticket default expiration is 10 hours.  When the machine comes out of hibernation it still has a Kerberos ticket that it now recognizes as expired.  But because secure channel allows 10 cached logins it allows your user to keep logging in and out.  UNTIL they fat finger their password.  Then it's forced to go back to a DC and verify that they still have the right information.  That's when it realizes that it's secure channel is broken and there is no longer any trust with the domain.  I have also been able to reproduce this after a 1.5hour interval by purging the Kerberos ticket on the machine.  After coming out of hibernation login and open a command prompt and do klist purge.  Then perform the 11 login/lock/login maneuver.  On login 12 it will cause the trust relationship error to happen. 

    I have some more testing to go such as wired vs wireless and applying some of the ideas in this thread. I can tell you for a fact adding/removing/rejoining does nothing to fix the root cause of this problem. It will almost always come back.  Reordering the providers worked on one unit and not on another.  I'm hopeful that the nic setting to allow the OS to turn off the wireless nic when it's powered off being disabled may provide some relief.  It makes sense from a perspective when you come out of hibernation you should be logged back in and get a new Kerberos ticket and all should be well.  But if there is some delay or some reason why your PC cannot communicate properly with the DC to do that such as wireless not really functioning properly then it would explain the whole issue.

    My intuition tells me this is related to Kerberos Ticketing, Timing, Hibernation and perhaps machine account password as others have noted.




    • Edited by JUrschel Friday, November 01, 2013 4:14 PM
    Friday, November 01, 2013 4:09 PM
  • I only speak English, but bekir's netdom command did the trick for me. Here are the details.

    Once every 6 months, I perform a disaster test:
    1. I used shadowprotect to restore a backup from Server01(Prod) to a hotsite box Server01(Test).
    2. I logon to Server01(test) with my Windows 7 laptop and verify that I can get at the restored system.

    I have done this for 3 years with no problems, but 10 to 15 days after the 10/1/2013 test my laptop started to get The Trust Relationship error message.

    I think the trust problem started when server01(test) battery had failed, and the CMOS date became 2008. During the disaster test my laptop's time synced to 2008. After the test, I manually reset the laptop date, and could logon to production normally for about 10 days.

    After the 11th day, I could only logon by bypassing the annoying message: disconnecting the Cat5 > login > reconnect Cat5 > ipconfig /renew

    I tried changing my password several times and rebooting several time, and the trust messages continued.

    To fix the problem, I reconnected the Cat5 and did the following:
       1) got a working copy of netdom.exe for my laptop (from http://www.microsoft.com/en-us/download/confirmation.aspx?id=7887)
       2) logged on as the local administrator
       3) issued this command.

       Netdom.exe resetpwd /s:server01 /ud:Joe.Doe /pd:*

    Rebooted, and the problem seems to have gone away.

    Surprisingly, I was never asked for server01 administrator credentials.
    Also, getting the netdom.exe module was a pain because it comes in a 250 meg download with dozens of other tools.  
    But, I think it would work fine if I copied c:\windows\system32\netdom.exe to another computer via flash drive.

    Hope this helps someone

    Thursday, November 14, 2013 6:18 PM
  • We experience this problem (reproducible) when deleting files from the Windows harddisk using a different operating system.

    This may be evil, but I use a Linux boot DVD with several virus scanners to check suspect computers. Last time I just deleted some files from the %temp% folders of several users in which I found some viruses. In the end, no domain user (even those with unchanged home folders) could log on to the computer but got the message this thread is about.

    Putting the computer into a workgroup and then putting it back to the domain fixes the problem, but I would really like to understand the cause for this. Maybe the Linux NTFS drivers left the file system in an indifferent state?

    Thanks,

    Peter


    • Edited by Peter St Wednesday, December 04, 2013 11:46 AM
    • Proposed as answer by Heathybaby Thursday, December 05, 2013 10:06 AM
    • Unproposed as answer by Heathybaby Thursday, December 05, 2013 10:31 AM
    Wednesday, December 04, 2013 11:45 AM
  • "The trust relationship between this workstation and the primary domain failed." 

    After reading though many of the proposed answers some of them seem very complicated for a relatively simple problem (for workstations). When a machine has the problem is has lost its Security Identifier (SID) which means the domain no longer trusts it because the machine has for some reason got its own SID and not the one given to it by the domain (think of it as a password)

    We have had many Win 7 machines with the same issue, and the way we have corrected the problem is by using the Network ID wizard, if your run the wizard it will talk to the domain  and actually ask for the SID that originally been given to the machine and the Domain re-establishes the trust…but it remembers the machine asking  so if this happens again it checks its valid and re-establishes the trust, thus correcting the issue automatically. If however you add the machine to a workgroup and then back to the Domain the issue will return as the Domain will issue a new ID.

    Hope this helps

    Thursday, December 05, 2013 4:02 PM
  • Just as I mentioned in my post way back when.  The full instructions are there as well.  I think everyone is really trying to understand why it happens in the first place and perhaps a way to prevent it.  So far I haven't seen any definite answers to that.
    Thursday, December 05, 2013 4:18 PM
  • Just as I mentioned in my post way back when.  The full instructions are there as well.  I think everyone is really trying to understand why it happens in the first place and perhaps a way to prevent it.  So far I haven't seen any definite answers to that.
    In response to the above to reiterate; we have had no further repeat instances of this incident since we pushed out the command quoted below.  I believe this to be the answer.

    Hi there,

    I've been following this thread for a while now and may have found a solution for the issue.

    Please have a look to see if Windows restore/recovery has been run on the machines dropping off.

    We found that on all the windows 7 machines that threw the error, someone had been doing a dirty shutdown thus causing recovery to run.  As this would restore the machines to an earlier config it was using an old machine password.

    Switching it off has prevented any further occurrences.


    Chris Bilsborough UK NHS Support Technician

    Further to this, this is the command we are using to do this in our Windows 7 Build (and soon to be pushed out via GPO)

    After monitoring the situation (setting up a problem for our service desk to attach the incident to) we've found that after disabling the restore we have had no further repeat instances of this.

    bcdedit /set {default} bootstatuspolicy ignoreallfailures


    Chris Bilsborough UK NHS Support Technician


    Chris Bilsborough UK NHS Support Technician

    Friday, December 06, 2013 8:32 AM
  • I've managed to do enough research throughout tech net, spice works, and a few blogs. The cause of this is that a local account is created in the same "refresh" login as the computer is joined to the domain. So in other words. This will happen most of the time if the computer is deployed the local account (other than the administrator) is created and the computer is joined to the domain before it is restarted. I guess you could say a simple fix (it was for me, your situation might be different as it usually is) is to create your user accounts, do any other changes (accept join the computer to the domain) restart, then, join the computer to the domain and it will (should) be working properly.

    P.S. if you use the Deployment Workbench you can customize the task sequence to do all of this for you and have it all be completely unattended.

    Friday, December 06, 2013 3:05 PM
  • So this issue appears to be related to a few things happening:

    1. System decides that it needs to run system repair tool (SRT) most likely due to unclean shutdown process or actual data corruption.
    2. User clicks repair which performs a background system restore.
    3. Machine account password sync with DC is broken and user does not report to IT that they ran the SRT.
    4. DC and machine are not able to re-sync the machine account password. (I'm intrigued by the DES/AES situation mentioned above.  Will need to look into that further).
    5. System may be able to operate until a particular period of time/failed logins transpires. (Usually over a weekend or at 6PM on a Friday) :-)
    6. Admin has to rejoin PC to the domain or use NETDOM to reset the machine account password.

    It amazes me that some people re-image to resolve this issue.  I guess if you have a super-fast imagine process, but what a waste of time.

    I had a user email me today with the above problem and she had run the SRT.  Tech onsite was able to rejoin to the domain to fix the issue.

    So sorting through all of the chaff in the posts above, it appears that running (at least for us enterprise users with AD with GPOs):

    bcdedit /set {default} bootstatuspolicy ignoreallfailures

    will prevent the SRT from running?  My question is what is the impact besides preventing users from having access to this tool?  Does something go "un-fixed" as a result?  Is it something that we need and can be useful?  Is it still accessible by holding down F8 (haven’t been able to test yet).

    I had another user who had a two year old PC.  They reported system was booting to SRT.  OEM diags indicated the HD was dying.  OEM sent out new HD and after running Spinrite on the drive, I was able to image over user's config.  I only did this because they had a very specific set of settings and programs installed.  I normally like to install clean and deploy apps via scripts that we use.

    Two days later it happened again.  Again it appeared the HD was dying and the onboard system diagnostics pointed to the HD.  Again the OEM sent us out a replacement drive, but issues persisted.  A few days later a second tech was looking at the system and noticed a system hang with diagnostic codes that pointed to the motherboard.  Everything looked fine and we had a hard time reproducing but as machine was under warranty OEM sent out new MB as we were able to produce failure codes.

    After new motherboard install the machine has been solid.  The moral is that sometimes the cause of users getting the SRT screen can be a much bigger problem.  I’ve been burned a few times trying to find the needle in the haystack until I think to run memtest86+ and discover I have bad RAM in the system.

    Sure would be nice if there was a way to alert us when a user runs the SRT so we could just run NETDOM or if the OS was smart enough to sync with the AD somehow after running a restore.  I guess we can again write scripts to check the C:\Windows\System32\LogFiles folder for SRT activity but it isn’t clear to me what this would look like.  Would it be in a \SRT directory?  Doesn’t appear to be there by default.  Perhaps only after use of SRT.

     


    Saturday, January 04, 2014 5:27 AM
  • Would you be willing to share how you enabled this/what registry entries/GPOs to enable?  Did this fix your issue?  Curious as to why the rejection would happen at random.  Shouldn't it either work or not work at all?
    Saturday, January 04, 2014 5:41 AM
  • This is exactly what happened in 3 instances in my Enterprise environment.

    Great answer, thanks for the post.


    MikeD

    Wednesday, January 15, 2014 5:32 PM
  • Any update after enabling DEC on Win7 and Win2008r2? we have mix env of win 2k3 and win2008r2 DCs. We also imaged win7 using GHOST. The win7 machines we used sysprep we haven't any problem on those so far.
    Tuesday, January 28, 2014 11:23 PM
  • This solves the problem for each individual machine but does not really address the issue requested.   GP wants to know why it keeps happening to different machines.  The machines were joined successfully.  They worked.   Then they stopped and gave these errors.  They can be "fixed" individually, but unless we know why they broke, they may (and do...) break again.

    What causes a broken trust relationship?

    There is another way of fixing the issue;  But may require it to be done during non business hours.

    Re-imaging these PC's will also fix the issue;  And as it pertains to a large scale fix;  Network push images to all the effected machines simultanously at night during business down times.  That's pretty much the only solution to deal with the large scale issue.  However, the issue is caused by windows on the individual PC's it will happen to my knowledge and is uncureable, but not untreatable.

    I have encountered this issue many times involving citrix or VDI environments on large scale locations.

    That being said the only 2 known fixes are to re-image or re-join the domain.   As a deskside service technician we do not always have admin rights to the local admin accounts, and as such only re-imaging will work.

    Hope this helps.


    • Edited by FlukeLSX Friday, February 07, 2014 5:35 PM
    Friday, February 07, 2014 5:33 PM
  • I haven't tested this method, but I found this configuration item on Group Policy Editor:

    Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network access: Do not allow storage of passwords and credentials for network authentication

    The 2008 R2 technet reference for this configuration (http://technet.microsoft.com/en-us/library/jj852185.aspx) says: 

    This security setting determines whether Credential Manager saves passwords and credentials for later use when it gains domain authentication.

    It is a recommended practice to disable the ability of the Windows operating system to cache credentials on any computer where credentials are not needed. Evaluate your servers and workstations to determine the requirements. Cached credentials are designed primarily to be used on laptops that require domain credentials when disconnected from the domain.

    Disabling this item on the domain controller policy sounds like what you need since most of users uses laptop



    • Edited by a_SkyBlue_ Monday, February 17, 2014 6:02 AM
    Monday, February 17, 2014 6:00 AM
  • While it is not a solution I have found that further information and scenarios can help identify the problem.  At my work we have a Win7 Pro workstation which multiple users log into.  The domain server is offsite and reached through a wireless signal which comes into the building and then is hard wired.  All users have the same access levels and passwords are set to never expire. (pls understand I am not the network admin... I gave that job up a long time ago).

    2 users out of 12 on the same machine have experienced this trust relationship error and it has only recently started to occur.  It did seem to start after the last Windows 7 update was applied to this particular machine.  Since other users such as myself can log on to the same machine to the same domain with no problems that would leave me to believe the issue has something to do with the individual user account.  If I put the wrong password in for one of the two accounts we are having problems with it gives me the same error.  That tells me that the issue probably has nothing to do with the user's password as I am thinking if the trust is not there, the server isn't even looking at that information.  Both users the trust issue occurs with have a tendency to stay logged for long periods of time (close to 2 weeks) and may have been logged in during the last win7 update application.  This Win7 machine will also not shut down on its own, it has to be physically powered down.

    I am really not up on the IT side as much as I used to be but hopefully that can help.



    • Edited by CPLGUN Tuesday, February 25, 2014 10:35 AM
    Tuesday, February 25, 2014 10:11 AM
  • Check Whether there is any other system with same HOST NAME. . I got the same problem in our organisation and Finally I found that there are two machines with same HOST NAMES.  
    • Proposed as answer by KING.IND Friday, March 07, 2014 8:09 AM
    Friday, March 07, 2014 8:07 AM
  • How do we know that this has been successfully performed on a machine, other than to crash it, and see if SRT comes up on the next boot?
    Monday, March 10, 2014 6:38 PM
  • I'm amazed this thread has run for over 2 years and still there is no definitive cause.

    And yes, I am randomly seeing this issue.

    Tuesday, March 11, 2014 10:59 PM
  • This has been happening at random on our network as well. Some on the LAN some on the WAN some over VPN connections. Mostly it seems to be tied to specific user accounts. I have had them bring in the laptops or towers and logged in under the admin account without an issue, yet when trying to log in under the users account still get the trust relashionship error. Even after pulling it off the domain and rejoining the problem disappears for a while but then happens again to the same user. Short of deleting and recreating the user's account I havent found any permanent solution to the problem.
    Tuesday, March 25, 2014 9:24 PM
  • "I'm amazed this thread has run for over 2 years and still there is no definitive cause." - I'm amazed too...

    Can anybody from MS at least tell us if it's a bug or by design?

    Thursday, March 27, 2014 11:33 AM
  • Hey All,    I am a lenovo certified tech and I have recently started reschearching this error. We were lucky enough to find this issue while the PCs are still under warranty. Currently I order a replacement system board and the fault goes away. If some of you are lucky enough to you can go that route.

    If I figure anything out I'll be back

     
    Thursday, March 27, 2014 5:51 PM
  • Interestingly, I have this same problem on 3 totally unrelated domains, using different servers, WinXP, 7 & 8, so it's obviously a "known" issue (I intend to check with our team to see if we can find more occurrences than we're noticing).  We're ALL tired of randomly rejoining computers to the domain, and it's obviously a chronic problem, but MS doesn't seem to have a functional answer (not that I find that really surprising).

    Has anyone noted a common "theme" here? 

    I have 2 observations to add:

    It almost always happens after a user changes their password.

    Restarting (often multiple times) invariably clears it.

    One user may get the error, and another won't when they try immediately afterwards.

    Tuesday, April 01, 2014 8:27 PM
  • I have the same issue.

    Our windows 7 pro are sysprep and cloned by ghost. This issue is happened randomly and just re-join to domain to solved it . However, we want to find the cause and solve it forever.

    Is there any solution found? thanks a lot

    Monday, April 07, 2014 8:55 AM
  • Thank you Sarah! The wizard (option 4) took care of my computer.
    Tuesday, April 08, 2014 9:22 PM
  • I found an issue for those imaging with WDS, which most likely would affect any program that images computers.  The answer file used to join the computer to the domain requires an admin password to join the domain.  If that password is changed, the machines that used the old password to join the domain start giving the Trust Relationship error when they attempt to authenticate the machine account and/or with the KMS server.  It seems that the password used in the original image must match the current password of the domain account used during the original imaging process.  I'm not sure where it is stored (haven't had time to look yet) but noticed the pattern on our domain after imaging machines with a new password in the image process, same user name.

    Friday, April 18, 2014 6:26 PM
  • I am having this problem; however, the computer will not allow me to log on locally so I can remove it from the domain.  In the past, we have formatted the computer in these instances.  Is there any way around formatting it if you can't log on locally?
    Monday, June 02, 2014 2:40 PM
  • I found our issues were related to a non removing group policy setting that configured the encryption standards

    We had set the following policy and it had run to most systems but hadn't removed when the policy was removed

    Policy was -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Network Security: Configure Encryption Types allowed for Kerberos

    This was set to not enable AES - this was fine for the XP clients but as soon as Windows Vista / 2008+ were installed then AD considered it should use AES and expected it. This caused clients requesting access to resources on those devices that could support AES to try and use it but when the data arrived at the machine in question it couldn't understand the AES encryption and so denied the request.

    This extended to the machines themselves as an example logging onto AD - AD expected AES encryption and didn't get it so didn't accept the request to log in. It was a two step process to recover from this

    1. In order to log back onto the server

    Find the machine in ADSIEDIT (or a windows 7/2008 version of AD users and computers as this has the attribute editor tab)

    search for the MsDS-SupportedEncryptionTypes attribute

    Select Edit

    Select Clear

    Select OK

    This will allow a logon to the machine and will re-populate shortly

    2. Logon

    ON the server go to regedit

    HKLM->Software-> Microsoft->Windows->Current Version->Policies -> System

    If the policy has been in place there will be a kerberos key with a parameters subkey and a value of supported encryptiontypes

    If this is present delete the Kerberos key and all subkeys

    Reboot the server

    This solved all our issues

    Monday, June 02, 2014 4:47 PM
  • Check out the active directory settings in the server. There might also be a time limit set that is responsible for the trust issues. Cheers!
    Tuesday, June 03, 2014 3:18 AM
  • Disconnect from network and login with cached domain credentials.
    Monday, June 23, 2014 9:31 PM
  • Perhaps some people have experienced this bug :

    DNS Host record of a computer is deleted after you change the DNS server assignment

    http://support.microsoft.com/kb/2520155


    Wednesday, June 25, 2014 9:25 AM
  • Good morning,

    I just setup a new Server 08 R2 domain in a Hyper-V VM on Server 2012. We have joined 5 clients, and 2 are having trust relationship issues.

    These machines were added directly to the domain out of the box from dell.  Server is also brand new out of the box. It has been 1 week since the user was created in AD and then the PC setup.

    My question is, who is expected to pay for this? My client is unhappy with the time I'm investing in repair (right now an hour or 2, but MANY hours if it continues), and based on the length of these comments, there is no cause, fix, or help in sight.

    I did not Ghost or sys prep any of these machines. They are literally plug in, add to domain, log user in, install apps. I am at a loss as to how to prevent this from continuing or explaining the cause since even Microsoft does not appear to know.

    Please advise how to explain to a client that Windows simply doesn't work correctly, Microsoft has no idea why or how to prevent it, and the client needs to pay for it.

    Thanks for reading.

    Tuesday, July 08, 2014 3:56 PM
  • Rich

    I as well just had a client with this issue today.

    I have seen this issue for at least a year or so by now.

    The only Microsoft Recommended solution is always Disjoin and Rejoin the domain.

    Today I found a PowerShell command that will fix the issue without having to Disjoin reboot and rejoin.

    Here is what happened to my client today:

    User leaves computer on overnight in an SBS 2008 / Windows 7 environment.

    User leaves files open, Outlook open and locks the PC.

    This morning the user tries to Login via Remote Web Workplace and gets the " The trust relationship between this workstation and the primary domain failed " error.

    User remembers that they have been receiving a message that password will expire in 4 Day's and logs into Terminal Server to reset password / Attempts RWW again and still trust error.

    I did some research and tested this workaround as follows.

    I did an RDP session to the Domain Controller / Then did an RDP to the Workstation

    Logged into the pc with a local administrator account.

    Opened Windows PowerShell

    Ran this command with my clients information:

    Windows PowerShell

    PS C:\> Reset-ComputerMachinePassword -Server DC01 -Credential Domain01\Admin01

    An Authentication pop up occurs.  Enter Domain\DomainAdministratorAccount  enter password

    Log off as Local PC Administrator  and now you can log in as the User.

    It is a little less time to do this, but what saved this user was the fact that Files were open and possibly not saved. I was able to use the Switch user to Reset the computer machine password and the files were still open and intact.

    Reference:
    NOTE: I can't paste a link here

    Do a Google search for hh849751   (Reset-ComputerMachinePassword)

    Good Luck.

    If anyone hears of a Fix as opposed to a work around for this issue, please let me know.

    Thanks.

    Chris

    Wednesday, August 13, 2014 6:44 PM