The trust relationship between this workstation and the primary domain failed, what does this mean?


Just like users, machines have domain accounts. And just like user accounts, machine accounts have passwords. And just like user account passwords, machine account passwords expire (by default, every 30 days). Now, you don't normally notice any of this because machines automatically change their machine account passwords before they expire.

Well, you notice it when something gets messed up.

One way you can trigger a password mismatch is to roll back a VM past a password change point. The machine will roll back to using the old password, which is not the correct password any more.

Another way you can run into this is by leaving a machine off the network for a few months. The machine password on the domain will expire, and the machine will be locked out of the domain.

If you get into this state, the standard solution is to leave the domain, and then rejoin it.

Bonus reading: How to disable automatic machine account password changes. The article also describes why machine account passwords expire in the first place.

Comments (34)
  1. Steve Donaghy says:

    Yup, we encountered this quite a bit when we dust off a work laptop that hasn't been used in a while. As crappy as the solution is, we just upped the password expiry to something like 180 days. After that, just installing missing updates is probably slower than simply reimaging the machine.

  2. Brian_EE says:

    And then you have to call the helpdesk to fix this for you because non-administrative users aren't allowed to join a machine to the domain.

  3. Anon says:

    And then the help desk agent finds out that the computer was deleted from AD, and then the only real solution is to reimage the laptop.

  4. Wayne says:

    @Brian EE – Non Admins can join machines to a domain at least up to 10x since windows 2000.  

    support.microsoft.com/…/243327

    support.microsoft.com/…/251335

  5. Timothy says:

    @Anon – if the computer account was deleted from ad, the solution is the same: unjoin and rejoin.  If you are reimaging it under guidance from your admin, that admin is either ignorant or trolling you.

  6. Xv8 says:

    @Wayne – But you need to be LocalAdmin on your machine, which (hopefully) your average user is not.

    Plus it is Best Practice to change that value to 0 as soon as possible. At least according to my MCSA books and the Windows Best Practices Analyzer. At which point you need Domain Admin (or another delegated group) membership too.

  7. AndyCadley says:

    @Wayne – In theory, yes. But every Domain Admin I've ever known very sensibly switches that off. If not before the first time someone joins something to a domain they shouldn't, then very soon afterwards!

  8. Brian_EE says:

    @Wayne – unless your corporate IT organization configures it so you can't.

  9. Kate says:

    Can also mean you gave another machine the same name then joined it to the domain, overwriting the first machines computer account.

  10. Greg W says:

    Or, if you're lucky and it's just an expired password and you have access to PowerShell 3.0+: Reset-ComputerMachinePassword (technet.microsoft.com/…/hh849751(v=wps.620).aspx).  No need to unjoin and rejoin.

  11. BugBug says:

    Actually, I think you're wrong, Raymond. Machine account passwords shouldn't ever expire. They are always changed by the client machine.

    The article you linked to explains "[why they do]" actually explains *that they don't* – that is, the password entry attached to the security principal doesn't expire – and that it's always a client-initiated change. There have been bugs over the years in handling this logic (Memory: W2000 in one Service Pack suddenly started treating Computer principals like User principals, and all hell broke loose on networks with more restrictive password policies than their machine account reset interval, and this change was reverted in the next), but fundamentally, machine accounts do not – and should not – respect the password policy implemented for users, and are excluded from password expiry logic. They only change when computers ask them to.

  12. cheong00 says:

    @BugBug: Machine accounts should still need password (secret) to prove it's identity.

    You know, a number of programs (mainly Windows Services) run as NetworkService account so it can access external resources using credential of the machine's AD account. This arrangement is useful if the service need to access a network share that shouldn't be accessable to everyone. (The most common case is, a folder on SAS to store images uploaded to a website, that contains confidential data)

    In that cause, you don't want a random machine named the same computer name be able to access the share without authenticating first. That's why it needs to have password like normal user so it can prove it's identity.

  13. cheong00 says:

    Also, the computer account is also used to authorize DNS update of the DNS server in your domain. You won't want to allow any members in your domain to be able to update the DNS records for all computer names in the domain. If every computer joined domain can update DNS record for all other computers, any infected PC in the domain can cause DNS poisoning to the network.

  14. BugBug says:

    @Cheong00 – "Machine accounts should still need password (secret) to prove it's identity" – right.

    But we're discussing *expiry*, not impersonation. Your point implies that my point is that computers don't need passwords, which is wrong. Computers have passwords. I'm saying that Windows Domain Controllers don't require machine account passwords to expire. If they did, what would the practical implication be?

    How does a machine account password change? The client machine proves it has knowledge of the last password (preventing random same-name client scenarios as you've suggested) and updates it with its new chosen password. But again, client initiated. When the bugs popped up around this in Windows 2000, it was because telling a computer "your password expired" is meaningless – it will do the same thing it always did anyway, or simply fail.

    If additional controls have been added since then which control computer account expiry, I am very interested to learn of them.

    This isn't an external process, this is the client machine doing it. DCs don't rotate the password for the computer and then tell it after the fact. DCs don't initiate anything, so unless the client changes its own password, the password is unchanging, and (unless there's something newer than 2003 which does this) un-expiring.

  15. cheong00 says:

    @BugBug: I think it's more a left over on the history.

    You know, the old NTLM authentication is subject to L0phtCrack password cracking, but computers before Vista still need to be able to talk the NTLM protocol or Win9X machines cannot access the network shares (NTLMv2 is available only on Win2kSP3 or above). So the password have actual need to change periodically to reduce the risk.

    Don't know if there is still a reason for keep changing it now.

  16. BugBug says:

    @Cheong00: You're arguing around the point. There is still a reason to update the computer password periodically. My point is that it doesn't expire like a user password.

    "Expiry" is where the DC decides the current password is not usable as an authenticator until it is changed to a new value. I believe (in the past: know) that this does not happen for computer accounts, and at the very least, does (or should) not happen on the same schedule as user password policy changes. Computers were exempted from that.

    Even though machine passwords aren't (weren't?) held to user password policy, computers "naturally" want to reset their password every 30 days by default. This is also fine, as long as you don't have frequent rollback events.

    But the fact that you can disable computer account password changes by setting a registry key *on the client* should tell you all you need to know about the situation – i.e. it's voluntary, and computer passwords aren't designed to *expire*.

  17. cheong00 says:

    As noted in technet.microsoft.com/…/jj852252.aspx ,

    In Active Directory–based domains, each computer has an account and password, just like every user. By default, the domain members automatically change their domain password every 30 days. Increasing this interval significantly, or setting it to 0 so that the computers no longer change their passwords, gives a malicious user more time to undertake a brute-force password-guessing attack against one of the computer accounts.

    You need expiry date so a computer that's "no longer used" but not "unjoin" from AD (which happens a lot in most companies, especially for those with lots of notebooks, or under exercise of computer replacement batches) do not linger as targets for the company for brute force attacks.

  18. BugBug says:

    @Cheong00: Yes. But you still seem to be missing the point.

    Where do you see "expiry" in that? "Expiry" is a server-side concept. Perhaps try answering this question: After 30 days, if the computer doesn't reset the password, what happens to the password? Answer only using words you can find in that article.

    Quoting links which don't disagree doesn't help your position. If you were actually looking to disagree, you'd quote the part where the article descends into nonsense – if my contention is correct:

    "2.Some organizations prebuild computers and then store them for later use or ship them to remote locations. If the computer's account has expired, it will no longer be able to authenticate with the domain. Computers that cannot authenticate with the domain must be removed from the domain and rejoined to it. For this reason, some organizations might want to create a special organizational unit (OU) for computers that are prebuilt, and configure the value for this policy setting to a larger number of days."

    That's just idiocy, so unless someone enabled account expiry again (at the user password rate) and failed to document it, that's a bunch of work for nothing useful. If computers initiate their own password changes *AND* accounts never expire, you don't need to do this. If you reinstate machine images all the time (i.e. a computer gets rolled back to a point earlier than it changed its password), you do need to do this.

    Let me rephrase: Client-initiated change is like saying to yourself "I need to reset my Facebook password every 30 days." But if I forget, it doesn't change, and there's no penalty for that.

    Expiry is like Facebook saying "you must reset your password every 30 days, and if you don't, you can't do anything else until you change it".

    My contention is that AD doesn't *expire* machine account passwords. Or didn't. Or shouldn't. Not that computers don't or shouldn't change them. Please provide documentation for or against that point with any response.

  19. BugBug says:

    blogs.technet.com/…/test2.aspx explains it quite well, and corresponds with my understanding of the process.

  20. cheong00 says:

    [Where do you see "expiry" in that? "Expiry" is a server-side concept. Perhaps try answering this question: After 30 days, if the computer doesn't reset the password, what happens to the password? Answer only using words you can find in that article. ]

    Actually, only 5 words are used in the quoted text – "brute-force password-guessing attack".

    The other parts are just fitting it in a very common real world scenario.

  21. Neil says:

    Leaving and rejoining the domain is all very well but difficult to execute remotely.

  22. GDwarf says:

    Cheong00: You're missing BugBug's point. Yes, computer objects change their domain password every 30 days. That is, *the computer itself* does the change. The DC doesn't force the change. BugBug is saying that if you turned a computer off for 31 days it could still talk to the domain because the DC doesn't care how old the password is, only the computer cares.

    I don't know if BugBug is right, this is a bit beyond my wheelhouse, but you're arguing a point they aren't making.

  23. Wayne says:

    @AndyCadley I agree that is sensible, especially considering technet.microsoft.com/…/ms15-096.aspx just pointing out that by default its allowed.

    @Xv8 – an average user will call helpdesk no matter what, they wouldn't know how to disjoin and rejoin the domain.

  24. cheong00 says:

    @GDwarf: And you totally missed my point that this policy is for protected the computer accounts of computers being thrown away, i.e.: their password administration manager will no longer have the chance for updating the passwords.

  25. DWalker says:

    This argument seems to be about terminology.  Raymond used the word "expire" in the original post, which, as has been pointed out, is probably not *exactly* the right word.  Or, you can say the machine password "expires" or "ages" but that "expiry" is not enforced.  So it's not really expired.  

    The rest is all just noise.  Yes, there is a good reason why the DC wants the computer to change its password every 30 days (I think this is cheong00's point).  Yes, the computer will not get locked out if it doesn't (I think this is BugBug's point).

  26. Chris says:

    @Bugbug   Actually, things work exactly as Raymond described.   If a computer doesn't contact a domain controller for a long amount of time(i.e. over the 30-day password change window), its machine password will no longer be recognized by the DC, and you'll need to re-join it to the domain.   That sounds like expiration to me.

  27. BugBug says:

    @Chris: I agree that what you're saying sounds like expiration. I'm interested in whether there were further behavior regressions after 2000 SP1/2 ? (where it went back and forth).

    So, please complete the sentence and provide supporting documentation: Computer account passwords expire when [blank].

    If there's a number of days, what's the number? If there's an OS version requirement (i.e. only X, or later than Y), what's the OS?

  28. bzakharin says:

    Ah, the memories. At my first job, before we finally went to a VM solution, we had two machines called "test server" and "test client". Each had two hard drives. Drive C: had Windows 2000 (and later 2003) server and workstation respectively. Drive D: had folders for installations of Windows with all major supported versions of our application. When development was complete, you would boot into drive C: and copy the required Windows installation to the root directory of drive D. Then you would boot into drive D:, apply your patch, and have another developer perform "independent testing" where you sat with them at told them what to do. The trust relationship thing was a common issue, but not the only one. Sometimes the SQL installation would not run because for some reason, the short directory name for "Program Files" was not always consistent. You'd have to regedit and then change all references from progra~1 to progra~2 or whatever. For some reason I don't recall the trust relationship issue once we went to VMs. By then the company was much bigger and I guess someone knew how to configure the VMs. We also had testers and test plans, so all you had to do is set up the right VM.

    Off topic: shortly after I was hired (as a developer), someone realized that drive D: on the Test Client was a lot larger than the one on Test Server. I was tasked with opening up the boxes and swapping them.

  29. David Totzke says:

    From:

    <a href="blogs.technet.com/…/a>

    "Machine account passwords as such do not expire in Active Directory. They are exempted from the domain's password policy. It is important to remember that machine account password changes are driven by the CLIENT (computer), and not the AD. As long as no one has disabled or deleted the computer account, nor tried to add a computer with the same name to the domain, (or some other destructive action), the computer will continue to work no matter how long it has been since its machine account password was initiated and changed.

    So if a computer is turned off for three months nothing expires. When the computer starts up, it will notice that its password is older than 30 days and will initiate action to change it. The Netlogon service on the client computer is responsible for doing this. This is only applicable if the machine is turned off for such a long time."

  30. David Totzke says:

    Well, that link got mangled.  That's what I get for trying to do HTML in a comment:

    blogs.technet.com/…/test2.aspx

  31. Mark Ransom says:

    @David Totzke, your link certainly does seem to state with some authority that a machine turned off will have no problems connecting later. But my experience opposes that, and is in line with Raymond's description – if I don't log in with my virtual machines at least once a month, they get locked out. Until today I had no idea how to fix it. I use an Outlook reminder so I'll start them often enough to prevent the problem.

    Even if AD doesn't automatically expire a machine, it's possible that our network administrators do it on a regular basis, perhaps even programmatically. The first link at the bottom of the page is "How to detect and remove inactive machine accounts".

  32. cheong00 says:

    Yes. It's good to remember removing inactive machine accounts, especially for the retired Exchange servers. I vaguely remember reading something in Technet article that, it's possible to reconstruct everything (except the contents in mailbox) of an Exchange server solely by using the configuration data stored in the server's machine account object in AD. If you're responsible for information security of your company, I don't think you'll tolerate the possibility of this kind of information leakage.

  33. Chris says:

    @BugBug @David

    Hmm, that article might explain *some* of what I was seeing.

    The computer changes its own password internally, WITHOUT CHECKING WITH THE DC FIRST.

    It only contacts the DC AFTERWARDS to inform the DC of the password change.

    If it goes through 2 password changes without contacting the DC, it won't have a record of the password that's stored with the DC.

    However, this doesn't explain other things I've seen, where computers that haven't been used in forever get the workstation trust relationship error.  (It's not from it being removed from the domain; you can still see the computer account in AD)

  34. 640k says:

    I'm not satisfied before a client computer can saturate the network link by only sending newly updated passwords, and make them change on the DC. Then we're talking about changing passwords rapidly. Once every 30 day is a joke.

Comments are closed.

Skip to main content