Er zijn maar weinig dingen ontmoedigender dan gaan zitten om op afstand verbinding te maken met je eigen pc, je inloggegevens in te typen en dan, op de minst behulpzame manier mogelijk, te horen krijgen dat “een beperking voor het gebruikersaccount (bijvoorbeeld een tijdvaksbeperking) voorkomt dat je je kunt aanmelden.”

Een tijdvaksbeperking? Ik heb deze machine zelf opgezet.

Dat was ik, buitengesloten van een Windows Server-machine een uur nadat ik deze had gemigreerd naar een nieuwer functioneel niveau van het domein. Na het doorspitten van Microsofts documentatie en sysadminfora kreeg ik uiteindelijk bij elkaar gepuzzeld wat er mis was gegaan, en dat was helemaal niet wat de foutmelding suggereerde.

Dit is wat niemand je vooraf vertelt: deze fout is niet één probleem, het is een categorie. De oorzaak kan van alles zijn, van een account zonder wachtwoord tot een verificatiepad dat stilzwijgend terugvalt op NTLM wanneer alleen Kerberos is toegestaan. Als je dat eenmaal begrijpt, ben je al halverwege het oplossen ervan.

Gebruikersaccountbeperking Verhindert Aanmelden

Inhoudsopgave

Symptoom / Oorzaak	Omgeving	Eerste actie	Frequentie
Leeg / geen wachtwoord op lokaal account	Standalone / thuis-pc	Oplossing 1 — Stel een wachtwoord in	Veelvoorkomend
Account ontbreekt in recht ‘RDP-aanmelding toestaan’	Elke	Oplossing 2 — Controleer Toewijzing van gebruikersrechten	Veelvoorkomend
Account in recht ‘RDP-aanmelding weigeren’	Elke	Oplossing 2 — Verwijder uit Weigeringsbeleid	Veelvoorkomend
Verbinding via IP, NTLM beperkt	Domein	Oplossing 3 — Gebruik FQDN-hostnaam	Veelvoorkomend
Account vergrendeld	Elke	Oplossing 4 — Ontgrendel in ADUC / lusrmgr	Incidenteel
Beperking van aanmeldingsuren	Domein	Oplossing 4 — Controleer aanmeldingsuren in ADUC	Incidenteel
Account in Protected Users, Kerberos werkt niet	Domein	Oplossing 5 — Herstel Kerberos of verwijder uit groep	Beheer/gehard
Gebeurtenislogboeken tonen verificatiefout	Elke	Oplossing 6 — Lees het beveiligingslogboek (Gebeurtenis 4625)	Diagnostisch

De oplossing die u nodig hebt hangt volledig af van uw omgeving. Loop deze vragen door voordat u iets verandert.

Kunt u lokaal met hetzelfde account aanmelden? Zo ja, en alleen RDP faalt, dan gaat het niet om onjuiste aanmeldingsgegevens. Het probleem is een RDP-rechtentoewijzing, een beleidsbeperking of een probleem in het authenticatiepad. Controleer op de doelcomputer in Event Viewer → Windows Logs → Security op Event ID 4625. Voor domeinomgevingen controleert u ook de beveiligingslogboeken van de domeincontroller(s), aangezien sommige authenticatiefouten alleen daar zichtbaar zijn.

Eén gebruiker of iedereen? Een enkele gebruiker die wordt buitengesloten wijst op een instelling op accountniveau. Iedereen die gelijktijdig wordt buitengesloten duidt op een recente beleidswijziging, een Groepsbeleid-update of een configuratiewijziging aan de serverzijde.

Zelfstandige machine of aan een domein gekoppeld? Domeinomgevingen brengen Active Directory-groepsbeleid, Kerberos, NTLM-beperkingen en het gedrag van Protected Users met zich mee. Als u op een zelfstandige thuis-pc werkt, zijn waarschijnlijk alleen Oplossingen 1, 2 en 4 relevant. Als u zich in een domein bevindt, kunnen alle oplossingen van toepassing zijn.

Verbindt u via IP-adres of hostnaam? Dit is belangrijker dan de meeste mensen zich realiseren. Verbinden via een IP-adres voorkomt doorgaans dat Windows Kerberos gebruikt en dwingt een terugval naar NTLM af. Als NTLM in uw omgeving is beperkt, mislukt die terugval en krijgt u precies deze fout, ook al is er niets aan uw daadwerkelijke account veranderd. Zie Oplossing 3.

