[photon_rancher]

This is true for basically any AD windows login. If you log in with an account on a machine on your domain, then take that machine offline and change the password elsewhere- you can login with the old password.

If you instead restore network access after it’s been offline long enough - depending on the exact process it will still accept the old password. Entering the old password isn’t enough to trigger domain check in. However, if I recall correctly entering an incorrect password will cause the login window to hang for 30+ seconds while it attempts to perform such a check in to see if your password changed in the interim. This will usually fail - but not always.

It’s probably bad behavior but it’s probably configurable in the domain settings. But it makes the user experience terrible because logging in gets super slow, because domain syncs in azure/ Active Directory are super slow.

[robertlagrant]

How is this offline if you're RDPing into it?

[zamadatix]

Offline can mean anything from "not able to connect to the internet" to "no networking active whatsoever" depending on the context. In this case, "not able to connect to AD for some reason".

[robertlagrant]

> In this case, "not able to connect to AD for some reason".

Okay, but in that case, keeping the old cached passwords seems reasonable so you can log in and fix it. How do you avoid that?

[zamadatix]

I'm not necessarily arguing it should be one way or another, just clarifying what photon_rancher was saying about the offline behavior extending past just RDP login.

As for the article's stance: keep in mind RDP to any user account isn't necessarily automatically required to fix it. In general even, it's a tradeoff one makes when deciding between fail open and secure. There likely isn't a "right" and "wrong" answer here, neither approach is going to make everyone happy. Unsurprisingly, the security researcher is unhappy the needle doesn't lean more in the direction of security.