Submitted 11 months ago by AngelikaMerkel@feddit.org to technology@lemmy.world
the real reason?
Yeah… Bill Hinks used to be the guy that did that but the execs fired him and replaced him with AI. Now when we ask the AI to fix it, it just removes the password requirement entirely and lets anyone login as admin with the username “fuckyou”. I wish Bill was around but he won’t answer our calls and any emails we send him just get an auto-reply of “fuck you”.
Microsoft always makes bad decisions about things and this stuff is nothing new at all
Linux: You’re using passwords? As your only authentication method? Eww! Whyyyyy???
Tbf rdp supports pki
Just speaking for the windows team at my own company, they’re arguably less modernized that are mainframe team.
Their stated reasoning here sounds bullshit and I’m sure the actual reason is a technical one, where they’re trying to retrofit the MS accounts login system to a protocol that wasn’t designed for it and for some reason are refusing to extend the RDP protocol to support the new auth mechanism. SMB network shares probably have the same issue I’d assume.
I’m sure AD domains don’t have this problem since it uses Kerberos, otherwise this would have been a problem already decades ago.
Using the password for a public account for local login is a disaster anyway, they should have done it like Apple and kept the local login password separate from the MS account login. I have never used a MS account for local login but it sounds to me like it just leads to people using insecure passwords for publicly reachable accounts because they don’t want to type a long password every time logging into their computer.
I have never used a MS account for local login but it sounds to me like it just leads to people using insecure passwords for publicly reachable accounts because they don’t want to type a long password every time logging into their computer.
I guess that’s what the PIN feature is for, even though you’re Personal Identification Number can have letters…
Oh, so that’s what that’s for. I’ve seen it before but never got the reason for it, but combined with this it makes sense. The name is very unfortunate though.
Now, the question is, will the cached RDP password update when you log in with the PIN :)
So if I understand that correctly that cache is never updated again after it is initially created? Wouldn’t that lead to a lot of issues when the online account has its password changed in terms of the new password not working too? Something seems to be missing from this article.
That is addressed in the article
Even after users change their account password, however, it remains valid for RDP logins indefinitely. In some cases, [independent security researcher Daniel] Wade reported, multiple older passwords will work while newer ones won’t.
I’m not exactly calling bullshit, but I’ve worked almost the entire last decade in IT in a Windows environment that has a decent amount of RDP use and has grown from ~2000-4000 employees during that time.
We’ve never encountered this as described.
From what I can tell, this “exploit” is just the standard NT password caching functionality that Windows has had for literal decades. Windows caches the last valid password used to log in, so if you lose your connection to your identity provider (AD or Entra) you can still log in with the last password confirmed to be valid.
In AD environments, this is what allows you to log into your laptop at home before you connect to VPN. You can’t hit your work AD before you’re on the work network. It also causes some fun because if you changed your password at work but didn’t lock and unlock your computer with the new one, it might still have your old one cached for the login screen but need the new one for VPN. This was a fairly common support call (I’m out of direct user support now so I can’t easily see if it still is).
Any situation where an old password would be valid indefinitely and a new one not recognized would require the machine to not be able to reach AD or Entra, but also to still be reachable by RDP… indefinitely. That’s definitely not impossible, but it’s one hell of an edge case to use the term “indefinitely” for.
It’s annoying that there aren’t separate settings from “local logins with AD as the IDP” and “remote logins with RDP”, but this feature is pretty damn critical for remote workers to be able to function and it is an intentional design choice as Microsoft states. Any potential workaround for a theoretical lack of this functionality is worse than the current state.
There’s no nefariousness here or lack of due dilligence. Labeling it as some horribly dangerous security hole with the amount of vagueness this article has is just misleading and clickbaity.
“We originally looked at a code change for this issue, but after further review of design documentation, changes to code could break compatibility with functionality used by many applications.”
Year of the Linux (Server|Desktop). Seriously. If you are in IT pls look into this (and hide your RDP server behind some VPN. No not MS RDP Gateway.)
Yeah, but “some cases” is extremely vague. If it is indeed cached indefinitely under all circumstances I would expect changed passwords to never work at all.
fatalicus@lemmy.world 11 months ago
This case is just fantastic. Someone discovered Cached domain logins, something that has been around for years and years to solve an issue when networks were less stable and AD might not be available, and decided to make a stink about it, as if sysadmins aren’t already aware of it and know how to handle things like this.