And you are ok with it too. This is not a security issue in any way.
The root of the issue is when you log into a domain joined machine your login info is cached on the machine. If you change your password and that machine has not been able to task with the domain controller it will use the local cache to verify your account. This is how it was intended.
Once the machine reconnects to the domain controller the cached details are expired.
As far as I can tell, this applies after reconnecting to the domain controller and being able to pull new credentials. It’s not 100% clear in the article, but
Old credentials continue working for RDP—even from brand-new machines.
Even after users change their account password, however, it remains valid for RDP logins indefinitely. In some cases, Wade reported, multiple older passwords will work while newer ones won’t. The result: persistent RDP access that bypasses cloud verification, multifactor authentication, and Conditional Access policies.
While the password change prevents the adversary from logging in to the Microsoft or Azure account, the old password will give an adversary access to the user’s machine through RDP indefinitely.
However
The mechanism that makes all of this possible is credential caching on the hard drive of the local machine. The first time a user logs in using Microsoft or Azure account credentials, RDP will confirm the password’s validity online. Windows then stores the credential in a cryptographically secured format on the local machine. From then on, Windows will validate any password entered during an RDP login by comparing it against the locally stored credential, with no online lookup. With that, the revoked password will still give remote access through RDP.
Which makes it sound like it has to be logged in successfully first, directly contradicting the first quote.
Either way, it does appear to be an issue that an online device will accept expired passwords before it will pull new credentials from the inter/intranet
As someone who has come across this scenario a lot through the years I have not been able to use an older password once connected to our domain and have synced. The cached account is nice since if you lose domain trust, just shut off wifi or unplug ethernet and you can get back in which allows you to rejoin. Local account can as well, but getting that password through laps and typing in the ridiculously long password thats set is by far our last resort method.
Is this from the local connection or over RDP? The issue they’re trying to point out seems to be that while it’ll stop working for local sessions, RDP sessions will continue to accept the old password
I’ll have to try on Monday. Sounds like a good test for work hours haha.
Looking forward to the results!
