In the spirit of people being wrong on the internet, I wanted to briefly discuss something people rarely get right: the computer account password.

Twitter warning: Like all good things this is mostly correct, with a few details fuzzier than others for reasons: a) details are hard on twitter; b) details are fudged for greater clarity; c) maybe I'm just dumb.

Your computer has an account in Active Directory and that account has a password. This account is what makes Kerberos work. When you want to communicate with this computer you encrypt tickets to the account password.

When your computer wants to act as itself on the network (instead of, say, you) it uses it's password to authenticate to the domain controller. Things running as SYSTEM or NETWORK SERVICE operate as the computer account on the network.

That's why you see COMPUTERNAME$ in DC event logs. Because it's literally the computer account authenticating to-and-fro.

But the thing people get wrong repeatedly is how this account password is managed.

Well, it turns out it's deceptively simple. You have this service on your computer called netlogon. Within this netlogon service is a timer. Every few days it polls a domain controller to find out when the password expires, and if it's nearing expiration it changes it.

See, netlogon is the service that makes function calls to Active Directory on behalf of your computer. There are a handful of ways you communicate with a DC: Kerberos, NTLM, LDAP, and RPC. Netlogon is the RPC bit, and this has historically been called the Secure Channel.

Incidentally not to be confused with SChannel which is the Windows TLS/SSL provider. They are not related.

So Windows uses netlogon to rotate it's computer account password.

The process is fairly simple.

  1. Timer wakes up, connects to a DC, see's its been 30 days
  2. Netlogon generates a password locally, stashes it, authenticates to the DC with the old password
  3. Calls ChangePassword(newPassword)
  4. DC acks
  5. NL Replaces old pwd with stashed pwd

But what happens if that fails? The DC isn't available or the change call doesn't succeed?

Nothing. Notta. Zilch. Not a thing. A big whopping zero.

See, *computer* password changes are optimistic. Until you get a confirmation you must assume it's the old password.

The reason you must assume it's the old one is because of continuity of service. If the computer can't change it's password because it's been WFH for 6 months what happens when you're back in the office? Well, you've now got 10k very annoyed computers to fix manually.

This is incidentally the source of many fantastically incorrect takes on how Active Directory works.

Take: expired computer passwords cause the trust to be broken.

Fact: nope. Computer passwords have an exception to the lockout policy. They just keep on truckin with the old password.

Take: expired passwords cause computer accounts to expire.

Fact: nope. Just, nope.

Take: computer accounts that haven't logged on in so many months are expired.

Fact: nope.

Take: computer accounts that haven't logged on in so many months are deleted from the directory.

Fact: nope. This isn't a feature in AD. Domain admins like to run scripts that periodically purge such computers and *that* is the source of many problems.

For all intents and purposes computer accounts don't break on their own nor do they break because of any built-in timers in Windows. That said...

Computer accounts do break. This is very clearly seen when you find you can't log into your machine anymore with some obscure workstation trust error.

There's fundamentally only a handful of reasons this happens.

  1. The computer lost the password
  2. The computer account was deleted

(2) is pretty obvious. An admin or some third party process removed it. Happens all the time. DELETE * WHERE LASTLOGGEDON < 3mo

But (1) is more problematic because it's insidious -- Windows as a rule doesn't just lose things. 

This can occur when system secrets get corrupted. Machines are not infallible. Drives fail, processes aren't transactional, bugs go boo, etc.

Thankfully the fix is usually super easy: Test-ComputerSecureChannel -Repair

But that generally shouldn't be required. Windows doesn't especially care that the password hasn't changed in forever. It'll happily rotate it the next time it has line of sight, but until then it'll just keep on truckin like nothing is wrong. Because nothing is wrong.