RDP geeft foutmelding "Er is een verificatiefout opgetreden"

[Freekers]

Ik probeer te RDP'en naar een van mijn servers waarop Netwerk Level Authentication staat ingeschakeld en NTLMv2 wordt afgedwongen. Dat ging prima, totdat de server ging rebooten voor updates. Sindsdien kom ik er met geen mogelijkheid meer in. Ik kreeg steeds deze foutmelding:



Na wat Googlen blijkt dit een hardnekkig probleem te zijn. Ik heb al verschillende dingen geprobeerd, zoals het toevoegen van deze waardes aan het register (http://funeasytech.com/rd...y-package-does-not-exist/) of het wijzigen van deze group policy (http://stackoverflow.com/...n-using-smtpclient-in-azu) maar beiden hebben het probleem niet opgelost.

De vertaling van deze error is overigens:
An authentication error has occurred
The function requested is not supported

Maar ook daar vind je vrijwel niets (bruikbaars) op...

De server draait Windows Server 2012 R2 Standard, mijn client Windows 10 Pro. NLA is ondersteund op de client, aldus het help/info schermpje van RDP.

Heeft iemand dit eerder meegemaakt ?

[medal]

Probeer is vanaf een ander systeem de verbinden naar de server ?
Indien dit wel werkt, even het wachtwoord resetten op de pc waarbij het niet werkt ( van het account waarmee je daarop ingelogd bent )

Klinkt als een vreemde oplossing maar het heeft bij ons op kantoor meerdere keren geholpen na updates bij klanten.

[DaVaRiOuS]

Dit is al een ouder topic, maar omschrijft exact mijn probleem die speelt sinds de updates van deze week die zijn doorgevoerd.

Op internet kan ik hier verder geen bruikbare info over vinden.

De computers die nog niet zijn ge-update en herstart, die kunnen nog wel inloggen. De computers die zijn ge-update kunnen niet meer inloggen.
De computers die nu nog wel kunnen inloggen, gaan we dus ook nog niet updaten en herstarten.

Die betreft een combinatie van Windows 7/8/10 computers waarbij dit issue speelt.
De server betreft een Windows server 2012 R2.

[ironleg]

Toevallig kwam ik hem bij een klant tegen deze week:
https://support.microsoft...e-2018-0886-march-13-2018
Oorzaak is inderdaad de mei update.

Als de cliënt hem wel heeft maar de server niet treed dit op.

In de link staat een lokale gpo welke het oplost

[MAX3400]

@DaVaRiOuS dan draai je je updates terug...???

@ironleg wat is een lokale gpo??

[maarud]

Beter de server updaten dan de policy toepassen, indien mogelijk. Beveiliging gaat voor

Of eenmalig om de server te updaten, en daarna weer de policy disablen.

[ironleg]

Ik bedoel computer policy. Met gpedit.msc

Maar inderdaad het beste is de server te updaten.

[Rolfie]

DaVaRiOuS schreef op zaterdag 12 mei 2018 @ 20:13:
Dit is al een ouder topic, maar omschrijft exact mijn probleem die speelt sinds de updates van deze week die zijn doorgevoerd.

Op internet kan ik hier verder geen bruikbare info over vinden.

De computers die nog niet zijn ge-update en herstart, die kunnen nog wel inloggen. De computers die zijn ge-update kunnen niet meer inloggen.
De computers die nu nog wel kunnen inloggen, gaan we dus ook nog niet updaten en herstarten.

Die betreft een combinatie van Windows 7/8/10 computers waarbij dit issue speelt.
De server betreft een Windows server 2012 R2.

Heb je exact de zelfde melding, of een andere? Want zoals in dit topic momenteel ook aangegeven is, is er een update geweest, maar dat is een andere melding als het goed is? (Indien je machine W10 is).

[DJSnels]

Dit komt vanwege de bug in CredSSP welke gepatcht is. Jouw client valideerde of de server de beveiligingspatch al doorgevoerd heeft (onderdeel van de monthly rollup van mei) en zo niet, dan verbind je client niet.

Het beste is om je server gewoon te updaten via de console of een client die de patch nog niet heeft, dat lost je probleem op.

Je kunt inderdaad ook een policy (of registry key) aanpassen om toch te verbinden als je anders compleet locked-out bent. Ik heb de betreffende policy niet bij de hand, maar een Google op CredSSP gaat je er zeker brengen!

[Verwijderd]

Dit kwam ik helaas ook tegen op het werk.

Hierbij de regfile waarmee je het probleem tijdelijk op client niveau oplost, totdat je de servers geupdate hebt.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters]
"AllowEncryptionOracle"=dword:00000002


