Windows RDP accepteert oude wachtwoorden, Microsoft vindt dat geen lek

Microsoft Windows Remote Desktop Protocol accepteert oude, veranderde wachtwoorden van gebruikers. Het bedrijf vindt dat geen lek, omdat het inloggen mogelijk maakt als een machine lang niet is gebruikt en niet online kan gaan.

Microsoft heeft wel de pagina over inloggen met RDP een update gegeven. "Wanneer een gebruiker lokaal inlogt, worden zijn referenties lokaal geverifieerd aan de hand van een kopie in de cache, voordat ze via het netwerk worden geverifieerd bij een identity provider. Als de cacheverificatie succesvol is, krijgt de gebruiker toegang tot de desktop, zelfs als het apparaat offline is. Als de gebruiker echter zijn wachtwoord in de cloud wijzigt, wordt de verificatie in de cache niet bijgewerkt, wat betekent dat hij nog steeds toegang heeft tot zijn lokale computer met zijn oude wachtwoord."

Dat kan een probleem zijn als bij een datalek wachtwoorden openbaar online verschijnen. Kwaadwillenden kunnen zich dan op afstand toegang verschaffen tot machines, zelfs als gebruikers het wachtwoord hebben veranderd. Microsoft weet dit al sinds augustus 2023, maar heeft besloten er niets aan te doen. "Het is een ontwerpbeslissing om ervoor te zorgen dat ten minste één gebruikersaccount altijd kan inloggen, ongeacht hoe lang een systeem offline is geweest", meldt Ars Technica. RDP is een manier om op afstand in te loggen op machines en is veel in gebruik in zakelijke omgevingen. De functie heet in het Nederlands Extern Bureaublad.

Windows RDP, Remote Desktop Protocol
Windows RDP, Remote Desktop Protocol

Door Arnoud Wokke

Redacteur Tweakers

01-05-2025 • 13:41

69

Reacties (69)

69
69
37
7
0
30
Wijzig sortering
Ik vind dit nogal wiedes om eerlijk te zijn. Als je user directory internet afhankelijk is, en je wilt dat gebruiken op een non-connected device, dan ligt het voor de hand dat dit met een lokale cache werkt.

Als je dit spint, dan kom je op titels als “RDP accepteert oude wachtwoorden!”.
Heel eerlijk snap ik de sensatie titel ook niet helemaal, cached credentials is ook een ding als je achter de machine zit en in sommige gevallen de enige manier om een gebruiker te redden op afstand.

Beetje beheerder weet natuurlijk dat dit bestaat, de titel doet het overkomen alsof er een mega issue is met rdp. Nog buiten het feit dat je rdp natuurlijk nooit van het internet af open zet richting welke cliënt dan ook.

Dus misbruik kan, als iemand toevallig in hetzelfde netwerk zit als de cached laptop/desktop en dan ook nog via een lek toevallig een wachtwoord heeft weten te vinden die toevallig dan ook nog net bij die laptop/desktop hoort en het wifi netwerk waar ze aanhangen niet de optie heeft aanstaan om verkeer tussen de wifi devices te blokkeren.

Een hoop nodig dus om dit uit te buiten, zodra je in je company netwerk zit al is het maar via vpn is dit binnen 2 minuten geen issue meer omdat je de meest recente AD credentials dan weet zal moeten gebruiken.

Ik zie dit net als Microsoft dan ook niet als een bug.
Ik zou dit kunnen accepteren als dit alleen van toepassing zou zijn als de machine geen netwerk heeft. Echter als de machine gewoon netwerk heeft, moet altijd tegen de DC gevalideerd worden. Nog beter zou zijn als deze optie via een group policy zou zijn in te stellen. Echter de standaard bij een DC connected client zou moeten zijn dat altijd validatie plaats vindt via DC server. Systeembeheerder zouden er dan voor kunnen kiezen om de cached validatie toe te staan als er geen verbinding met een DC gemaakt kan worden.

Wij zijn een paar jaar geleden al overgestapt naar RustDesk voor remote desktop en hebben Remote Assistance en Remote Desktop uitgeschakeld.
Blijkbaar is het probleem dat de cache niet bijgewerkt wordt zelfs als het systeem online is. Het probleem is dus dat de cache gebruikt wordt ongeacht of het systeem online is, zelfs als de cache al verlopen is houdt het systeem de cache bij “in geval dat” het systeem offline is.
Volgens mij kan de cache niet bijgewerkt worden als het systeem het nieuwe wachtwoord niet weet.
Tuurlijkwel. Alle systemen die aan dat account (bij live) of domein gekoppeld zijn worden bijgewerkt zodra de machine een netwerkverbinding heeft met Live of AD.

