Es gibt nur wenige Dinge, die niederschmetternder sind, als sich hinzusetzen, um sich per Fernzugriff mit dem eigenen PC zu verbinden, die Anmeldedaten einzugeben und dann auf die unhilfreichste Art mitgeteilt zu bekommen, dass “eine Benutzerkontobeschränkung (zum Beispiel eine zeitliche Beschränkung) Sie daran hindert, sich anzumelden.”

Eine zeitliche Beschränkung? Diesen Rechner habe ich selbst eingerichtet.

Das war ich, aus einem Windows-Server ausgesperrt, eine Stunde nachdem ich ihn auf eine neuere Domänenfunktionsstufe migriert hatte. Nachdem ich Microsofts Dokumentation und Sysadmin-Foren durchgearbeitet hatte, konnte ich schließlich nachvollziehen, was schiefgelaufen war, und es war ganz und gar nicht das, was die Fehlermeldung nahelegte.

Hier ist etwas, das einem niemand gleich am Anfang sagt: Dieser Fehler ist kein einzelnes Problem, sondern eine Kategorie. Die Ursache kann alles Mögliche sein, von einem Konto ohne Passwort bis hin zu einem Authentifizierungspfad, der stillschweigend auf NTLM zurückfällt, obwohl nur Kerberos zulässig ist. Wenn man das einmal verstanden hat, ist man bereits auf halbem Weg zur Lösung.

Benutzerkontoeinschränkung verhindert die Anmeldung

Inhaltsverzeichnis

Symptom / Ursache	Umgebung	Erste Maßnahme	Häufigkeit
Leer / kein Kennwort auf lokalem Konto	Einzelplatz / Heim-PC	Lösung 1 — Kennwort festlegen	Häufig
Konto fehlt beim Recht RDP-Anmeldung zulassen	Beliebig	Lösung 2 — Zuweisung von Benutzerrechten prüfen	Häufig
Konto im Recht RDP-Anmeldung verweigern	Beliebig	Lösung 2 — Aus der Verweigerungsrichtlinie entfernen	Häufig
Verbindung per IP, NTLM eingeschränkt	Domäne	Lösung 3 — FQDN-Hostname verwenden	Häufig
Konto gesperrt	Beliebig	Lösung 4 — In ADUC / lusrmgr entsperren	Gelegentlich
Einschränkung der Anmeldezeiten	Domäne	Lösung 4 — Anmeldezeiten in ADUC prüfen	Gelegentlich
Konto in Protected Users, Kerberos fehlerhaft	Domäne	Lösung 5 — Kerberos reparieren oder aus der Gruppe entfernen	Admin/gehärtet
Ereignisprotokolle zeigen Authentifizierungsfehler	Beliebig	Lösung 6 — Sicherheitsprotokoll lesen (Ereignis 4625)	Diagnostisch

Der erforderliche Fix hängt vollständig von Ihrer Umgebung ab. Gehen Sie diese Fragen durch, bevor Sie irgendetwas ändern.

Können Sie sich lokal mit demselben Konto anmelden? Wenn ja und nur RDP schlägt fehl, handelt es sich nicht um falsche Anmeldeinformationen. Das Problem ist eine RDP-Berechtigungszuweisung, eine Richtlinienbeschränkung oder ein Problem im Authentifizierungspfad. Überprüfen Sie auf dem Zielcomputer die Ereignisanzeige → Windows-Protokolle → Sicherheit auf Ereignis-ID 4625. In Domänenumgebungen prüfen Sie außerdem die Sicherheitsprotokolle der Domänencontroller, da einige Authentifizierungsfehler nur dort sichtbar sind.

Ein Benutzer oder alle? Eine Sperrung eines einzelnen Benutzers weist auf eine Einstellung auf Kontoebene hin. Sind alle gleichzeitig ausgesperrt, deutet das auf eine kürzliche Richtlinienänderung, ein Gruppenrichtlinien-Update oder eine serverseitige Konfigurationsänderung hin.