Is er recent iets veranderd? Updates van Groepsbeleid, OS-patches, upgrades van het domeinfunctioneringsniveau en beveiligingshardening kunnen RDP van de ene op de andere dag laten uitvallen zonder zichtbare waarschuwing. Stel deze vraag altijd voordat u aanneemt dat het probleem bij uw account ligt.

Oplossingen 1–4 zijn hier het meest relevant. Deze vereisen geen kennis van Active Directory of domeinen.

Begin hier, vooral op een thuis-pc of een losstaande machine.

Windows blokkeert standaard externe aanmeldingen voor lokale accounts zonder wachtwoord. Dit is bewust en gedocumenteerd beveiligingsbeleid: de instelling “Accounts: Limit local account use of blank passwords to console logon only” is standaard ingeschakeld, wat betekent dat accounts zonder wachtwoord beperkt zijn tot interactieve console-aanmeldingen. RDP is een externe interactieve aanmelding en wordt daarom geblokkeerd.

Waarom dit gebeurt: Microsoft documenteert dit gedrag onder de instelling voor lokaal beveiligingsbeleid “Accounts: Gebruik van lege wachtwoorden door lokale accounts beperken tot alleen aanmelden via de console.” (Microsoft Learn)

Stel een wachtwoord in: open Computerbeheer → Lokale gebruikers en groepen → Gebruikers → klik met de rechtermuisknop op het account → Wachtwoord instellen. Als dat het oplost, ben je klaar.

Er is een noodoplossing: je kunt de beperking voor lege wachtwoorden uitschakelen via secpol.msc of de registersleutel LimitBlankPasswordUse. Beschouw dit als een laatste redmiddel op elke via het netwerk toegankelijke machine.

Waarschuwing: Het uitschakelen van beperkingen voor lege wachtwoorden verzwakt uw aanvalsoppervlak aanzienlijk. Het instellen van een sterk wachtwoord is altijd de juiste oplossing.

Dit is een van de meest voorkomende oorzaken en een van de gemakkelijkste om over het hoofd te zien.

Windows gebruikt twee complementaire Groepsbeleid-instellingen om RDP-toegang te beheren:

Aanmelden via Services voor extern bureaublad toestaan — verleent het recht om verbinding te maken.
Aanmelden via Services voor extern bureaublad weigeren — blokkeert het recht om verbinding te maken.

Het beleid Weigeren overschrijft altijd Toestaan, ongeacht het groepslidmaatschap. Dit is gedocumenteerd gedrag van Microsoft.

Waar je het kunt vinden: Open gpedit.msc → Computerconfiguratie → Windows-instellingen → Beveiligingsinstellingen → Lokaal beleid → Toewijzing van gebruikersrechten.

Controleer beide beleidsinstellingen. Bevestig dat uw account, of een groep waartoe het behoort, zoals Gebruikers van Extern bureaublad of Beheerders, bij Toestaan wordt vermeld. Bevestig dat het niet voorkomt bij Weigeren. Als uw account volledig ontbreekt bij Toestaan, wordt RDP-toegang geblokkeerd, ongeacht uw wachtwoord of aanmeldgegevens.

Op domeincomputers: Deze rechten kunnen op domeinniveau worden ingesteld door Groepsbeleid en kunnen lokale instellingen overschrijven. Als de lokale instellingen correct lijken maar het probleem aanhoudt, controleer dan op conflicterende GPO’s met behulp van gpresult /h report.html op de doelmachine.

Deze ene wijziging lost meer problemen op dan je redelijkerwijs zou mogen verwachten.

Wanneer je verbinding maakt met een IP-adres (bijvoorbeeld, 192.168.1.100), kan Windows doorgaans geen Kerberos-authenticatie gebruiken en valt het in plaats daarvan terug op NTLM. Op zelfstandige thuismachines is dit vaak prima. Op aan een domein gekoppelde machines waar NTLM is beperkt of uitgeschakeld, mislukt deze terugval stilzwijgend en krijg je de foutmelding over accountbeperkingen, ook al is er niets aan je account veranderd.

Gebruik in plaats daarvan de hostnaam van de machine:

server.yourdomain.com ✔ Aanbevolen

192.168.1.100 ✘ Forceert terugval naar NTLM