En het maakt niet uit waar het wachtwoord gewijzigd wordt. Of op de (bijvoorbeeld) laptop zonder netwerkverbinding. Waar er dan nog steeds met het oude wachtwoord in Live ingeloged kan worden vanaf een andere computer/smartphone.
He Tweakers nog een klik bericht over oud nieuws.
Tot de laptop verbinding maakt met Live. Of via een smartphone/pc in Live zoals in dit "nieuws" item.
Ik dacht dat het idee van AD was dat het wachtwoord nooit over het netwerk gaat. En dan kan je ook niet de cache bijwerken met het wachtwoord
Afhankelijk van wat je bedoelt met AD. AD is een combinatie van LDAP en Kerberos met een laagje MS-RPC.

AD kan Kerberos doen zodat het paswoord inderdaad niet over het netwerk moet. Het kan ook LDAP doen (zonder TLS standaard). Echter niet alle applicaties ondersteunen dit, vb. met RDP stuur je het wachtwoord naar de server die dan de user authenticeert. Die toelating en/of wachtwoord wordt dan 'ergens' in een cache opgeslaan.

Moest het allemaal Kerberos zijn hadden ze dit probleem niet: ticket expired => inloggen gedaan.
Nee, maar een sessie heeft wel een levenseinde. Met dit zeg je eigenlijk, zolang de gebruiker het systeem niet verbindt met het netwerk EN authenticeert, kunnen ze ALTIJD inloggen ongeacht hun huidige status of wachtwoord.

Dus vb. je verbindt als tech met RDP naar een laptop. Nu is jouw paswoord opgeslaan in die computer. Zolang jij niet meer inlogt kan iemand de laptop offline houden en altijd met jouw oud paswoord in de computer. Zelfs al verander je je wachtwoord, zolang jij geen gebruik maakt van de dienst terwijl het systeem online is blijft het oude wachtwoord in de cache geldig. 2 jaar later, 10 jaar later, zolang de laptop niet naar jouw AD verbindt en jij niet verbindt terwijl het systeem online is blijft jouw oud wachtwoord geldig.

[Reactie gewijzigd door Guru Evi op 1 mei 2025 19:12]

Mee eens. Caches hoeven geen actuele/live data te hebben. ‘Recent’ is vaak genoeg; zeker gezien het hier bewust zo is geimplementeerd.

Een kleine aanpassing laat de titel al minder sensationeel klinken:
“Windows RDP accepteert standaard oude wachtwoorden, Microsoft verduidelijkt documentatie
Begrijp ik het verkeerd? Non connected device kun je toch niet in rdp-en?
Inderdaad. Is dat niet wat sssd op linux moest doen destijds ?
Niet dat ik het ooit heb moeten gebruiken.
Goed dat hier bewustwording over gecreëerd wordt, maar dit is wat mij betreft een relatief logische designkeuze. Door middel van een GPO of regkey is dit wel aan te passen


Policy Path: Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options

Policy Name: Interactive logon: Number of previous logons to cache (in case domain controller is not available)

Setting: Set the value to 0.



Veel hardening/CIS policies raden ook aan de standaard waarde van 10 cached credentials naar 4 te zetten

[Reactie gewijzigd door LigeTRy op 1 mei 2025 13:52]

Klopt is volledig logisch. Bij ons intern is dit ook al jaren bekend.

De settings die je aangeeft werkt idd maar wellicht goed om op te merken dat hiermee devices niet offline gebruikt kunnen worden. Voer dit dus niet zomaar door.

Daarnaast is deze setting computer wide. Dus de default van 10 cached logon's kan dus ook 1 logon van 10 verschillende accounts zijn.
Dat is voor het aantal accounts dat het login scherm mag 'herinneren'. Als ik mij goed herinner, onthoudt dat ook hoe lang je paswoord geldig is in AD en eenmaal je paswoord verlopen is kun je nog steeds niet inloggen. Ook niet leuk voor mensen met een laptop om dit zomaar op 0 te zetten.

Blijkbaar is er een regel voor RDP die zegt dat het systeem altijd 1 in de cache moet laten ongeacht de instellingen, ongeacht of het account/paswoord/sessie verloopt of verandert. En volgens Microsoft moet dit want anders breekt er teveel oude meuk.

[Reactie gewijzigd door Guru Evi op 1 mei 2025 19:19]

De cruciale vraag is hoe lang die wachtwoorden nog vanuit de cache gebruikt worden.

