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

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.

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?

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

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...

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

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.

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.

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.

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

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.

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...

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

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

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....

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??

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

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?

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?

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.

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.

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...

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

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

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.