Gebruik bij het verbinden met domeinmachines ook aanmeldgegevens in UPN-formaat: user@domain.com in plaats van DOMAIN\user. Dit helpt Windows het juiste authenticatiepad te kiezen en voorkomt een verrassend aantal randgevallen.

Uitzondering: Microsoft heeft een nieuwere Kerberos-over-IP-functionaliteit voor Windows Server-omgevingen gedocumenteerd, maar het vereist expliciete configuratie en is niet standaard ingeschakeld. (Microsoft Learn: Kerberos voor IP-adres configureren).

Windows toont voor verschillende, afzonderlijke soorten beperkingen hetzelfde generieke bericht, wat er deels voor zorgt dat deze fout zo frustrerend is. Accountvergrendelingen en beperkingen op aanmeldingsuren zijn twee van de zeldzame gevallen waarin de foutmelding letterlijk klopt.

Voor lokale accounts (standalone of domein) Open lusrmgr.msc → selecteer de gebruiker → controleer of Account is geblokkeerd is aangevinkt. Deblokkeer het indien dit het geval is.

Voor domeinaccounts Open Active Directory Users and Computers → zoek de gebruiker → dubbelklik → tabblad Account. Controleer de optie Account ontgrendelen en bekijk Aanmeldingsuren.

Een Windows Server 2016-beheerder beschreef dat hij precies tegen deze muur aanliep: verbinding maken met de server mislukte met het bericht over een accountbeperking, maar er waren geen tijdsbeperkingen bewust geconfigureerd. De oorzaak was een Groepsbeleid dat stilletjes een aanmeldingsbeperking had toegepast na een update van het domeinbeleid. Event ID 4625 in het beveiligingslogboek zou de specifieke subcode hebben weergegeven.

Gebeurtenis 4625: De vermelding in het beveiligingslogboek voor een mislukte aanmelding bevat een substatuscode die de exacte reden aangeeft. Veelvoorkomende waarden: 0xC0000234 (account vergrendeld), 0xC000006F (aanmelding buiten toegestane uren), 0xC0000022 (toegang geweigerd). Controleer dit voordat u naar de oorzaak gaat gissen.

Oplossingen 5 en 6 vereisen toegang tot Active Directory en bekendheid met Kerberos en NTLM. Als u een stand-alone thuis-pc gebruikt, kunt u deze sectie overslaan.

Dit is de foutmodus die ervaren beheerders overvalt, vaak na een domeinupgrade.

De beveiligingsgroep Protected Users van Active Directory dwingt strengere authenticatieregels af voor zijn leden:

NTLM-authenticatie wordt volledig geblokkeerd.
Alleen Kerberos is toegestaan, en dan uitsluitend met AES-versleuteling.
RC4- en DES-Kerberos-versleutelingstypen zijn niet toegestaan.
Referenties worden niet op de machine in de cache opgeslagen.

Op papier is dit uitstekende beveiligingshygiëne. In de praktijk verstoort dit RDP-toegang in omgevingen die stilzwijgend afhankelijk waren van NTL, wat precies is wat er gebeurt wanneer je verbinding maakt via een IP-adres, wanneer DNS verkeerd is geconfigureerd, of wanneer Kerberos na een domeinupgrade niet volledig is gevalideerd. De gebruiker krijgt de generieke melding over accountbeperkingen, zonder enige aanwijzing dat Protected Users hierbij betrokken is.

Waarom het opduikt na domeinupgrades: Het verhogen van het functionele niveau van het domein maakt vaak strengere afdwinging van bestaande beleidsregels mogelijk. Accounts die al in Protected Users zaten maar eerder NTLM-terugval tolereerden, kunnen plotseling falen. (Microsoft Learn: Beveiligingsgroep Protected Users)

Voordat u iemand uit Protected Users verwijdert, probeer deze stappen in de volgende volgorde:

Gebruik de FQDN van de machine (server.domain.com), geen IP-adres.
Gebruik UPN-inloggegevens (user@domain.com).
Controleer of DNS-resolutie correct werkt vanaf de computer die de verbinding maakt.
Controleer de connectiviteit met de domeincontroller en of de Kerberos-service actief is.

Als Kerberos correct werkt, verdwijnt het probleem meestal zonder wijzigingen aan accounts. Als dat niet zo is, kunt u het account als tijdelijke maatregel uit Protected Users verwijderen:

powershell
$Cred = Get-Credential Remove-ADGroupMember -Identity "Protected Users" -Members YourAccountName -Credential $Cred