Bij Exchange (online) merkten we in het verleden dat er ook een wachtwoord cache was in de communicatie met mobile devices. En bij iPhones was dat in mijn herinnering een aantal uren en bij Android kon het volgens mij zelfs een dag zijn.
Dat soort dingen zijn slecht gedocumenteerd.

[Reactie gewijzigd door mjtdevries op 1 mei 2025 13:48]

De cruciale vraag is hoe lang die wachtwoorden nog vanuit de cache gebruikt worden.
Oneindig tot deze wordt overschreven, er zit in principe geen time limit aan:
The cached account information does not expire, but can get overwritten, as previously described.
Zie https://learn.microsoft.c...ntroller-is-not-available
Jouw link -> het document geeft idd aan dat cached credentials oneindig blijven werken tot ze worden overschreven, en dat dit bedoeld is voor situaties waarin de domain controller niet beschikbaar is. Maar juist dat roept in mijn ogen de vraag op of dit ontwerp nog wel van deze tijd is. Het idee stamt duidelijk uit een periode waarin beschikbaarheid belangrijker werd gevonden dan security, maar met de huidige focus op zero trust en het beperken van aanvalsoppervlak vind ik dat je daar kritisch naar moet kijken. Als een wachtwoord is gewijzigd, zeker na bijvoorbeeld een datalek, zou je willen dat die wijziging zo snel mogelijk overal wordt afgedwongen - ook op apparaten die tijdelijk offline zijn. Het feit dat een gebruiker of aanvaller met het oude wachtwoord blijft inloggen totdat er een nieuwe cache ontstaat, is dan een zwakte. Ik vind dat Microsoft organisaties minimaal de mogelijkheid moet geven dit beleid zelf in te stellen of strenger te maken. Dat is wat mij betreft beter passend bij de huidige security-standaarden.

[Reactie gewijzigd door InsanelyHack op 1 mei 2025 14:23]

Dit gedrag van Windows kan aangepast worden vanuit AD. gpedit.
En die mogelijkheid zit er al heel erg lang in. Maar zal wel ingesteld moeten worden.
Nee, het gedrag kan niet aangepast worden. Dat is juist het probleem. Het design principle is dat er altijd 1 account moet zijn die het systeem kan ontsleutelen ONGEACHT of dit geldig is volgens de policies.
Prima, maar hadden we ook niet zoiets als "secure design"?
Stond Microsoft daar ook niet achter? Zou dat dan niet de standaard instelling moeten zijn?
Is er nou niemand bij Microsoft die heeft gedacht dat daar een tijdlimiet aan moet zitten?

Bij Exchange werd het gedaan om performance redenen. En dan hoeft het echt niet lang bewaard te worden.
Het probleem is dat je er dan helemaal niet meer inkomt. Dan krijgen ze daar weer klachten over.
In jouw voorstel zou dat betekenen dat een offsite medewerker die op z'n laptop werkt, of die een paar maanden op vakantie is, niet meer kan inloggen totdat 'ie weer op de zaak is.
Je gaat voorbij aan het belangrijkste punt. Het laat een logon toe terwijl het wachtwoord in de cloud al veranderd is.
Dat is wat anders dan iemand die na een vakantie inlogt met het wachtwoord dat ie altijd heeft gebruikt.
dat is niet anders dan wanneer het domain password gewijzigd wordt en dit nog niet is gerepliceerd naar de client.
Maar de replicatie tijd is geen maanden of jaren.
Nee dat is allebei om dezelfde reden, cached credentials. Want als het device geen internet heeft of de DC niet kan bereiken is het dan toch beschikbaar. Gelukkig kun je als beheerde perfect kiezen hoeveel er gecached moeten worden (inclusief 0). Denk daar overigens wel over na voordat je dat over je org uitstort... Je gaat wat telefoontjes krijgen.
De cruciale vraag is hoe lang die wachtwoorden nog vanuit de cache gebruikt worden.
Ik denk eerder dat de cruciale vraag is waarom we nog wachtwoorden gebruiken om in te loggen op RDP, Windows 365 of AVD. Gebruikers en beheerders hoeven echt geen wachtwoord meer te gebruiken.

Exchange Online heeft geen wachtwoordcache meer. Modern Auth heeft een einde gemaakt aan wachtwoorden. Opzich is Modern Auth best goed gedocumenteerd.
Hoe kan een apparaat offline zijn en toch bereikbaar zijn via rdp?
Ik gok erop dat ze bedoelen geen verbinding met de AD/Microsoft services maar wel toegankelijk op het lokale netwerk. Maar de netwerkspecialisten mogen toelichten of dat kan :D.
Ja hoor, op mijn werk had ik een netwerk met unix-machines die niet internet op mochten. Wel met elkaar verbonden. Daartussen zat ook een windows machine met rdp. Bestanden brieg ik op met sftp. (Dus stiekem zat een poort wel op internet)
Als het een domain joined machine is, kan hij zijn koppeling met het domain kwijtgeraakt zijn bijvoorbeeld, waardoor je alleen met een cached credential, of met een lokaal account in kan loggen.

