AD - Account Lockout vs Disabled

tl;dr - Disabling an account in AD will replicate normally, which can give an attacker quite a bit of time :)

What

Account lockout vs Disabled account

• Disabling an account sets a flag in the userAccountControl
• This attribute is handled via normal replication
• Locking an account out is when an accounts BadLogonCount exceeds some threshold ( Lockout-Threshold )
  • This sets the lockoutTime and Lockout-Duration attributes on an account, and then is handled by immediate replication instead of “normal” replication
  • Edge case - this also gets compared against LastBadPasswordAttempt
  • Also useful to note, this attribute isn’t replicated :)

‘Normal’ replication, how fast is that?

• Intra-site

  • i.e. Head office is full of domain controllers, replication between these
  • 15 seconds, with a 3 second pause for the next replication partner (i.e. Other DC’s)
  • Handled by the msDS-Replication-Notify-First-DSA-Delay and msDS-Replication-Notify-Subsequent-DSA-Delay attributes configured on a site

• Inter-site

  • i.e. Someone did AD properly, and put geographically disparate domain controllers in different AD sites
  • This is less common in AU than you’d think, FYI
  • 180 minute replication

• Exception - “Urgent Replication”

  • This is immediate
  • Will always replicate to all domain controllers on the same site, at the same time (ignores the msDS-Replication-Notify-First-DSA-Delay and msDS-Replication-Notify-Subsequent-DSA-Delay attribute)

Curiously, an account unlock is not immediate - so you can be waiting 180 minutes for an account lock to come into effect in a remote office.

You can change inter-site to replicate immediately with ‘Inter-Site change notification’, but I haven’t seen it deployed in any of the places I’ve checked - but perhaps it’s common elsewhere?

Why does this matter

If an insider threat materialises (read: an attacker you had on payroll), disabling their account isn’t going to do much, almost to the point of they could drive to another remote office and still log in to steal a bunch of stuff.

This is completely ignoring that kerberos tickets for an account are going to last for hours, so if an attacker steals kerberos tickets, you’re going to be in grief for a few hours.

Also worth mentioning that if their machine is still logged in, and they didn’t lock their windows box - they’ve still got a machine they can use until other systems stop accepting kerberos credentials (i.e. sharepoint, where you’re keeping all the goodies)

Keeping that in mind, if you want to offboard your employees:

• Lock their account
  • Using the wrong password on an auth attempt a couple of times is going to work well here, don’t bother doing it via ADSIedit
• Take their machine off them
• Figure out where they’re logged in, and kill their sessions
• No idea on Kerberos, does a password reset invalidate existing TGT’s as they’re encrypted with the users password anyway?