RDP-Fehler: Authentifizierung auf Netzwerkebene fehlgeschlagen

Du tippst Benutzername und Passwort in die Remotedesktopverbindung, klickst auf Verbinden, und bevor irgendein Anmeldebildschirm erscheint, kommt eine Fehlermeldung. Kein Desktop, kein Ladebalken, nichts. Genau das ist das Kennzeichen eines NLA-Problems: Die Authentifizierung auf Netzwerkebene läuft vor dem Aufbau der Sitzung ab. Schlägt sie fehl, bekommst du nie eine Anmeldemaske zu sehen, in der du etwas korrigieren könntest.

Dieser Artikel geht die realistischen Ursachen in der Reihenfolge durch, in der sie in der Praxis auftreten, und zeigt für jede den Prüfbefehl, die Lösung und den Weg zurück, wenn RDP komplett tot ist.

Die Fehlermeldungen im Wortlaut

Es gibt nicht eine Meldung, sondern eine Handvoll, und der genaue Text grenzt die Ursache bereits stark ein. Diese Varianten begegnen dir am häufigsten:

• "Der Remotecomputer erfordert eine Authentifizierung auf Netzwerkebene, die von Ihrem Computer nicht unterstützt wird." Der Server verlangt NLA, der Client liefert es nicht. Typisch bei alten Clients, bei Drittanbieter-Clients unter Linux oder macOS und bei falsch gesetzten Client-Richtlinien.
• "Es ist ein Authentifizierungsfehler aufgetreten. Die lokale Sicherheitsinstanz kann nicht kontaktiert werden." Im Englischen: "The Local Security Authority cannot be contacted". Das ist die klassische Zertifikats- oder Zeitversatz-Meldung.
• "Es ist ein Authentifizierungsfehler aufgetreten. Die angeforderte Funktion wird nicht unterstützt." Das ist fast immer CredSSP, nicht NLA im engeren Sinn. Dazu unten mehr.
• "Die Anmeldeinformationen, die zum Herstellen der Verbindung verwendet wurden, funktionieren nicht." Konto gesperrt, deaktiviert, Passwort abgelaufen oder Konto fehlt in der Gruppe der Remotedesktopbenutzer.
• "Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden." Das Computerkonto in der Domäne passt nicht mehr.

Wichtig zur Abgrenzung: Wenn der Client nach zwanzig Sekunden meldet, der Remotecomputer sei nicht erreichbar, ist das kein NLA-Fehler, sondern Netzwerk, Firewall oder ein nicht laufender Dienst. NLA-Fehler kommen schnell, meist in ein bis drei Sekunden, weil die TCP-Verbindung ja steht und erst die Authentifizierung scheitert.

Ursache 1: Zeitversatz zwischen Client und Server

Das ist die mit Abstand häufigste Ursache, und sie wird am häufigsten übersehen, weil "die Uhr geht ein bisschen falsch" nach einem harmlosen Problem klingt. Ist es nicht. Zwei Mechanismen brechen bei Zeitversatz sofort:

• Kerberos toleriert standardmäßig maximal fünf Minuten Abweichung. Darüber lehnt der Domänencontroller die Anfrage mit KRB_AP_ERR_SKEW ab. Betrifft alle Domänenmitglieder.
• Die TLS-Prüfung des RDP-Zertifikats schlägt fehl, wenn die Uhr des Clients außerhalb der Gültigkeit des Serverzertifikats liegt. Das betrifft auch Einzelserver ohne Domäne, und zwar genau dann, wenn der Server nach einem Neustart mit einer Uhr in der Vergangenheit hochkommt und ein frisch erzeugtes Zertifikat aus Sicht des Clients noch gar nicht gültig ist.

Prüfen auf dem Server, in einer PowerShell mit Administratorrechten:

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

Der Stripchart gibt dir den Offset in Sekunden. Alles unter einer Sekunde ist gut, alles über 60 Sekunden ist verdächtig, alles über 300 Sekunden erklärt den Fehler.

Hier trennen sich die Systeme, und die meisten Anleitungen werfen beides in einen Topf:

• Einzelserver ohne Domäne: externe NTP-Quelle setzen.
• Domänenmitglied: auf keinen Fall eine eigene Peer-Liste setzen. Ein Mitgliedsserver muss seine Zeit aus der Domänenhierarchie beziehen, sonst driftet er gegen den Domänencontroller.

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