Dat cached credentials werkt namelijk breder dan alleen via RDP, ook lokaal worden credentials in een cache bewaard.
Klopt maar dit kan je wèl uitzetten in tegenstelling tot RDP klaarblijkelijk:
Standaard staat dit op 10 (Windows onthoudt de laatste 10 gebruikers).
Zet je dit op 0, dan worden er géén cached credentials opgeslagen, en móet een machine de DC bereiken om aan te melden. GPO-locatie: Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options → Interactive logon: Number of previous logons to cache
Of zou dit ook werken op een RDP host die je wil benaderen en zodanig dus ook dit probleem van cached wachtwoorden kunnen afdwingen? ... Nu ik dit zo zit te bedenken kan je het dus zo oplossen.

[Reactie gewijzigd door InsanelyHack op 1 mei 2025 14:32]

Dit is inderdaad de zelfde cachfile.OP 0 zetten en dit "probleem" is verholpen.

Het "probleem" dat wordt aangekaart bestaat al zeer lang. Geen idee waarom dit nu zo naar boven komt.
Offline is meer in de zin; geen contact met het AD / domaincontroller, maar wel op afstand benaderbaar.

[Reactie gewijzigd door Luchtbakker op 1 mei 2025 13:50]

Offline voor de IPD wil niet zeggen dat het apparaat offline is voor RDP.
offline als in "machine kan niet bij de identity provider."

maar ook als bv je nic er afvalt. Kan je er middels iDrac,iLO,vSphere etc nog bij.
Terechte vraag, mij klinkt het ook wat tegenstrijdig.

Ik denk doordat alle poorten dicht staan behalve die van het RDP protocol.
Misschien een suffe vraag, maar wat is daar dan het nut van dat hij alleen via rdp bereikbaar is en verder alles dicht staat?
De root van een PKI bijv.

Al wil je die liever helemaal 100% offline hebben. Zonder wat voor connectiviteit dan ook :X
Helemaal geen suffe vraag!

Ik kan me bepaalde usecases voorstellen.

Bijvoorbeeld waarbij je op een legacy systeem berekeningen wilt uitvoeren. Het systeem zelf is hardstikke onveilig om aan het internet te hangen, maar dat is geen probleem want hij berekent toch puur en alleen o.b.v. input die je zelf geeft tijdens de RDP sessie.

Of dat je wilt inloggen op een systeem van een stuk apparatuur in een ziekenhuis om analyse te kunnen doen bij bijvoorbeeld een storing. De apparatuur zelf werkt zonder internetverbinding, dus als je deze open laat verhoog je alleen maar de 'attack vector' voor hackers.
Denk dan aan een PC die in een DMZ of een VLAN zonder internettoegang is gezet. Deze kan benaderd worden via VPN bijvoorbeeld.
Lokaal, wellicht. Ik gebruik het ook zo, als iemand toegang heeft tot het netwerk kan je dit benutten. Niet elke RDP machine is uberhaut verbonden met het internet.
Wij hebben sporadisch wel eens dat 1 of meeredere servers AD en andere infrastructuur niet meer kunnen bereiken door een foutje in een firewall, maar dat we vanuit de client subnets die servers wel kunnen bereiken. Aanloggen kan dan wel nog via een cached credential.
Ik snap het artikel niet helemaal.
De eerste vraag is hoe lang de cache blijft. Normaliter is zoiets namelijk maximaal enkele uren tot een dag geldig, of zolang je sessie actief blijft ( en die wordt normaliter na disconnectie en een paar keer proberen afgesloten).

Ik zou mogen aannemen dat een nieuwe poging om de sessie naar remote te halen ook een verversing van het wachtwoord vereist.

Als je na een aantal uren nog steeds met een oud wachtwoord kan inloggen, lijkt dit me een mega issue. Het zorgt er namelijk voor dat het wijzigen van je wachtwoord niet helpt wanneer een kwaadwillige een connectie naar je machine heeft gemaakt.
Dit blijft volgens mij in de cache totdat je machine de domain controller weer heeft kunnen benaderen, of tegenwoordig entra id.

Als je namelijk in het weekend met je laptop thuis op de bank zit, of even in de trein, dan wil je wel kunnen inloggen op je laptop. Als hij je wachtwoord niet zou cachen dan zou je niet kunnen inloggen als je een vpn nodig hebt om je domain controller te bereiken of gewoon internet voor entra id.