Eigenständiger Computer oder der Domäne beigetreten? Domänenumgebungen bringen Active-Directory-Gruppenrichtlinien, Kerberos, NTLM-Einschränkungen und das Verhalten der Gruppe Protected Users mit sich. Wenn Sie einen eigenständigen Heim-PC verwenden, sind wahrscheinlich nur Fixes 1, 2 und 4 relevant. In einer Domäne können alle Fixes zutreffen.

Stellen Sie die Verbindung über IP-Adresse oder Hostnamen her? Das ist wichtiger, als die meisten denken. Die Verbindung über IP-Adresse verhindert typischerweise die Verwendung von Kerberos durch Windows und erzwingt ein Fallback auf NTLM. Wenn NTLM in Ihrer Umgebung eingeschränkt ist, schlägt dieses Fallback fehl, und Sie erhalten genau diesen Fehler, obwohl sich an Ihrem eigentlichen Konto nichts geändert hat. Siehe Fix 3.

Hat sich kürzlich etwas geändert? Gruppenrichtlinien-Updates, Betriebssystem-Patches, Upgrades der Domänenfunktionsebene und Sicherheitshärtung können RDP über Nacht ohne sichtbare Warnung außer Betrieb setzen. Stellen Sie diese Frage immer, bevor Sie davon ausgehen, dass Ihr Konto das Problem ist.

Die Korrekturen 1–4 sind hier am relevantesten. Diese erfordern keine Kenntnisse zu Active Directory oder Domänen.

Beginnen Sie hier, insbesondere auf einem Heim-PC oder einem eigenständigen Rechner.

Windows blockiert standardmäßig Remoteanmeldungen für lokale Konten ohne Kennwort. Dies ist beabsichtigt und eine dokumentierte Sicherheitsrichtlinie: Die Einstellung “Accounts: Limit local account use of blank passwords to console logon only” ist standardmäßig aktiviert, was bedeutet, dass kennwortlose Konten auf interaktive Konsolenanmeldungen beschränkt sind. RDP ist eine entfernte interaktive Anmeldung und wird daher blockiert.

Warum das passiert: Microsoft dokumentiert dieses Verhalten unter der Einstellung der lokalen Sicherheitsrichtlinie “Konten: Verwendung leerer Kennwörter für lokale Konten nur auf die Anmeldung an der Konsole beschränken.” (Microsoft Learn)

Legen Sie ein Kennwort fest: Öffnen Sie die Computerverwaltung → Lokale Benutzer und Gruppen → Benutzer → klicken Sie mit der rechten Maustaste auf das Konto → Kennwort festlegen. Wenn das das Problem behebt, sind Sie fertig.

Es gibt einen Workaround: Sie können die Beschränkung für leere Kennwörter über secpol.msc oder den Registrierungsschlüssel LimitBlankPasswordUse deaktivieren. Betrachten Sie dies auf jedem netzwerkzugänglichen Computer nur als letzten Ausweg.

Warnung: Das Deaktivieren von Einschränkungen für leere Passwörter schwächt Ihre Angriffsfläche erheblich. Das Festlegen eines starken Passworts ist immer die richtige Lösung.

Dies ist eine der häufigsten Ursachen und eine der am leichtesten zu übersehenden.

Windows verwendet zwei sich ergänzende Gruppenrichtlinieneinstellungen, um den RDP-Zugriff zu steuern:

Anmelden über Remotedesktopdienste zulassen — gewährt das Recht, eine Verbindung herzustellen.
Anmelden über Remotedesktopdienste verweigern — verweigert das Recht, eine Verbindung herzustellen.

Die Verweigern-Richtlinie hat immer Vorrang vor Zulassen, unabhängig von der Gruppenmitgliedschaft. Dies ist ein von Microsoft dokumentiertes Verhalten.

Wo man es findet: Öffnen Sie gpedit.msc → Computerkonfiguration → Windows-Einstellungen → Sicherheitseinstellungen → Lokale Richtlinien → Zuweisen von Benutzerrechten.

