RDP-fout: verificatie op netwerkniveau mislukt

U typt gebruikersnaam en wachtwoord in Verbinding met extern bureaublad, klikt op Verbinden, en nog voordat er een aanmeldscherm verschijnt, komt er een foutmelding. Geen bureaublad, geen voortgangsbalk, niets. Precies dat is het kenmerk van een NLA-probleem: de verificatie op netwerkniveau loopt vóór het opzetten van de sessie. Mislukt die, dan krijgt u nooit een aanmeldvenster te zien waarin u nog iets zou kunnen corrigeren.

Dit artikel loopt de realistische oorzaken af in de volgorde waarin ze zich in de praktijk voordoen, en geeft bij elke oorzaak het controlecommando, de oplossing en de weg terug wanneer RDP helemaal dood is.

De foutmeldingen woord voor woord

Er is niet één melding, maar een handvol, en de exacte tekst beperkt de mogelijke oorzaak al flink. Deze varianten komt u het vaakst tegen:

• "De externe computer vereist verificatie op netwerkniveau, die niet wordt ondersteund door uw computer." De server eist NLA en de client levert het niet. Typisch bij oude clients, bij clients van derden onder Linux of macOS en bij verkeerd ingesteld clientbeleid.
• "Er is een verificatiefout opgetreden. Er kan geen contact worden gemaakt met de lokale beveiligingsinstantie." In het Engels: "The Local Security Authority cannot be contacted". Dat is de klassieke melding bij een certificaatprobleem of een afwijkende klok.
• "Er is een verificatiefout opgetreden. De gevraagde functie wordt niet ondersteund." Dat is vrijwel altijd CredSSP en niet NLA in engere zin. Verderop meer daarover.
• "De referenties die zijn gebruikt om verbinding te maken, werken niet." Account vergrendeld, uitgeschakeld, wachtwoord verlopen of het account ontbreekt in de groep Extern bureaublad-gebruikers.
• "De vertrouwensrelatie tussen dit werkstation en het primaire domein is mislukt." Het computeraccount in het domein klopt niet meer.

Belangrijk voor de afbakening: meldt de client pas na twintig seconden dat de externe computer niet bereikbaar is, dan is dat geen NLA-fout, maar een kwestie van netwerk, firewall of een service die niet draait. NLA-fouten komen snel terug, meestal binnen één tot drie seconden, want de TCP-verbinding staat wel degelijk en alleen de verificatie mislukt.

Oorzaak 1: tijdsverschil tussen client en server

Dit is met afstand de meest voorkomende oorzaak, en tegelijk de oorzaak die het vaakst over het hoofd wordt gezien, omdat "de klok loopt een beetje verkeerd" als een onschuldig probleem klinkt. Dat is het niet. Twee mechanismen breken meteen zodra de tijd uiteenloopt:

• Kerberos tolereert standaard maximaal vijf minuten afwijking. Daarboven wijst de domeincontroller de aanvraag af met KRB_AP_ERR_SKEW. Dat treft alle domeinleden.
• De TLS-controle van het RDP-certificaat mislukt zodra de klok van de client buiten de geldigheidsduur van het servercertificaat valt. Dat raakt ook losstaande servers zonder domein, en wel precies wanneer de server na een herstart opkomt met een klok in het verleden, zodat een net aangemaakt certificaat vanuit het oogpunt van de client nog helemaal niet geldig is.

Controleer dit op de server, in een PowerShell met beheerdersrechten:

w32tm /query /status /verbose
w32tm /query /source
w32tm /stripchart /computer:ptbtime1.ptb.de /samples:5 /dataonly

De stripchart geeft u de afwijking in seconden. Alles onder één seconde is prima, alles boven 60 seconden is verdacht en alles boven 300 seconden verklaart de fout.

Hier lopen de systemen uiteen, en de meeste handleidingen gooien beide op één hoop:

• Losstaande server zonder domein: een externe NTP-bron instellen.
• Domeinlid: in geen geval een eigen peerlijst instellen. Een lidserver moet zijn tijd uit de domeinhiërarchie halen, anders loopt hij weg van de domeincontroller.

w32tm /config /manualpeerlist:"ptbtime1.ptb.de,0x9 time.windows.com,0x9" /syncfromflags:manual /update

w32tm /config /syncfromflags:domhier /update

Herstart daarna in beide gevallen de service en synchroniseer opnieuw:

net stop w32time
net start w32time
w32tm /resync /rediscover

Eén bijzonderheid die u op gevirtualiseerde servers te pakken krijgt: staat de klok precies één of twee uur verkeerd, dan is dat geen drift maar een verschil in de interpretatie van de hardwareklok. Windows verwacht de RTC in lokale tijd, terwijl veel virtualisatieplatformen die in UTC aanbieden. Controleer eerst de tijdzone en zet daarna zo nodig de interpretatie om:

tzutil /g
tzutil /s "W. Europe Standard Time"

reg add "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /t REG_DWORD /d 1 /f

Oorzaak 2: verlopen of verkeerd gekoppeld certificaat

Zonder eigen PKI maakt Windows voor RDP een zelfondertekend certificaat aan dat ongeveer een half jaar geldig is en zichzelf normaal gesproken vernieuwt. "Normaal gesproken" is hier het sleutelwoord. Mislukt die vernieuwing op rechten in de sleutelopslag, of verloopt een handmatig gekoppeld certificaat van een interne CA, dan kunt u niet meer inloggen en krijgt u de melding over de lokale beveiligingsinstantie.

Controleren wat er in de opslag staat:

Get-ChildItem "Cert:\LocalMachine\Remote Desktop" | Select-Object Subject, NotBefore, NotAfter, Thumbprint

En daarna, welk certificaat de listener werkelijk gebruikt:

(Get-CimInstance -Namespace root\cimv2\terminalservices -ClassName Win32_TSGeneralSetting -Filter "TerminalName='RDP-tcp'").SSLCertificateSHA1Hash

Vergelijk de teruggegeven hash met de thumbprints uit het eerste commando. Er zijn twee foutbeelden mogelijk: de hash wijst naar een verlopen certificaat, of hij wijst naar een certificaat dat helemaal niet meer in de opslag ligt.

De reparatie bestaat eruit de koppeling los te maken en het oude certificaat te verwijderen. Windows maakt daarna bij het starten van de service een nieuw certificaat aan:

Remove-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name SSLCertificateSHA1Hash -ErrorAction SilentlyContinue

Get-ChildItem "Cert:\LocalMachine\Remote Desktop" | Where-Object { $_.NotAfter -lt (Get-Date) } | Remove-Item

Restart-Service TermService -Force

Twee waarschuwingen daarbij. Ten eerste gooit een herstart van TermService alle bestaande RDP-sessies eruit, ook uw eigen sessie, mocht u er op de een of andere manier toch nog op zitten. Voer dit dus via de console uit. Ten tweede: schrijft een groepsbeleid een certificaatsjabloon voor serververificatie voor, dan haalt de server zijn certificaat bij de interne CA. Is die CA niet bereikbaar of is het sjabloon verlopen, dan komt er geen nieuw certificaat en blijft de fout staan. Controleer in dat geval eerst de CA en niet de server.

Controle achteraf: het eerste commando levert nu een certificaat met een NotAfter-datum in de toekomst, en de SSLCertificateSHA1Hash wijst precies naar dat certificaat.

Oorzaak 3: account vergrendeld, uitgeschakeld of wachtwoord verlopen

Hier zit de valkuil die NLA van alle andere aanmeldproblemen onderscheidt: met NLA actief kunt u een verlopen wachtwoord niet via de RDP-client wijzigen. Het venster "Uw wachtwoord is verlopen en moet worden gewijzigd" verschijnt pas binnen de sessie, en zonder geslaagde verificatie komt u niet tot een sessie. In plaats daarvan meldt de client alleen dat de referenties niet werken. Het wachtwoord is volkomen correct, het is alleen verlopen.

De status van een lokaal account bekijken:

net user Administrator

Let op de regels "Account actief", "Account verloopt", "Wachtwoord verloopt" en "Wachtwoord kan worden gewijzigd". De bijbehorende maatregelen:

net user Administrator "NieuwLangWachtwoord!2026"

Enable-LocalUser -Name "Administrator"

Set-LocalUser -Name "Administrator" -PasswordNeverExpires $true

Een lokaal account dat na te veel mislukte pogingen vergrendeld is, verkeert in een eigen toestand die noch met Enable-LocalUser noch met een wachtwoordwijziging wordt opgeheven. Het ontgrendelt zichzelf zodra de vergrendelingsduur voorbij is, en die bekijkt u zo:

net accounts