Verbaast me enorm dat ik dit gemist heb en de klanten hebben er natuurlijk last van gehad

[True]

Wat leesvoer voor de liefhebbers: https://www.reddit.com/r/...here_upset_about_the_rdp/
Zie ook: https://www.reddit.com/r/...desktop_connections_over/
Het is dus al een tijd aangekondigd door Microsoft en was ook beheersbaar geweest indien je nog niet wilde updaten (WSUS bijvoorbeeld d.m.v. whitelisting) niet dat je daar nu wat aan hebt natuurlijk.

[Thijs B]

misschien domme vraag, even niet nu de tijd alles door te lezen maar is dit een eenmalig issue of gaan we dit nu elke maand krijgen wanneer je client updates of server updates achterlopen ?

[Dennism]

Thijs B schreef op maandag 14 mei 2018 @ 11:43:
misschien domme vraag, even niet nu de tijd alles door te lezen maar is dit een eenmalig issue of gaan we dit nu elke maand krijgen wanneer je client updates of server updates achterlopen ?

In principe eenmalig**, tenzij je de boel niet op orde brengt (Het s eigenlijk zelfs niet eens een issue, iedere sys admin heeft 2 maand de tijd had om zich hier op voor te bereiden en deze change zonder enige impact te laten verlopen).

** Tenzij er uiteraard andere lekken gevonden worden waarvoor een change als deze nodig is.

[maarud]

Rolfie schreef op zondag 13 mei 2018 @ 12:47:
[...]


Heb je exact de zelfde melding, of een andere? Want zoals in dit topic momenteel ook aangegeven is, is er een update geweest, maar dat is een andere melding als het goed is? (Indien je machine W10 is).

De update van maart of mei had ook een update van de foutmelding (dan zegt hij specifiek dat het aan de CredSSP versleuteling ligt). Als je die update op de client nog niet hebt, dan kan het best zijn dat de foutmelding algemener van aard is, en dan dus dezelfde als boven is.

[ElCondor]

Vreemd genoeg kwam de patch voor de 2008 servers bij mij niet met de automatische updates mee. Ik gebruik thuis geen WSUS, dus laat de servers online zoeken naar updates.
Uiteindelijk het bijbehorende KB artikel gevonden en de update handmatig op alle servers geïnstalleerd (die nog draaiden op 2008 R2).

[Tadream]

Bij de updates van maart (of was het april) had ik geen issues met de connecties van clients naar (RDS) servers. Met die van mei wel. Ben ik blij dat ik WSUS heb draaien en juist dit geval apart heb getest en het gelukkig dus op 1 client had en niet 500.
Servers bijgewerkt, daarna pas de clients en we kunnen weer verder.
Je kan er gewoon niet vanuit gaan dat je maar klakkeloos alle updates vrijgeeft, elke maand alles goed doornemen en testen op testomgeving. Ik hou van een telefoon die niet al teveel overgaat (vanwege dit soort dingen).

[Jazzy]

DaVaRiOuS schreef op zaterdag 12 mei 2018 @ 20:13:
Dit is al een ouder topic, maar omschrijft exact mijn probleem die speelt sinds de updates van deze week die zijn doorgevoerd.

Je hebt een drie jaar oud topic gekicked en schrijft dat het exact jouw probleem is, maar aangezien het met een update te maken heeft betwijfel ik dat. Om eventuele verwarring te voorkomen moet je misschien nog even bevestigen of je de foutmelding uit de startpost ziet of dat je een iets andere foutmelding krijgt waar het woord Oracle in voorkomt.

[Dennism]

Tadream schreef op dinsdag 15 mei 2018 @ 00:08:
Bij de updates van maart (of was het april) had ik geen issues met de connecties van clients naar (RDS) servers. Met die van mei wel.

Dat kan inderdaad kloppen, het KB artikel behorende bij de update van maart gaf aan dat de fix in de update van maart zat, maar dat bij de update ronde van mei deze fix breder geactiveerd zal worden. Hierdoor had iedereen van maart tot mei de tijd om of wel zijn / haar omgeving(en) zo in te richten dat dit geen invloed zou hebben, dan wel om GPO's uit te rollen om daarmee zelf de activatie van de fix te regelen.

[Aapmansz]

Dank voor de registry oplossing, na de mei update was de server ook weer beschikbaar vanaf andere werkstations.