Überprüfen Sie beide Richtlinien. Stellen Sie sicher, dass Ihr Konto oder eine Gruppe, der es angehört, z. B. Remote Desktop Users oder Administrators, unter Zulassen erscheint. Bestätigen Sie, dass es nicht unter Verweigern erscheint. Wenn Ihr Konto überhaupt nicht unter Zulassen aufgeführt ist, ist der RDP-Zugriff unabhängig von Ihrem Kennwort oder Ihren Anmeldeinformationen blockiert.

Auf Domänencomputern: Diese Rechte können auf Domänenebene durch Gruppenrichtlinien festgelegt werden und lokale Einstellungen außer Kraft setzen. Wenn die lokalen Einstellungen korrekt erscheinen, das Problem jedoch weiterhin besteht, überprüfen Sie auf widersprüchliche GPOs mit gpresult /h report.html auf dem Zielcomputer.

Diese eine Änderung behebt mehr Probleme, als sie eigentlich sollte.

Wenn Sie über eine IP-Adresse eine Verbindung herstellen (zum Beispiel 192.168.1.100), kann Windows in der Regel keine Kerberos-Authentifizierung verwenden und greift stattdessen auf NTLM zurück. Auf eigenständigen Heimrechnern ist das oft unproblematisch. Auf domänengebundenen Rechnern, auf denen NTLM eingeschränkt oder deaktiviert ist, schlägt dieses Fallback stillschweigend fehl, und Sie erhalten den Fehler wegen Kontobeschränkung, obwohl sich an Ihrem Konto nichts geändert hat.

Verwenden Sie stattdessen den Hostnamen des Rechners:

server.yourdomain.com ✔ Empfohlen

192.168.1.100 ✘ Erzwingt NTLM-Fallback

Verwenden Sie beim Herstellen einer Verbindung zu Domänenrechnern außerdem Anmeldedaten im UPN-Format: user@domain.com statt DOMAIN\user. Das hilft Windows, den richtigen Authentifizierungspfad zu wählen, und vermeidet überraschend viele Sonderfälle.

Ausnahme: Microsoft hat eine neuere Kerberos-over-IP-Funktion für Windows-Server-Umgebungen dokumentiert, sie erfordert jedoch eine explizite Konfiguration und ist standardmäßig nicht aktiviert. (Microsoft Learn: Konfigurieren von Kerberos für IP-Adresse).

Windows gibt für mehrere unterschiedliche Einschränkungstypen dieselbe generische Meldung zurück, was teilweise dazu beiträgt, dass dieser Fehler so frustrierend ist. Kontosperrungen und Anmeldezeitbeschränkungen sind zwei der seltenen Fälle, in denen die Fehlermeldung wörtlich zutrifft.

Für lokale Konten (eigenständig oder Domäne) Öffnen Sie lusrmgr.msc → wählen Sie den Benutzer aus → prüfen Sie, ob Konto ist gesperrt aktiviert ist. Entsperren Sie das Konto, falls ja.

Für Domänenkonten Öffnen Sie Active Directory-Benutzer und -Computer → suchen Sie den Benutzer → doppelklicken → Registerkarte Konto. Aktivieren Sie Konto entsperren und prüfen Sie die Anmeldezeiten.

Ein Administrator für Windows Server 2016 beschrieb, genau auf dieses Problem gestoßen zu sein: Die Verbindung zum Server schlug mit der Meldung über eine Kontoeinschränkung fehl, es waren jedoch keine zeitlichen Beschränkungen absichtlich konfiguriert worden. Die Ursache war eine Gruppenrichtlinie, die nach einer Aktualisierung der Domänenrichtlinie stillschweigend eine Anmeldebeschränkung angewendet hatte. Die Ereignis-ID 4625 im Sicherheitsprotokoll hätte den spezifischen Untercode angezeigt.