Dit is een functie die al heel lang in Windows zit en maar goed ook.
Het maakt daarbij niet uit of je inlog via de console of rdp plaatsvind, het mechanisme is hetzelfde.

Of het een functie is die je ook op je servers actief wilt hebben is nog te betwijfelen, maar op de clients die niet altijd online zijn lijkt het me wel handig. Het is niet de meest veilige optie, maar wel de meest praktische denk ik.
De cache is op zich ook wel logisch, maar dat er standaard geen timeout of zit is raar.
Als de cache zou verlopen na like 24 of 48 uur zou het minder een probleem zijn.
Maar iemand die op vrijdag zijn laptop uitzet kan dan op maandag niet meer thuiswerken als zijn bedrijf nog via een AD werkt. Want dan ben je meer dan 48 uur later. Vaak moet je eerst inloggen op je laptop en de vpn starten voordat je laptop weer het AD kan zien en dat inloggen mag dan niet meer want je laptop heeft de cache verwijderd.

Hij zal dan eerst naar kantoor, of andere locatie met corp netwerk, moeten om een keer te syncen met het ad en dan moet hij als de laptop uitgaat weer binnen 48 uur een keer inloggen op de vpn om toegang te houden.
Laat het dan 72 uur zijn. Dat overbrugt dan net het weekend.
Wat als je verlof hebt en 3 weken op vakantie vertrekken?
Tjah dan kan je de eerste dag niet thuiswerken he als er geen local accounts zijn 8)7
Los van het feit dat het een security concern is (of kan zijn) zou ik dit ook niet als een "lek" bestempelen.
Op welk moment word een risico een lek?

Ze zouden toch wel iets moeten doen om het risico te mitigeren.
Dat uiteraard een beetje arbitrair maar een security lek of datalek treedt op wanneer beveiligde informatie onbedoeld of opzettelijk wordt vrijgegeven aan onbevoegde personen.

En dat is hier volgens mij niet aan de hand. Het is alleen een risico WANNEER bij een lek credentials zijn buit gemaakt.
Onbevoegde personen. Bv iemand die niet het juiste wachtwoord gebruikt, maar een oud verlopen wachtwoord.

Er zijn wat redenen te verzinnen bij een machine die al een tijd offline staat. Maar dan zou ik dat alleen voor lokale login acceptabel vinden en niet bij een logon via rdp.
Cached credentials is niet iets nieuws... en snap de redenering ook wel, al hebben we het hier wel over remote toegang, niet lokaal direct op de machine zelf.
Kwaadwillenden kunnen zich dan op afstand toegang verschaffen tot machines
RDP hoort niet direct vanaf internet toegankelijk te zijn. Dat is vragen om ellende, cached credentials of niet.

[Reactie gewijzigd door Miesepies op 1 mei 2025 13:49]

Is dit niet hetzelfde als een domain joined machine al een lange tijd niet online geweest is, dat je dan met een cached account (wat al eerder ingelogt geweest is) kan inloggen?
Ja dit is precies hetzelfde alleen dan over RDP. De titel had ook kunnen zijn "Windows accepteert oude wachtwoorden". Maar, een remote kwetsbaarheid is wel een graadje erger ingeschat dan een lokale dus dat is wel begrijpelijk.

[Reactie gewijzigd door Llopigat op 1 mei 2025 14:08]

Voor mensen die een alternatief zoeken: RustDesk is open-source en heeft een goed track record wat betreft privacy en veiligheid.
Hoewel ikzelf ook Rustdesk gebruik, is er geen structureel probleem met RDP, maar met het feit dat cached credentials blijven werken. Als je een Rustdesk server hebt ingericht die werkt, dan zul je ook wel een domain controller hebben die werkt voor deze use case.

Voor lokale accounts was dit sowieso niet relevant.
Maar ze kunnen toch juist NIET op afstand inloggen met dat alleen lokaal geauthoriseerde account?
Dit hangt er vanaf. Local admins zijn lid van de rdp groep. een standaard gebruiker niet.
Als de gebruiker een admin is, is deze dus ook direct lid van de rdp groep.
En kan dus lokaal inloggen met zijn gecached ww. Maar niet extern via rdp toch?
Dit WW zit niet een cache file. Dit is direct op de machine. Het oude en nieuwe wachtwoord zijn dus altijd gelijk. Maar rdp werkt wel met een lokaal account. IP of machinenaam/loginnaam + WW
Het gaat hier juist om ww in de cache!

Op dit item kan niet meer gereageerd worden.