Thread by @lkarlslund

Don't lose trust! "The trust relationship between this workstation and the primary domain failed." Have this ever happened to you? I'll show you how to fix it, and (more interestingly) how it works behind the scenes 1/🧵

First some basics: when you join a computer to an Active Directory, it gets a machine account in the AD. This is like a user account, but with objectClass value 'computer' (and others) and some userAccountControl flags indicating it to be a computer (0x1000). But ... 2/🧵

It uses a password to authenticate to Active Directory controllers. Every once in a while (30 days default) it rotates the password. If you roll back a VM, restore from backup or clone two machines, the computer's idea of the password and the AD password can get out of sync 3/🧵

Then you get the dreaded "trust relationship" error message. Years ago the recommended fix was to 1) disjoin the computer 2) delete machine account in AD 3) join the machine to the AD again. This is hopeless, for many reasons! Also it's entirely unnecessary 4/🧵

To fix it, you need admin access to the machine. There are multiple ways to do this 1) local admin account 2) unrotated LAPS account (unlikely) or 3) cached domain account which is local admin. 4) break into machine with your fav ISO and pwn local administrator account. 5/🧵

Congrats, you're local admin. Now sync the password using PowerShell - provide an AD account that has the power to "Reset Password" on the machine account. That's it, problem solved! If you're in the mood for some history, read on ... 6/🧵

There are multiple non-working suggestions on how to fix this on the internet. A popular one is using the "Reset Account" GUI option in Users & Computers. This does not work, but what does it actually do? 7/🧵

We need to go back in time, when Windows 2000 was the cool thing (it was!). Things were simpler, and machine accounts were ... uhm, also "simpler". With simpler I mean they used the machine name as password. (Check out @Oddvarmoe's recent post on this). 8/🧵

The NT5 code base (Windows 2003) is all over GitHub (thanks, @Microsoft and evil hackers!) so I went hunting for this oddity. I found it replicated 4 different places in the source ... the old Windows source is a goldmine for knowledge if you're into that kind of stuff. 9/🧵

Enough history, you get the picture. Do "Reset Account" procedure on the machine object in the AD = it sets the password to "lowercased machine name" :-\ Yes, that simple. Useless today, but no one has been squishing bugs on "Users & Computers" for many years, so no wonder 10/🧵

You can validate the "Reset Account" functionality by doing it, and then testing the password. I used HashCat against the LM hash (thanks @UK_Daniel_Card for the registry NoLMHash hint!). But just use PowerShell if you want. (Script from powershellbros.com/test-credentia…) 11/🧵

So to sum it up: locally stored machine password and AD password must match. Resyncing them is possible and easy, but must be done on both ends at the same time for it to work. 12/🧵END