Ereignis 4625: Der Sicherheitsprotokolleintrag für eine fehlgeschlagene Anmeldung enthält einen Unterstatuscode, der den genauen Grund angibt. Häufige Werte: 0xC0000234 (Konto gesperrt), 0xC000006F (Anmeldung außerhalb der zulässigen Zeiten), 0xC0000022 (Zugriff verweigert). Prüfen Sie dies, bevor Sie über die Ursache spekulieren.

Die Korrekturen 5 und 6 erfordern Zugriff auf Active Directory sowie Kenntnisse in Kerberos und NTLM. Wenn Sie auf einem eigenständigen Heim-PC arbeiten, können Sie diesen Abschnitt überspringen.

Dies ist der Fehlermodus, der selbst erfahrene Administratoren kalt erwischt, oft nach einem Domänenupgrade.

Die Sicherheitsgruppe ‘Geschützte Benutzer’ von Active Directory erzwingt für ihre Mitglieder strengere Authentifizierungsregeln:

NTLM-Authentifizierung wird vollständig blockiert.
Nur Kerberos ist zulässig, und zwar ausschließlich mit AES-Verschlüsselung.
Die Kerberos-Verschlüsselungstypen RC4 und DES sind nicht zulässig.
Anmeldeinformationen werden nicht auf dem Computer zwischengespeichert.

Auf dem Papier ist das ausgezeichnete Sicherheitshygiene. In der Praxis bricht dadurch der RDP-Zugriff in Umgebungen, die stillschweigend von NTL abhingen – genau das passiert, wenn Sie sich per IP-Adresse verbinden, wenn DNS falsch konfiguriert ist oder wenn Kerberos nach einem Domänenupgrade noch nicht vollständig validiert wurde. Der Benutzer erhält die generische Meldung zu Kontoeinschränkungen, ohne Hinweis darauf, dass ‘Geschützte Benutzer’ beteiligt ist.

Warum es nach Domain-Upgrades auftaucht: Das Anheben der Domänenfunktionsebene ermöglicht häufig eine strengere Durchsetzung bestehender Richtlinien. Konten, die bereits der Sicherheitsgruppe ‘Geschützte Benutzer’ angehörten, bei denen zuvor jedoch NTLM-Fallbacks toleriert wurden, können plötzlich fehlschlagen. (Microsoft Learn: Sicherheitsgruppe Geschützte Benutzer)

Bevor Sie jemanden aus Protected Users entfernen, führen Sie diese Schritte der Reihe nach aus:

Verwenden Sie den FQDN des Computers (server.domain.com), nicht eine IP-Adresse.
Verwenden Sie UPN-Anmeldeinformationen (user@domain.com).
Überprüfen Sie, dass die DNS-Auflösung vom zugreifenden Computer aus korrekt funktioniert.
Bestätigen Sie die Konnektivität zum Domänencontroller und dass der Kerberos-Dienst ausgeführt wird.

Wenn Kerberos ordnungsgemäß funktioniert, verschwindet das Problem in der Regel ohne Änderungen am Konto. Falls nicht, können Sie das Konto vorübergehend aus Protected Users entfernen:

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

Zum PowerShell-Remoting: Dieser Ansatz funktioniert, wenn PowerShell Remoting verfügbar ist. Beachten Sie, dass PowerShell Remoting, wenn verfügbar, ebenfalls Kerberos und als Fallback NTLM verwendet, sodass es in vollständig gehärteten Umgebungen auf dieselben Authentifizierungsbeschränkungen stoßen kann. (Microsoft Learn: WinRM-Sicherheit)

Warnung: Das Entfernen eines Kontos aus der Gruppe “Geschützte Benutzer” schwächt dessen Sicherheitsstatus. Behandeln Sie dies als einen Diagnoseschritt, nicht als eine dauerhafte Lösung. Die richtige Lösung besteht darin, sicherzustellen, dass Kerberos in Ihrer Umgebung ordnungsgemäß funktioniert.

Melden Sie sich ab und warten Sie, bis die Authentifizierung aktualisiert wurde, bevor Sie nach jeder Änderung der Gruppenmitgliedschaft RDP erneut versuchen.