Direct ontgrendelen kan zonder grafisch beheer via ADSI:

$u = [ADSI]"WinNT://./Administrator,user"; $u.IsAccountLocked = $false; $u.SetInfo()

Is de RDP-poort vanaf het internet bereikbaar, dan komen vergrendelingen vrijwel dagelijks voor, omdat bots uw beheerdersaccount stelselmatig aflopen. Dat is een sterk argument om de toegang te beperken in plaats van het account telkens opnieuw te ontgrendelen. Een andere poort helpt merkbaar tegen massascans, zie RDP-poort wijzigen zonder herstart.

Tot slot het groepslidmaatschap. De groepsnaam is vertaald, en juist daarop lopen scripts graag stuk. Taalonafhankelijk vraagt u die op via de bekende SID:

Get-LocalGroupMember -SID "S-1-5-32-555"

Oorzaak 4: NLA op de server uitgeschakeld of half uitgeschakeld

Twee losse schakelaars bepalen het gedrag, en juist hun combinatie zorgt voor de ellende. UserAuthentication stuurt NLA aan, SecurityLayer de beveiliging van het transport, met de waarden 0 voor de oude RDP-beveiligingslaag, 1 voor onderhandelen en 2 voor afgedwongen TLS.

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer

De typische doodlopende weg: iemand schakelt NLA uit omdat hij een certificaatprobleem vermoedt, maar laat SecurityLayer op 2 staan. Daarmee blijft de TLS-onderhandeling met het kapotte certificaat gewoon bestaan en verandert alleen de formulering van de melding. Wilt u voor de diagnose echt beide waarden verlagen, verlaag ze dan allebei en zet ze daarna weer terug.

(Get-CimInstance -Namespace root\cimv2\terminalservices -ClassName Win32_TSGeneralSetting -Filter "TerminalName='RDP-tcp'") | Invoke-CimMethod -MethodName SetUserAuthenticationRequired -Arguments @{UserAuthenticationRequired=0}

De tweede doodlopende weg is nog vervelender: u zet de registerwaarde, start opnieuw op, en hij staat weer op 1. Dan komt hij uit een groepsbeleid. Beleidswaarden staan op een andere plek en winnen altijd:

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v UserAuthentication

gpresult /r /scope:computer

Zolang daar een waarde staat, geldt elke lokale wijziging alleen tot de volgende toepassing van het beleid. Het beleid heet "Gebruikersverificatie voor externe verbindingen vereisen met verificatie op netwerkniveau" en moet op de domeincontroller worden aangepast.

En de belangrijkste regel aan het slot van dit hoofdstuk: NLA permanent uitschakelen is geen oplossing, maar een open deur. Zonder NLA kan iedereen die de poort bereikt het aanmeldscherm opvragen en daarmee een onbeschermd deel van de sessiestack aanspreken. Schakel het uit voor de diagnose en daarna meteen weer in.

Oorzaak 5: verbroken vertrouwensrelatie met het domein

Elk computeraccount in een domein heeft een eigen wachtwoord, dat standaard elke 30 dagen automatisch wordt gewisseld. Lopen de standen van server en domeincontroller uiteen, dan kan de server geen domeinaccounts meer verifiëren en mislukt NLA voor alle domeingebruikers, terwijl lokale accounts gewoon blijven werken. Precies dat patroon is het bewijs voor deze oorzaak.

De klassieke aanleiding in het serverbeheer is een terugzetting naar een oudere toestand, bijvoorbeeld uit een back-up of snapshot die ouder is dan de laatste wachtwoordwissel. Controleren:

Test-ComputerSecureChannel -Verbose

nltest /sc_verify:mijndomein.local

Repareren, ingelogd als lokale beheerder via de console:

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Reset-ComputerMachinePassword -Credential (Get-Credential)

De server uit het domein halen en opnieuw laten toetreden is hiervoor niet nodig en maakt de zaak vaak erger, omdat daarbij groepslidmaatschappen en rechten van het oude computeraccount verloren kunnen gaan. Na de reparatie volstaat een herstart van de Netlogon-service:

Restart-Service Netlogon

Als RDP helemaal niet meer werkt: de weg via de console