Over PowerShell op afstand: Deze methode werkt wanneer PowerShell Remoting beschikbaar is. Houd er rekening mee dat PowerShell Remoting ook Kerberos gebruikt wanneer beschikbaar en NTLM als terugvaloptie, waardoor het in volledig geharde omgevingen met dezelfde authenticatiebeperkingen te maken kan krijgen. (Microsoft Learn: WinRM-beveiliging)

Waarschuwing: Het verwijderen van een account uit Protected Users verzwakt de beveiligingspositie van het account. Beschouw dit als een diagnostische stap, niet als een permanente oplossing. De juiste oplossing is ervoor te zorgen dat Kerberos in uw omgeving correct functioneert.

Meld u af en wacht tot de authenticatie is vernieuwd voordat u opnieuw via RDP probeert te verbinden na elke wijziging in het groepslidmaatschap.

Stop nu met raden en begin met lezen.

Op de doelcomputer Logboeken → Windows-logboeken → Beveiliging. Filter op gebeurtenis-ID 4625. Elke vermelding bevat een reden van mislukking en een substatuscode die de exacte oorzaak aangeeft, veel nauwkeuriger dan de RDP-foutmelding zelf.

Voor meer diepgaande verificatietracering schakelt u ook in: Toepassings- en servicelogboeken → Microsoft → Windows → Verificatie.

Op domeincontrollers Sommige verificatiefouten, vooral Kerberos-gerelateerde, worden alleen vastgelegd op de domeincontroller die het verzoek heeft verwerkt, niet op de doelcomputer. Controleer de beveiligingslogboeken op uw DC’s wanneer de lokale logboeken van de doelcomputer u niet het volledige beeld geven.

Zodra u de substatuscode in gebeurtenis 4625 vindt, houdt de fout op vaag te zijn en wordt het een specifiek, diagnoseerbaar probleem. Veelvoorkomende codes staan vermeld in de opmerking bij Fix 4 hierboven.

Als u foutcode 0xC07 ziet, met name op macOS bij gebruik van Microsoft Remote Desktop, verschijnt deze doorgaans samen met dezelfde klasse van authenticatie- en beperkingsproblemen die in dit artikel worden beschreven. Communityrapporten suggereren dat verbinden via de hostnaam in plaats van het IP-adres het in veel gevallen oplost, wat overeenkomt met het NTLM-terugvalpatroon dat in Fix 3 wordt beschreven.

Er is geen definitieve Microsoft-documentatie die 0xC07 eenduidig aan één enkele onderliggende oorzaak koppelt. Beschouw het als een signaal dat u zich in de juiste probleemcategorie bevindt in plaats van als een precieze diagnose. De bovenstaande oplossingen zijn van toepassing.

Wanneer RDP-toegang wordt geweigerd met het bericht “user account restriction”, doet Windows precies wat het hoort te doen, alleen zonder aan te geven welke regel je hebt overtreden.

De snelste weg naar een oplossing is:

Gebruik de diagnostische matrix bovenaan dit artikel om je meest waarschijnlijke oorzaak te identificeren.
Pas de relevante oplossing toe voor je omgeving (thuis/standalone of domein).
Controleer Event ID 4625 op de doelcomputer als de oorzaak nog onduidelijk is.
Controleer in domeinomgevingen ook de logboeken van de domeincontroller en bevestig dat Kerberos werkt voordat je accountinstellingen wijzigt.

Meestal is het iets eenvoudigs. Zelfs wanneer dat niet zo is, is het doorgaans iets logisch, alleen verborgen achter een zeer onbehulpzame melding.

Hoe te verhelpen dat een gebruikersaccountbeperking het inloggen verhindert

Snelle diagnose

Deel 1: Thuis-pc & stand-alone machines

Oplossing 1: Het account heeft geen wachtwoord

Oplossing 2: Controleer wie toestemming heeft om via RDP verbinding te maken

Oplossing 3: Stop met verbinding maken via een IP-adres

Oplossing 4: Controleer op accountvergrendelingen en beperkingen voor aanmeldingsuren

Deel 2: Domein- en Enterprise-omgevingen

Oplossing 5: De groep Beschermde gebruikers

Oplossing 6: Lees de logbestanden wanneer niets anders meer logisch is

Hoe zit het met foutcode 0xC07?

Samenvatting