An diesem Punkt sollten Sie aufhören zu raten und anfangen zu lesen.

Auf der Zielmaschine Ereignisanzeige → Windows-Protokolle → Sicherheit. Filtern Sie nach der Ereignis-ID 4625. Jeder Eintrag enthält eine Fehlerursache und einen Substatuscode, der die genaue Ursache angibt, weit präziser als die RDP-Fehlermeldung selbst.

Für eine tiefergehende Authentifizierungsverfolgung aktivieren Sie außerdem: Anwendungs- und Dienstprotokolle → Microsoft → Windows → Authentication.

Auf Domänencontrollern Einige Authentifizierungsfehler, insbesondere Kerberos-bezogene, werden nur auf dem Domänencontroller protokolliert, der die Anfrage verarbeitet hat, nicht auf der Zielmaschine. Prüfen Sie die Sicherheitsprotokolle auf Ihren DCs, wenn die lokalen Zielprotokolle kein vollständiges Bild liefern.

Sobald Sie den Substatuscode in Ereignis 4625 gefunden haben, ist der Fehler nicht mehr vage, sondern ein konkretes, diagnostizierbares Problem. Häufige Codes sind im obigen Hinweis zu Fix 4 aufgeführt.

Wenn Sie den Fehlercode 0xC07 sehen, insbesondere unter macOS mit Microsoft Remote Desktop, tritt er typischerweise zusammen mit derselben Klasse von Authentifizierungs- und Einschränkungsproblemen auf, die in diesem Artikel beschrieben werden. Berichte aus der Community deuten darauf hin, dass die Verbindung über den Hostnamen statt über die IP-Adresse das Problem in vielen Fällen behebt, was mit dem in Fix 3 beschriebenen NTLM-Fallback-Muster übereinstimmt.

Es gibt keine eindeutige Microsoft-Dokumentation, die 0xC07 klar einer einzigen Ursache zuordnet. Betrachten Sie ihn eher als Hinweis darauf, dass Sie in der richtigen Problemkategorie liegen, statt als präzise Diagnose. Die oben genannten Lösungen sind anwendbar.

Wenn der RDP-Zugriff mit der Meldung „Benutzerkontoeinschränkung“ verweigert wird, tut Windows genau das, was es tun soll, nur ohne mitzuteilen, gegen welche Regel Sie verstoßen haben.

Der schnellste Weg zur Lösung ist:

Verwenden Sie die Diagnosematrix am Anfang dieses Artikels, um die wahrscheinlichste Ursache zu ermitteln.
Wenden Sie die relevante Korrektur für Ihre Umgebung an (Heim-/Standalone oder Domäne).
Überprüfen Sie auf dem Zielrechner die Ereignis-ID 4625, falls die Ursache noch unklar ist.
Für Domänenumgebungen prüfen Sie außerdem die Protokolle des Domänencontrollers und vergewissern Sie sich, dass Kerberos funktioniert, bevor Sie Kontoeinstellungen ändern.

Meistens ist es etwas Einfaches. Und selbst wenn nicht, ist es in der Regel etwas Logisches, nur verborgen hinter einer sehr wenig hilfreichen Meldung.

So beheben Sie: Benutzerkontoeinschränkung verhindert die Anmeldung

Schnelle Diagnose

Teil 1: Heim-PC & Standalone-Maschinen

Lösung 1: Das Konto hat kein Passwort

Lösung 2: Überprüfen, wer sich über RDP verbinden darf

Lösung 3: Verbinden Sie sich nicht per IP-Adresse

Lösung 4: Prüfen Sie auf Kontosperrungen und Anmeldezeitbeschränkungen

Teil 2: Domänen- und Unternehmensumgebungen

Lösung 5: Die Gruppe Geschützte Benutzer

Lösung 6: Lesen Sie die Protokolle, wenn nichts anderes Sinn ergibt

Was ist mit Fehlercode 0xC07?

Zusammenfassung