w32tm /config /syncfromflags:domhier /update

Danach in beiden Fällen den Dienst neu starten und synchronisieren:

net stop w32time
net start w32time
w32tm /resync /rediscover

Eine Besonderheit, die dich auf virtualisierten Servern erwischt: Zeigt die Uhr exakt ein oder zwei Stunden falsch, ist das kein Drift, sondern ein Interpretationsproblem der Hardware-Uhr. Windows erwartet die RTC in Ortszeit, viele Virtualisierungsplattformen stellen sie in UTC bereit. Prüfe zuerst die Zeitzone und stelle dann gegebenenfalls die Interpretation um:

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

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

Ursache 2: Abgelaufenes oder falsch gebundenes Zertifikat

Ohne eigene PKI erzeugt Windows für RDP ein selbstsigniertes Zertifikat, das etwa ein halbes Jahr gültig ist und sich normalerweise selbst erneuert. "Normalerweise" ist hier das operative Wort. Wenn die Erneuerung an Berechtigungen im Schlüsselspeicher scheitert oder wenn ein manuell gebundenes Zertifikat aus einer internen CA abläuft, kannst du dich nicht mehr anmelden und siehst die Meldung mit der lokalen Sicherheitsinstanz.

Bestand prüfen:

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

Und danach, welches Zertifikat der Listener tatsächlich benutzt:

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

Vergleiche den zurückgegebenen Hash mit den Thumbprints aus dem ersten Befehl. Zwei Fehlerbilder sind möglich: Der Hash zeigt auf ein abgelaufenes Zertifikat, oder er zeigt auf ein Zertifikat, das gar nicht mehr im Speicher liegt.

Die Reparatur besteht darin, die Bindung zu lösen und das alte Zertifikat zu entfernen. Windows erzeugt danach beim Dienststart ein neues:

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

Zwei Warnungen dazu. Erstens wirft der Neustart von TermService alle bestehenden RDP-Sitzungen ab, auch deine eigene, falls du doch noch irgendwie drin bist. Führe das über die Konsole aus. Zweitens: Wenn eine Gruppenrichtlinie eine Zertifikatvorlage für die Serverauthentifizierung vorgibt, holt sich der Server sein Zertifikat von der internen CA. Ist die CA nicht erreichbar oder die Vorlage abgelaufen, kommt kein neues Zertifikat und der Fehler bleibt. Prüfe dann zuerst die CA, nicht den Server.

Erfolgskontrolle: Der erste Befehl liefert jetzt ein Zertifikat mit einem NotAfter-Datum in der Zukunft, und der SSLCertificateSHA1Hash zeigt auf genau dieses.

Ursache 3: Konto gesperrt, deaktiviert oder Passwort abgelaufen

Hier steckt die Falle, die NLA von allen anderen Anmeldeproblemen unterscheidet: Bei aktivem NLA kannst du ein abgelaufenes Passwort nicht über den RDP-Client ändern. Der Dialog "Ihr Kennwort ist abgelaufen und muss geändert werden" erscheint erst in der Sitzung, und zur Sitzung kommst du ohne bestandene Authentifizierung nicht. Der Client meldet stattdessen nur, die Anmeldeinformationen funktionierten nicht. Das Passwort ist völlig korrekt, es ist nur abgelaufen.

Status eines lokalen Kontos ansehen:

net user Administrator

Achte auf die Zeilen "Konto aktiv", "Konto läuft ab", "Kennwort läuft ab" und "Kennwort ablaufbar". Die passenden Gegenmaßnahmen:

net user Administrator "NeuesLangesPasswort!2026"

Enable-LocalUser -Name "Administrator"

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

Ein gesperrtes lokales Konto nach zu vielen Fehlversuchen ist ein eigener Zustand, der weder von Enable-LocalUser noch von einer Passwortänderung aufgehoben wird. Es entsperrt sich nach Ablauf der Sperrdauer selbst, die du dir so ansiehst:

net accounts

Sofort entsperren geht ohne grafische Verwaltung über ADSI:

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

