This functionality is critical for offline access; in fact in some scenarios you may not be able to configure WiFi (or VPN) for Domain Access without first logging in. If the offline password didn't exist the machine would be inoperable.
Let's also acknowledge the fact that even if they try to address this, unplugging the network cable or otherwise interfering with connectivity would always fall back to offline credentials. You cannot simply invalidate them for reasons previously stated.
So now we're at the point where the fix is at best unreliable, and NOT even a hard security boundary. Yet they could still try. For example either phoning the mothership (e.g. AD, Microsoft Login, et al) on a regular schedule for a logged-in user and verifying offline credentials OR phoning the mothership during successful cached login (with aggressive timeouts).
There is actually precedent for this: UAC. UAC is also not a real security boundary, and is also unreliable. It is a "best effort" improvement. This would be of that nature, engineering effort to kinda-sorta make it better than nothing but trivial for a trained attacker to bypass.
But ultimately, this isn't a bug, and any improvements Microsoft makes will be similarly criticized (due to the trivially of bypassing them).
photon_rancher · 28m ago
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.
kryogen1c · 2h ago
I'll take a look at this tomorrow, but it seems like a security researcher angling for a bug bounty.
Cached local credentials and saved rdp credentials have existed for a long time and both have gpo settings to modify/disable - you just don't do it because no caching requires some kind of sase/ always on vpn, etc. I think most systems have disallowed rdp credential saving for years.
Furthermore, how does one connect to the domain with an invalid password? I'm inclined to think this was tested on a workgroup and not a domain. If you go long enough your trust tombstones and you lose all access anyway, cached and saved or not.
Your RPD password is your AD password and that is encrypted and salted (I think). There are some worrying extensions to MSAD but I don't think that unless you tick the box in ADUC that your password will be stored unencrypted, it will be stored unencrypted (hashed or whatever).
We need to understand what:
"...Microsoft said the behavior is a “a design decision to ensure that at least one user account always has the ability to log in no matter how long a system has been offline."
really means.
I'm a Linux jockey but I can't be arsed with nonsense like this.
nine_k · 1h ago
> one user account always has the ability to log in no matter how long a system has been offline
To me, it's pretty clear.
Assume that every password has an expiration date. Having not logged in to the system long enough, you end up with a system where every password has expired. A relatively reasonable thing to do then is to accept some previously valid password, and direct the user to the password reset flow. Else you end up with a system that rejects every login.
A much more reasonable thing to do would be to accept rescue codes in this situation, of use 2FA so that passwords expiration is not needed. But I bet the security checklists used by some behemoth insurance companies predate these inventions, nobody wants to alter them, and companies who don't want to pay higher IT insurance premiums have to follow these outdated and inefficient practices.
politelemon · 2h ago
This isn't working for me on an enterprise domain, I'm simply refused access. TFA doesn't link to any instructions either.
cobbal · 2h ago
"The first time a user logs in using Microsoft or Azure account credentials"
Maybe it's related to using the online account for local logins
notnmeyer · 3h ago
That is… insane. In what world is this expected or acceptable behavior?
pixl97 · 2h ago
There are 2 hard things in computer science. Naming things, cache invalidation, and off by one errors.
'Some' of this makes sense but not all of it.
For example let's imagine a linux password system that let's you take a system offline and still use it. You have to cache the password locally and if it doesn't connect to the online system where the password has changed then the old password will still work.
With that said you should also design the system to invalidate the cached password from upstream when it gets a notification it changed.
- This is not a bug; it is a design decision.
- Microsoft could still try.
This functionality is critical for offline access; in fact in some scenarios you may not be able to configure WiFi (or VPN) for Domain Access without first logging in. If the offline password didn't exist the machine would be inoperable.
Let's also acknowledge the fact that even if they try to address this, unplugging the network cable or otherwise interfering with connectivity would always fall back to offline credentials. You cannot simply invalidate them for reasons previously stated.
So now we're at the point where the fix is at best unreliable, and NOT even a hard security boundary. Yet they could still try. For example either phoning the mothership (e.g. AD, Microsoft Login, et al) on a regular schedule for a logged-in user and verifying offline credentials OR phoning the mothership during successful cached login (with aggressive timeouts).
There is actually precedent for this: UAC. UAC is also not a real security boundary, and is also unreliable. It is a "best effort" improvement. This would be of that nature, engineering effort to kinda-sorta make it better than nothing but trivial for a trained attacker to bypass.
But ultimately, this isn't a bug, and any improvements Microsoft makes will be similarly criticized (due to the trivially of bypassing them).
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.
Cached local credentials and saved rdp credentials have existed for a long time and both have gpo settings to modify/disable - you just don't do it because no caching requires some kind of sase/ always on vpn, etc. I think most systems have disallowed rdp credential saving for years.
Furthermore, how does one connect to the domain with an invalid password? I'm inclined to think this was tested on a workgroup and not a domain. If you go long enough your trust tombstones and you lose all access anyway, cached and saved or not.
Your RPD password is your AD password and that is encrypted and salted (I think). There are some worrying extensions to MSAD but I don't think that unless you tick the box in ADUC that your password will be stored unencrypted, it will be stored unencrypted (hashed or whatever).
We need to understand what:
"...Microsoft said the behavior is a “a design decision to ensure that at least one user account always has the ability to log in no matter how long a system has been offline."
really means.
I'm a Linux jockey but I can't be arsed with nonsense like this.
To me, it's pretty clear.
Assume that every password has an expiration date. Having not logged in to the system long enough, you end up with a system where every password has expired. A relatively reasonable thing to do then is to accept some previously valid password, and direct the user to the password reset flow. Else you end up with a system that rejects every login.
A much more reasonable thing to do would be to accept rescue codes in this situation, of use 2FA so that passwords expiration is not needed. But I bet the security checklists used by some behemoth insurance companies predate these inventions, nobody wants to alter them, and companies who don't want to pay higher IT insurance premiums have to follow these outdated and inefficient practices.
Maybe it's related to using the online account for local logins
'Some' of this makes sense but not all of it.
For example let's imagine a linux password system that let's you take a system offline and still use it. You have to cache the password locally and if it doesn't connect to the online system where the password has changed then the old password will still work.
With that said you should also design the system to invalidate the cached password from upstream when it gets a notification it changed.