Alle voorgaande commando's gaan ervan uit dat u op de een of andere manier op de server komt. Precies dat is in het ergste geval niet zo. Bij de KVM-rootservers van KernelHost bereikt u daarom in het klantenpaneel een VNC-console die losstaat van RDP, van de Windows-firewall en zelfs van de netwerkstack van het gastsysteem. Dat is de noodtoegang waarmee u zich uit elk van de hierboven beschreven situaties zelf bevrijdt. Bij dedicated servers loopt de noodtoegang via de support.

Drie dingen zijn op de VNC-console anders dan in een RDP-sessie en kosten regelmatig tijd:

• Toetsenbordindeling. De console levert vaak een US-indeling terwijl Windows op Nederlands staat, of andersom. Speciale tekens in wachtwoorden komen dan verkeerd aan, en u houdt een correct wachtwoord voor onjuist. Gebruik bij twijfel het schermtoetsenbord met osk.exe vanuit het aanmeldscherm.
• Klembord. Kopiëren vanaf uw eigen computer naar de console werkt meestal niet. Houd er rekening mee dat u alles moet overtypen en kies uw tijdelijke wachtwoorden daarop af.
• Inloggen met een lokaal account. Bij domeinproblemen logt u in met .\Administrator: de punt en de backslash dwingen het lokale account af in plaats van het domeinaccount.

Op de console controleert u vervolgens de basis, voordat u aan NLA gaat sleutelen:

sc query TermService

netstat -ano | findstr :3389

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections

Staat fDenyTSConnections op 1, dan zijn externe verbindingen volledig uitgeschakeld, onafhankelijk van NLA:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f

De firewallregels schakelt u taalonafhankelijk in via de interne groepsaanduiding, omdat de weergegeven groepsnaam per systeemtaal anders luidt:

Enable-NetFirewallRule -Group "@FirewallAPI.dll,-28752"

Het bijzondere geval CredSSP, dat vaak wordt verward

Luidt de melding letterlijk "De gevraagde functie wordt niet ondersteund" en noemt zij het CredSSP-versleutelingsoracleherstel, dan is geen van de vijf oorzaken hierboven de schuldige. Hier lopen de patchniveaus van client en server uiteen: de ene kant eist de geharde CredSSP-variant, de andere kent die nog niet.

De enige nette oplossing is beide kanten bij te werken. De registerwijziging met AllowEncryptionOracle op de client, die overal op internet rondgaat, zet precies de verharding buiten werking die de fout veroorzaakt en opent daarmee opnieuw een bekende aanvalsweg. Hebt u haar kort nodig om de updates binnen te halen, zet haar dan terug zodra de server bij is.

Waaraan u ziet dat het echt verholpen is

Een geslaagde verbinding is het zwakste bewijs, want die lukt ook wanneer u NLA voor de diagnose hebt uitgeschakeld. Controleer in plaats daarvan op volgorde:

1. NLA is weer actief. UserAuthentication staat op 1 en SecurityLayer op 2.
2. De klok klopt. De afwijking uit de stripchart ligt onder één seconde, en w32tm /query /source noemt een echte bron, niet "Local CMOS Clock" en niet "Free-running System Clock".
3. Het certificaat is geldig. NotAfter ligt in de toekomst, en de gekoppelde hash wijst precies naar dat certificaat.
4. Het gebeurtenislogboek bevestigt de geslaagde netwerkverificatie. Gebeurtenis 1149 verschijnt pas nadat NLA is doorlopen en is daarmee het eigenlijke bewijs.

Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational" -MaxEvents 20 | Where-Object Id -eq 1149

Voor de tegenproef bij mislukte pogingen zeggen de statuscodes in gebeurtenis 4625 meer dan welke clientmelding ook: 0xC0000071 staat voor een verlopen wachtwoord, 0xC0000072 voor een uitgeschakeld account, 0xC0000234 voor een vergrendeld account en 0xC000006A voor een werkelijk onjuist wachtwoord.

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 5 | Format-List TimeCreated, Message

Tot slot de sessies zelf, bij voorkeur vanuit de console:

qwinsta

Kort overzicht voor de foutopsporing

Zet u een Windows-server opnieuw op, dan loont het om de tijdbron, het accountbeleid en de toegangsweg meteen aan het begin goed in te richten, in plaats van ze later onder druk te repareren. Als leidraad daarvoor dient de checklist voor een nieuwe rootserver, en wie de RDP-toegang extra wil beveiligen, vindt in RDP-poort wijzigen zonder herstart de eenvoudigste eerste stap tegen geautomatiseerde aanmeldpogingen.