Wenn RDP-Ports aus dem Internet erreichbar sind, kommen Sperrungen praktisch täglich vor, weil Bots dein Administratorkonto durchprobieren. Das ist ein starkes Argument dafür, den Zugang einzuschränken, statt nur das Konto immer wieder zu entsperren. Ein anderer Port hilft gegen Massenscans spürbar, siehe RDP-Port ohne Neustart ändern.

Zuletzt die Gruppenmitgliedschaft. Der Gruppenname ist lokalisiert, was Skripte gerne zerlegt. Sprachunabhängig fragst du über die bekannte SID ab:

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

Ursache 4: NLA am Server deaktiviert oder halb deaktiviert

Zwei getrennte Schalter bestimmen das Verhalten, und genau ihre Kombination macht den Ärger. UserAuthentication steuert NLA, SecurityLayer die Transportsicherung mit den Werten 0 für die alte RDP-Sicherungsschicht, 1 für Aushandeln und 2 für erzwungenes 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

Die typische Sackgasse: Jemand schaltet NLA ab, weil ein Zertifikatsproblem vermutet wird, lässt aber SecurityLayer auf 2 stehen. Damit bleibt die TLS-Aushandlung mit dem kaputten Zertifikat bestehen, und der Fehler ändert sich nur im Wortlaut. Wenn du zum Diagnostizieren wirklich beides senken willst, senke beides, und stelle es danach wieder her.

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

Die zweite Sackgasse ist noch unangenehmer: Du setzt den Registrierungswert, startest neu, und er steht wieder auf 1. Dann kommt er aus einer Gruppenrichtlinie. Richtlinienwerte liegen an einer anderen Stelle und gewinnen immer:

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

gpresult /r /scope:computer

Solange dort ein Wert steht, ist jede lokale Änderung nur bis zur nächsten Richtlinienanwendung gültig. Die Richtlinie heißt "Benutzerauthentifizierung mit Authentifizierung auf Netzwerkebene für Remoteverbindungen anfordern" und muss auf dem Domänencontroller angefasst werden.

Und die wichtigste Regel zum Schluss dieses Abschnitts: NLA dauerhaft abzuschalten ist keine Lösung, sondern eine offene Tür. Ohne NLA kann jeder, der den Port erreicht, den Anmeldebildschirm und damit einen ungeschützten Teil des Sitzungsstacks ansprechen. Schalte es zur Diagnose ab und danach wieder ein.

Ursache 5: Gebrochene Domänenvertrauensstellung

Jedes Computerkonto in einer Domäne hat ein eigenes Passwort, das standardmäßig alle 30 Tage automatisch gewechselt wird. Passen die Stände von Server und Domänencontroller nicht mehr zusammen, kann der Server keine Domänenkonten mehr authentifizieren, und NLA scheitert für alle Domänenbenutzer, während lokale Konten weiter funktionieren. Genau dieses Muster ist der Beweis für diese Ursache.

Der klassische Auslöser im Serverbetrieb ist ein Rücksetzen auf einen älteren Zustand, etwa aus einem Backup oder Snapshot, der älter als der letzte Passwortwechsel ist. Prüfen:

Test-ComputerSecureChannel -Verbose

nltest /sc_verify:meinedomaene.local

Reparieren, angemeldet als lokaler Administrator über die Konsole:

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

Reset-ComputerMachinePassword -Credential (Get-Credential)

Ein Herauslösen aus der Domäne und Neubeitritt ist dafür nicht nötig und macht die Sache oft schlimmer, weil dabei Gruppenmitgliedschaften und Berechtigungen des alten Computerkontos verloren gehen können. Nach der Reparatur reicht ein Neustart des Netlogon-Dienstes:

Restart-Service Netlogon

Wenn RDP gar nicht mehr geht: der Weg über die Konsole

Alle bisherigen Befehle setzen voraus, dass du irgendwie auf den Server kommst. Genau das ist im Ernstfall nicht der Fall. Bei den KVM-Rootservern von KernelHost erreichst du deshalb im Kundenbereich eine VNC-Konsole, die unabhängig von RDP, von der Windows-Firewall und sogar vom Netzwerkstack des Gastsystems funktioniert. Das ist der Notzugang, mit dem du dich aus jeder der oben beschriebenen Situationen selbst befreist. Bei Dedicated Servern läuft der Notzugang über den Support.

