[English]Die Tage wurde bekannt, dass Remote Desktop-Verbindungen (RDP-Zugänge) auch alte, widerrufene Passwörter aus dem Cache für Verbindungen verwenden können. Das wird von einigen Leuten als Sicherheitsrisiko betrachtet. Microsoft will aber nichts an dieser Situation ändern.
Ein Blog-Leser wies hier im Blog im Diskussionsbereich darauf hin (danke dafür), dass RDP lokal alte Passwörter verschlüsselt in einem Cache sich merkt. Dadurch können unter bestimmten Umständen RDP-Anmeldungen mit einem alten, nicht mehr aktuellen Passwort (weil diese in der Cloud geändert wurde) unter Windows erfolgen.
Der Blog-Leser hat im Diskussionsbereich diesen heise-Beitrag erwähnt. Ich hatte es auch auf diversen Webseiten, z.B. bei Golem gesehen. Dan Gookin hat es auf Arstechnica im Beitrag Windows RDP lets you log in using revoked passwords. Microsoft is OK with that als erster aufgegriffen.
Windows RDP-Verbindungen
In Windows ist das proprietäre Remote Desktop Protocol (RDP) implementiert, um RDP-Verbindungen zu unterstützen. Hat sich der Benutzer per Remote Desktop Protocol (RDP) auf einem Computer eingewählt, kann er den betreffenden Rechner remote steuern.
RDP-Verbindungen nutzen gecachte Anmeldedaten
Sicherheitsforscher Daniel Wade ist nun aufgefallen, dass das die RDP-Verbindungen die Zugangsdaten für Microsoft-Konten aus einen Cache nutzen. Das heißt, dass geänderte und dadurch als ungültig zurückgerufene Passwörter weiterhin gültig bleiben.
Das Szenario, sich mit einem widerrufenen Kennwort über RDP anzumelden, tritt bei Windows-Rechnern auf, die mit einem Microsoft- oder Azure-Konto angemeldet und so konfiguriert sind, dass der Remote-Desktop-Zugriff aktiviert ist. In diesem Fall können sich Benutzer über RDP mit einem dedizierten Kennwort anmelden, das anhand eines lokal gespeicherten Berechtigungsnachweises validiert wird. Alternativ können sich die Benutzer mit den Anmeldeinformationen für das Online-Konto anmelden, das für die Anmeldung auf dem Computer verwendet wurde.
Microsoft will nichts ändern
Wade gibt an, dass durch diesen Mechanismus auch eine Anmeldung mit alten Passwörtern (sogar von neuen Rechnern) möglich ist und sieht dies als "Vertrauensbruch". Denn was tut man, wenn der Verdacht besteht, dass ein Konto Passwort kompromittiert sein könnte? Man ändert das Passwort, um den Zugang zu ändern, was durch das Caching aber nicht funktioniert – die alten Zugangsdaten funktionieren weiterhin.
Es sieht so aus, dass der Endnutzer das Problem nicht erkennen kann, es wurde von Microsoft auch nicht auf das Problem hingewiesen – erst nach dem Hinweis des Sicherheitsforschers hat Redmond hier einen Hinweis nachgetragen. Daniel Wade meldete das Verhalten Anfang April 2025 an das Microsoft Security Response Center.
Microsofts Rückmeldung war, dass es sich bei diesem Verhalten um eine Design-Entscheidung handelt. Diese soll sicherstellen, dass mindestens ein Benutzerkonto immer die Möglichkeit habe, sich anzumelden, und das unabhängig davon, wie lange ein System offline war. Für Microsoft entspricht das Verhalten nicht der Definition einer Sicherheitslücke. Das Unternehmen hat daher keine Pläne, das Verhalten zu ändern.
Microsoft teilte Wade mit, dass er nicht der Erste sei, der das "Problem" berichtete. Bereits 2023 habe ein Sicherheitsforscher auf den Sachverhalt hingewiesen. Die Aussage Microsofts war: "Ursprünglich haben wir eine Codeänderung für dieses Problem in Betracht gezogen, aber nach einer weiteren Überprüfung der Designdokumentation könnten Codeänderungen die Kompatibilität mit Funktionen, die von vielen Anwendungen genutzt werden, beeinträchtigen."
MVP: 2013 – 2016
"Das Szenario, sich mit einem widerrufenen Kennwort über RDP anzumelden, tritt bei Windows-Rechnern auf, die mit einem Microsoft- oder Azure-Konto angemeldet und so konfiguriert sind, dass der Remote-Desktop-Zugriff aktiviert ist. "
Ich nutze RDP nur im LAN mit lokalen Konten, aber das macht mich nun doch neugierig und ich muss morgen mal probieren, was hier bei einer Kennwortänderung passiert.
Ggf. muss man herausfinden, wie der Cache gelöscht werden kann.
Update: war neugierig und habe es gleich noch probiert. Hier (LAN mit lokalen Konten) wird offenbar nichts gecachet, muss das neue Kennwort verwenden.
Dass Windows als Client für RDP-Sessions zu Terminalservern denkbar ungeeignet ist habe ich bereits vor Jahren berichtet. Nicht nur Passwörter sondern auch Bildschirminhalte werden Recall-like by design gecached wenn man nicht aufpasst. Ist ebenfalls by Design so:
https://blog.jakobs.systems/micro/20220819-rdp-cache-reste/
Liegt vielleicht daran, dass es schon spät (oder früh) ist aber: Hä?
Ich habe jetzt die News mehrmals hier, bei Heise und Golem und Arstechnika lesen müssen, wobei überall etwas leicht anderes steht (und möglicherweise sogar Infos zu fehlen scheinen!?) und vielleicht bin ich auch einfach zu doof… (Ich dachte Anfangs erst, dass es um die Speicherung von Serverzugangsdaten auf dem lokalen Client-Rechner geht, was m.E. zumindest in Firmenumgebungen auch problematisch ist)
Folgender Zustand (habe ich verstanden):
1. Wir haben $(RDP-)Server
2. $(RDP-)Server wird verwaltet von $CloudDienst (Zugangsdaten, Passwort usw.)
3. Wir ändern bei $CloudDienst das Passwort von $(RDP-)Server (-Benutzer)
4. $(RDP-)Server kann (bei der nächsten Anmeldung) $CloudDienst nicht erreichen
Wie soll $(RDP-)Server denn was von der Passwortänderung mitbekommen? (Golem schreibt auch: "…, so dass Anwender sich auch dann weiterhin anmelden können, wenn das Zielsystem später nicht mehr mit dem Internet verbunden ist.)
Das ist auch nicht abhängig von einem Microsoft- oder Azure-Konto sondern betrifft jeden zentralen Dienst z.B. auch normale "Active Directory" Accounts und hat auch nur indirekt mit RDP zu tun!
Der einzige Unterschied ist, dass (einer) der (Cloud-)Account(s) wohl niemals abläuft um den Zugriff nicht komplett zu verlieren während bespielsweise AD Accounts im Cache durch die eingestellte Gültigkeit beschränkt sind, die aber auch erstmal ablaufen müsste um Angreifern den Zugriff zu verwehren, wenn die zentrale Verwaltung eben nicht erreichbar wäre. (Ist das für nicht Public-Cloudserver tatsächlich relevant? Geht es vieleicht nur um solche Server? In Firmenumgebungen und/mit standard ADs hat man dann afaik halt Pech, wenn der Server offline ist und die Daten abgelaufen sind)
Außerdem einfach mal folgendes vorstellen:
Man will im Homeoffice arbeiten und der Windows-, Mac-, Linux-, Wasauchimmer-PC versucht die Anmeldedaten mit $ZentralemDienst abzugleichen bevor man sich überhaupt am Rechner anmelden und mit dem Firmen-VPN verbinden kann… Super Idee und viel Spaß damit!
Ich finde auch den Ausdruck, dass das Passwort widerrufen wurde seltsam, denn es wurde schlicht geändert (gut Englisch, Sicherheitsforscher vielleicht reden die so…)
Oder, dass der Zugriff sogar von (heise schreibt auf…) neuen Rechnern funktioniere: Ja, wenn ich das Passwort von einem Server habe, kann ich auch von einem neuen Rechner darauf zugreifen und sogar von meinem Smartphone oder Tablet – komische Aussage…
Eine Lösung soll (laut Arsrechnika/Dormann, 2. Sicherheitsforscher) sein, RDP so zu konfigurieren, dass ausschließlich gegen lokal gespeicherte Daten authentifizert wird – ich dachte, lokal gespeicherte Zugangsdaten wären genau das Problem…
Der schreibt zusätzlich auch "It doesn't make sense from a security perspective," he wrote in an online interview. "If I'm a sysadmin, I'd expect that the moment I change the password of an account, then that account's old credentials cannot be used anywhere. But this is not the case."
Also wenn ich Sysadmin wäre, würde ich eben nicht erwarten, dass jedes zentral verwaltetet (Offline) Gerät die Änderung mitbekommt… (wie auch…)
Noch seltsamer wird es wenn man die Aussage mit einbezieht, dass selbst mehrere alte Passwörter gleichzeitig funktionieren sollen, also ein Account mit mehreren Passwörtern gespeichert sein soll…
Im Heiseforum hat auch jemand sowas ähnliches wie ich oben geschrieben, was aber, allerdings nur mit Vermutungen, wiederlegt wurde. Scheint also keiner was genaues zu wissen… außer, dass Microsoft wie immer schuld ist!
Golemforum geht von "Alles (News/Quelle) ist Bullshit" über "Sicherheitsforscher hat keine Ahnung von MS-Kram" und "Ja, wie soll das auch sonst funktionieren (s.o.)" bis zu "Unwahrscheinlicher Fall, weil ausschließlich Privater Account mit Microsoft Cloud Konto für RDP-Server" also weitestgehend irrelevant.
Der (zusätzliche) Text von Microsoft scheint sowieso etwas missverständlich zu sein:
"Caution
When a user performs a local logon, their credentials are verified locally against a cached copy before being authenticated with an identity provider over the network. If the cache verification is successful, the user gains access to the desktop even if the device is offline. However, if the user changes their password in the cloud, the cached verifier is not updated, which means that they can still access their local machine using their old password."
Ein Missverständnis könnte daher kommen, dass "local" wohl nicht als Gegensatz von "local" und "remote" sondern als Gegensatz von "local inklusive remote" und "cloud" verwendet wird, denn bei "remote" im Sinne von RDP passiert bei zentral verwalteten Accounts ja dasselbe wie bei "local", dann hätte man:
Neues Passwort
local inkl. remote -> cached copy -> identity provider erreichbar -> Zugriff
Altes Passwort
local inkl. remote -> cached copy -> identity provider nicht erreichbar -> Zugriff
Altes Passwort
local inkl. remote -> cached copy -> identity provider erreichbar -> kein Zugriff
Den dritten Satz könnte man zwar so verstehen, dass der Zugriff noch mit dem alten PW funktionieren würde, wenn man es in der Cloud (für den "local logon") geändert hätte und der Identity Provider erreichbar wäre, was aber dann dem ersten Satz wiedersprechen würde und den extra Offline Hinweis im Satz davor auch irgendwie überflüssig machen würde; aber wieder dem AD-Verhalten entsprechen würde. (Ist vielleicht etwas konstruiert oder hat möglicherweise sogar überhaupt nichts mit dem "Problem" zu tun oder wurde von einer eher technikfremden Person verfasst…)
Heise schreibt, dass die Daten nur beim ersten Mal online geprüft werden würden und ab dann nurnoch gegen die Lokalen, ohne weitere Onlineprüfung [daraus schließe ich: selbst wenn diese möglich wäre] (Golem schreibt so ähnlich).
Wenn das das Problem wäre, dann wäre das tatsächlich ziemlich dumm, was aber wiederum nicht klar aus dem Microsoft Text hervorgeht und ehrlich gesagt auch etwas unwahrscheinlich klingt.
Mögliche Lösungen:
1. Wenn man das Passwort von/in seinem Cloud-Mist ändert geht eine fette rote Meldung auf mit dem Inhalt: Hey, du hast 20 Server, die du über diesen Account verknüpft hast und bei denen du dich einmal mit den neuen Daten anmelden musst, damit die das entsprechende neue Passwort mitbekommen.
Was aber bei Offline Servern nicht funktionert und bei Online Servern egal ist…
2. Wenn man sich auf Cloud-verwaltete Server aufschaltet eine fette rote Meldung mit dem Inhalt: Hey pass mal auf du Penner! Weil du unseren Käse benutzt, dich aber wahrscheinlich nicht, so wie du es eigentlich solltest, vollständig mit den technischen Gegebenheiten auseinandergesetzt hast, sei dir gesagt, dass eine Änderung deines Microsoft/Azure whatever Drecksaccountspassworts nicht automatisch auf "Diesen Server" übertragen wird, sondern eine, nach der Änderung vollzogene Anmeldung mit den neuen Daten unter Erreichbarkeit des Microsoft/Azure whatever Drecksaccountspasswortsclouddienst nötig macht!
3. Microsoft ändert die Logik und alle Server gleichen sich regelmäßig mit $CloudDienst ab, was aber auch wieder eine entsprechende Erreichbarkeit voraussetzt…
Das alles funktionert aber nur, wenn tatsächlich ein weiterer Abgleich der Daten nach der ersten Anmeldung passieren würde. Ansonsten müsste man die Meldungen teilweise mit "Du musst die Daten auf allen Servern erstmal manuell löschen" ergänzen bzw. ändern.
Andere Möglichkeiten wären ein Abgleich der Zugangsdaten und dem lokalem Clientzertifikat, was sich aber regelmäßig ändert. Multifaktor Authentifizierung, die ja angeblich wegen des Problems umgangen werden kann was dann die Frage aufwirft, warum das überhaupt aktivierbar sein soll oder passwortloser Anmeldung, die aus demselben Grund wieder sinnlos wäre, weil ja der erste Zugriff mit dem ersten Passwort angeblich dauerhaft gültig sein soll.
Wo ist mein Denkfehler? Habe ich etwas überlesen oder falsch verstanden? Oder sind die News tatsächlich alle un-/missverständlich oder die Infos mangelhaft?
Keine Sorge, das geht nicht nur dir so. Ich denke der letzte Satz deines Beitrags fasst die Situation am Besten zusammen.
Und danke für deine ausführliche Aufarbeitung.
TLDR
Bei Erstanmeldung mit einem Microsoft-Konto wird online einmalig ein Anmeldetoken generiert, der dann valide bleibt selbst wenn zwischenzeitlich das Passwort und/oder sogar die Authentifizierungsart z.B. "passwordless" geändert wurde. Sowas nennt man Backdoor.
Die Alternative wäre für viele also dass bei einem Kennwort Ablauf kein Wechsel auf ein neues Kennwort möglich ist, weil die Anmeldung mit dem alten Kennwort nicht mehr funktioniert.
Falsch! Die einzige Alternative lautet:
Die Authentification niemals aus der Hand zu geben!
Wer das macht, ist lost… alle Schutzziele sind verloren.
Wo dein Denkfehler ist? Ich habe es auch erst nach mehrmaligen Lesen erkannt:
Es geht im Artikel nicht um RDP auf einen Server, sondern auf den Client.
Klassischer Fall: Notebook wird auf Dienstreise, im Urlaub, etc. verwendet. Währenddessen läuft das Domänen/EntraID-Kennwort ab und wird online geändert. Auf dem Notebook gilt weiterhin das alte Kennwort aus dem Cache, und zwar so lange, bis wieder eine Verbindung zur Domäne besteht und dort eine Anmeldung mit dem neuen Kennwort erfolgte.
Ist bekanntermaßen ein beabsichtigtes Vorgehen. Das Problem an der Sache besteht nun, wenn RDP auf das (in diesem Beispiel) Notebook möglich ist, dann erfolgt der Zugriff auch mittels dem "veralteten" Kennwort.
Aber wenn RDP funktioniert ist das Gerät nicht mehr offline…
Aus der Sicht einer lokalen Windows-Domäne durchaus, wenn kein VPN verwendet wird, bei dem der Verbindungsaufbau vor der Anmeldung möglich ist, oder wenn ein Notebook nur im Ruhezustand war und nicht neu gestartet wurde, oder, oder…
"tritt bei Windows-Rechnern auf, die mit einem Microsoft- oder Azure-Konto angemeldet" ließt sich so als seien On-Premise Domains nicht davon betroffen.
Das Problem ist laut Artikel aber das gleiche, wenn das Kennwort online geändert wurde und die lokale Anmeldung mit dem alten Kennwort fortbesteht:
"Alternativ können sich die Benutzer mit den Anmeldeinformationen für das Online-Konto anmelden, das für die Anmeldung auf dem Computer verwendet wurde."
Es ist egal ob das RDP-Ziel ein Client oder Server ist.
Technisch gesehen ist das natürlich korrekt. Die Szenarien, wo Endbenutzer sich per RDP auf Server verbinden, wo noch eine Sitzung mit dem alten Kennwort vorhanden ist, sind (hoffentlich) eher selten. Und bei Admins, die sowas regelmäßig machen, ist eh Hopfen und Malz verloren…
Es geht darum welcher Account am Ziel verwendet wird zum authentifizieren. Azure Account oder Microsoft Account – du hast die Arschkarte.
OnPrem AD oder lokaler Account es wird alles passen.
Besteht das Probkem auch wenn man nach der Passwortänderung auch die Session im Entra revoked? (Was man generell tun sollte)
"Heise schreibt, dass die Daten nur beim ersten Mal online geprüft werden würden und ab dann nurnoch gegen die Lokalen, ohne weitere Onlineprüfung [daraus schließe ich: selbst wenn diese möglich wäre] (Golem schreibt so ähnlich).
Wenn das das Problem wäre, dann wäre das tatsächlich ziemlich dumm, was aber wiederum nicht klar aus dem Microsoft Text hervorgeht und ehrlich gesagt auch etwas unwahrscheinlich klingt."
Sehr gut gedacht. Das zeigt, dass der ganze Sachverhalt Bullshit ist, wie es auch 1ST1 drüben bei Golem und Winfuture schrieb.
Man denke nur an die ganzen Active-Directory-Audit-Tools, die aus dem Eventlog der Domaincontroller jede einzelne Benutzeranmeldung an irgend einem AD-Member System heraus lesen. Das würde nicht funktionieren, wenn die Clients Anmeldungen nicht beim DC verifizieren würden und nur aus dem lokalen Cache authentifizieren würden.
Und noch eine Erfahrung, die jeder Admin kennt: Benutzer hat mehrere Remotesessions auf verschiedene Windows-Systeme offen. Derweil läuft sein Passwort ab und er ändert es an einer Station bei Anmeldung. Ab dem Moment passiert es, dass sein Konto durch andere offene Sitzungen, wo noch der alte Passworthash als Token hinterlegt ist, laufend gesperrt wird. Das kommt daher, dass bei sämtlichen Prozess-Starts usw. in diesen Sessions ständig dieser alte Hash bzw,. das damit generierte Ticket (TGT) zur Authentifizierung bei Programmstarts usw. weiter verwendet wird. Der Authentifizierungsdienst hat aber währenddessen schon vom DC den geänderten PW-Hash bekommen und das passt nicht mehr. Nach mehreren solchen Fehlern kommt es dann zum Account-Lockout. Das zeigt, dass Passwörter ständig vom DC zu den Members syncronmisiert werden.
Die parallele Existenz und Funktionsfähigkeit zweier oder mehrerer Passwörter zum gleichen Account kann nur funktionieren, wenn vor dem Passwortwechsel auf der zentralen Instanz das jeweilige Geräte keinen Kontakt mit dem AD oder Azure aufnehmen kann.
Und das selbe Problem sollte auch Linux haben, sofern es die Anmeldeaccounts von einem zentralen Verzeichnisdienst wie AD oder Kerberos holt.
> bespielsweise AD Accounts im Cache durch die eingestellte Gültigkeit beschränkt sind
nur zur Klarstellung deiner Formulierung:
der Counter der Cached Credentials definiert die mögliche Anzahl der zu speichernden Benutzername/Kennwort Kombinationen, aber keinesfalls(!) die Anzahl möglicher offline Anmeldungen eines Benutzers
RDP = Really Dangerous Practice
MS empfiehlt z.B. für seine Azure-VMs mit Windows selbst den RDP Port zum WAN nur zu Testzwecken offen zu halten, das sagt doch schon alles.
RDP hat man nie zum WAN offen.
Besteht das Probkem auch wenn man nach der Passwortänderung auch die Session im Entra revoked? (Was man generell tun sollte)
Mir geht es wie TAFKAegal und ich habe gehofft, dass wenigstens der Born den Fehler in der ganzen Geschichte erkennt und dazu keinen Artikel bringt, oder wenigstens eine Korrektur. Aber nein, fail.
Verdächtig wie so oft ist es immer… wenn jemand über etwas berichtet, die eigentliche Analyse aber nirgendwo Verfügbar ist.
Damit bleibt.. irgendwer hat sich über irgendwas gewundert und MS hat gesagt das ist korrekt so.
dafür haben wir ja dich ;)
Das ist korrekt haben wir auch so, über cached credential kann sich der Benutzer lokale anmelden, auch wenn das Kennwort im ad geändert wurde. man kann den Client nach der ad Verbindung mit lock und entsperren zum sync des neuen Passwort zwingen. ob die GPO Einstellungen wie hoch die Anzahl der Anmeldung im Cache liegen, zu dem Thema passt weiß ich nicht. wir haben das auf 1 Anmeldung gesetzt. das aber ein bekanntes Verhalten. ob das das selbe ist wie aus dem Bericht ergibt sich mir jetzt nicht beim lesen.
Wenn du es ganz verhindern willst, musst du die Benutzer in die AD-Gruppe "Protected Users" rein stecken, das funktioniert nämlich tatsächlich sehr gut. Ich verspreche dir, deine Benutzer werden es dir danken. In der Kantine sitzt du dann ganz alleine, weil du keine Freunde mehr hast.
Die funktionierende Lösung lautet, inkl. Freunde in der Kantine:
Interaktive Anmeldung: Anzahl der vorherigen Anmeldungen, die zwischengespeichert werden (falls der Domänencontroller nicht verfügbar ist) = 0
Dann muss man sich immer online gegen einen DC authentifizieren, da die Credentials nicht hinterlegt werden.
Einer der Gründe, warum man ein Computer basiertes VPN haben sollte: Damit sowas möglich ist. Im BSI SiM zum Einsatz von Windows 10 bei der Bnudespolizei war es Teil des Konzepts.
Es ist mir nur nicht klar ob genau diese Einstellung wenn man die nicht anpasst genau das ist worum es im dem Artikel geht. Weil das ist ja bekannt, oder etwas anderes gemeint ist ? Angepasst auf OU und damit Device Type haben wir das schon länger.
Aus Neugier:
Ich betreue nur kleine Netzwerke ohne Domain-Controller. Sind diese Dienste wirklich so unzuverlässig, dass hier ein Großteil meint lieber auf DC-basierte Authentifizierungen zu verzichten?
Wenn ja: Warum nutzt man so etwas, wenn es nicht zuverlässig ist?
Heisst im Klartext Microsoft Accounts sind scheisse, weil die syncen einen Passwort Change nie korrekt.