Drei Dinge, die auf der VNC-Konsole anders sind als in einer RDP-Sitzung und die regelmäßig Zeit kosten:

• Tastaturlayout. Die Konsole liefert oft ein US-Layout, während Windows auf Deutsch steht oder umgekehrt. Sonderzeichen in Passwörtern landen dann falsch, und du hältst ein korrektes Passwort für falsch. Nutze im Zweifel die Bildschirmtastatur mit osk.exe aus dem Anmeldebildschirm heraus.
• Zwischenablage. Kopieren vom eigenen Rechner in die Konsole funktioniert meist nicht. Rechne mit Abtippen und wähle temporäre Passwörter entsprechend.
• Anmeldung als lokales Konto. Bei Domänenproblemen meldest du dich mit .\Administrator an, der Punkt und der Backslash erzwingen das lokale Konto statt des Domänenkontos.

Auf der Konsole prüfst du dann die Grundlagen, bevor du an NLA schraubst:

sc query TermService

netstat -ano | findstr :3389

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

Steht fDenyTSConnections auf 1, sind Remoteverbindungen komplett abgeschaltet, unabhängig von NLA:

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

Die Firewallregeln aktivierst du sprachunabhängig über die interne Gruppenkennung, weil der angezeigte Gruppenname je nach Systemsprache anders lautet:

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

Der Sonderfall CredSSP, der oft verwechselt wird

Lautet die Meldung wörtlich "Die angeforderte Funktion wird nicht unterstützt" und nennt sie die CredSSP-Verschlüsselungsoraclekorrektur, dann ist keine der fünf Ursachen oben schuld. Hier passen die Patchstände von Client und Server nicht zusammen: Eine Seite verlangt die gehärtete CredSSP-Variante, die andere kennt sie noch nicht.

Die einzig saubere Lösung ist, beide Seiten zu aktualisieren. Die im Netz kursierende Registrierungsänderung mit AllowEncryptionOracle auf dem Client hebelt genau die Härtung aus, die den Fehler verursacht, und öffnet damit wieder einen bekannten Angriffsweg. Falls du sie zum Einspielen der Updates kurzfristig brauchst, setze sie zurück, sobald der Server aktuell ist.

Woran du erkennst, dass es wirklich behoben ist

Eine erfolgreiche Verbindung ist der schwächste Beweis, weil sie auch dann klappt, wenn du NLA zur Diagnose abgeschaltet hast. Prüfe stattdessen der Reihe nach:

1. NLA ist wieder aktiv. UserAuthentication steht auf 1 und SecurityLayer auf 2.
2. Die Uhr stimmt. Der Offset aus dem Stripchart liegt unter einer Sekunde, und w32tm /query /source nennt eine echte Quelle, nicht "Local CMOS Clock" und nicht "Free-running System Clock".
3. Das Zertifikat ist gültig. NotAfter liegt in der Zukunft, und der gebundene Hash zeigt auf genau dieses Zertifikat.
4. Das Ereignisprotokoll bestätigt die bestandene Netzwerkauthentifizierung. Ereignis 1149 erscheint erst, wenn NLA durchlaufen wurde, es ist damit der eigentliche Nachweis.

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

Für die Gegenprobe bei Fehlversuchen sind die Statuscodes im Ereignis 4625 aussagekräftiger als jede Clientmeldung: 0xC0000071 steht für ein abgelaufenes Passwort, 0xC0000072 für ein deaktiviertes Konto, 0xC0000234 für ein gesperrtes Konto und 0xC000006A für ein tatsächlich falsches Passwort.

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

Abschließend die Sitzungen selbst, gerne aus der Konsole heraus:

qwinsta

Kurzer Abgleich für die Fehlersuche

Wenn du einen Windows-Server neu aufsetzt, lohnt es sich, Zeitquelle, Kontorichtlinien und den Zugriffsweg gleich zu Beginn richtig zu setzen, statt sie später unter Druck zu reparieren. Als Orientierung dafür eignet sich die Checkliste für den neuen Rootserver, und wer den RDP-Zugang zusätzlich absichern will, findet in RDP-Port ohne Neustart ändern den unaufwendigsten ersten Schritt gegen automatisierte Anmeldeversuche.