Błąd RDP: uwierzytelnianie na poziomie sieci nie powiodło się

Wpisujesz nazwę użytkownika i hasło w oknie Podłączanie pulpitu zdalnego, klikasz Połącz, i zanim pojawi się jakikolwiek ekran logowania, dostajesz komunikat o błędzie. Żadnego pulpitu, żadnego paska postępu, nic. Właśnie to jest znak rozpoznawczy problemu z NLA: uwierzytelnianie na poziomie sieci odbywa się przed zestawieniem sesji. Jeśli się nie powiedzie, nigdy nie zobaczysz okna logowania, w którym mógłbyś cokolwiek poprawić.

Ten artykuł omawia realistyczne przyczyny w kolejności, w jakiej pojawiają się w praktyce, i pokazuje dla każdej z nich polecenie kontrolne, rozwiązanie oraz drogę powrotną, gdy RDP jest już całkiem martwe.

Komunikaty błędów w dosłownym brzmieniu

Nie ma jednego komunikatu, jest ich kilka, a dokładna treść już mocno zawęża przyczynę. Te warianty spotkasz najczęściej:

• „Komputer zdalny wymaga uwierzytelniania na poziomie sieci, którego ten komputer nie obsługuje.” Serwer wymaga NLA, a klient go nie dostarcza. Typowe przy starych klientach, przy klientach innych producentów na Linuksie lub macOS oraz przy błędnie ustawionych zasadach po stronie klienta.
• „Wystąpił błąd uwierzytelniania. Nie można skontaktować się z lokalnym urzędem zabezpieczeń.” Po angielsku: „The Local Security Authority cannot be contacted”. To klasyczny komunikat przy problemie z certyfikatem albo przy rozjechanym zegarze.
• „Wystąpił błąd uwierzytelniania. Żądana funkcja nie jest obsługiwana.” To prawie zawsze CredSSP, a nie NLA w ścisłym znaczeniu. Więcej o tym poniżej.
• „Poświadczenia użyte do nawiązania połączenia nie zadziałały.” Konto zablokowane, wyłączone, hasło wygasło albo konta brakuje w grupie Użytkownicy pulpitu zdalnego.
• „Relacja zaufania między tą stacją roboczą a domeną podstawową nie powiodła się.” Konto komputera w domenie przestało się zgadzać.

Ważne rozróżnienie: jeśli klient dopiero po dwudziestu sekundach melduje, że komputer zdalny jest nieosiągalny, to nie jest błąd NLA, tylko kwestia sieci, firewalla albo niedziałającej usługi. Błędy NLA przychodzą szybko, zwykle w ciągu jednej do trzech sekund, bo połączenie TCP przecież stoi, a zawodzi dopiero uwierzytelnianie.

Przyczyna 1: różnica czasu między klientem a serwerem

To zdecydowanie najczęstsza przyczyna i zarazem najczęściej przeoczana, bo „zegar trochę się spieszy” brzmi jak niegroźny drobiazg. Nie jest. Przy różnicy czasu natychmiast łamią się dwa mechanizmy:

• Kerberos toleruje domyślnie najwyżej pięć minut odchylenia. Powyżej tej granicy kontroler domeny odrzuca żądanie z KRB_AP_ERR_SKEW. Dotyczy wszystkich członków domeny.
• Weryfikacja TLS certyfikatu RDP kończy się niepowodzeniem, gdy zegar klienta wypada poza okres ważności certyfikatu serwera. Dotyczy to również pojedynczych serwerów bez domeny, a konkretnie wtedy, gdy serwer wstaje po restarcie z zegarem cofniętym w przeszłość i świeżo wygenerowany certyfikat z punktu widzenia klienta jeszcze w ogóle nie obowiązuje.

Sprawdzenie na serwerze, w PowerShellu z uprawnieniami administratora:

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

Stripchart podaje odchylenie w sekundach. Wszystko poniżej sekundy jest w porządku, wszystko powyżej 60 sekund jest podejrzane, a wszystko powyżej 300 sekund tłumaczy błąd.

Tutaj drogi obu rodzajów systemów się rozchodzą, a większość poradników wrzuca je do jednego worka:

• Pojedynczy serwer bez domeny: ustaw zewnętrzne źródło NTP.
• Serwer członkowski domeny: pod żadnym pozorem nie ustawiaj własnej listy serwerów. Serwer członkowski musi pobierać czas z hierarchii domeny, inaczej rozjedzie się względem kontrolera domeny.

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

w32tm /config /syncfromflags:domhier /update

Potem w obu przypadkach zrestartuj usługę i zsynchronizuj czas:

net stop w32time
net start w32time
w32tm /resync /rediscover

Osobliwość, która dopada cię na serwerach wirtualnych: jeśli zegar myli się dokładnie o godzinę albo o dwie, to nie jest dryf, tylko problem z interpretacją zegara sprzętowego. Windows oczekuje RTC w czasie lokalnym, a wiele platform wirtualizacyjnych udostępnia go w UTC. Sprawdź najpierw strefę czasową, a potem w razie potrzeby zmień samą interpretację:

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

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

Przyczyna 2: wygasły albo źle powiązany certyfikat

Bez własnego PKI Windows tworzy dla RDP certyfikat samopodpisany, ważny mniej więcej pół roku i normalnie odnawiający się sam. „Normalnie” jest tu słowem kluczowym. Jeśli odnowienie rozbije się o uprawnienia w magazynie kluczy albo jeśli wygaśnie ręcznie powiązany certyfikat z wewnętrznego CA, nie zalogujesz się już i zobaczysz komunikat o lokalnym urzędzie zabezpieczeń.

Sprawdzenie zawartości magazynu:

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

A zaraz potem, którego certyfikatu faktycznie używa nasłuch:

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

Porównaj zwrócony skrót z odciskami palca z pierwszego polecenia. Możliwe są dwa obrazy błędu: skrót wskazuje na wygasły certyfikat albo wskazuje na certyfikat, którego w magazynie już w ogóle nie ma.

Naprawa polega na usunięciu powiązania i skasowaniu starego certyfikatu. Windows utworzy potem nowy przy starcie usługi:

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

Dwa ostrzeżenia. Po pierwsze, restart TermService zrywa wszystkie istniejące sesje RDP, także twoją, gdybyś jednak jakimś cudem był w środku. Wykonaj to z konsoli. Po drugie: jeśli zasady grupy narzucają szablon certyfikatu do uwierzytelniania serwera, serwer pobiera certyfikat z wewnętrznego CA. Gdy CA jest nieosiągalne albo szablon wygasł, nowy certyfikat nie powstanie i błąd zostanie. Sprawdź wtedy najpierw CA, a nie serwer.

Kontrola skuteczności: pierwsze polecenie zwraca teraz certyfikat z datą NotAfter w przyszłości, a SSLCertificateSHA1Hash wskazuje dokładnie na niego.

Przyczyna 3: konto zablokowane, wyłączone albo hasło wygasło

Tu kryje się pułapka, która odróżnia NLA od wszystkich innych problemów z logowaniem: przy aktywnym NLA nie zmienisz wygasłego hasła przez klienta RDP. Okno „Twoje hasło wygasło i musi zostać zmienione” pojawia się dopiero w sesji, a do sesji bez zdanego uwierzytelniania nie dotrzesz. Klient melduje zamiast tego tylko tyle, że poświadczenia nie zadziałały. Hasło jest całkowicie poprawne, tyle że wygasło.

Podgląd stanu konta lokalnego:

net user Administrator

Zwróć uwagę na wiersze „Konto aktywne”, „Konto wygasa”, „Hasło wygasa” i „Hasło może być zmienione”. Odpowiednie środki zaradcze:

net user Administrator "NoweDlugieHaslo!2026"

Enable-LocalUser -Name "Administrator"

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

Konto lokalne zablokowane po zbyt wielu nieudanych próbach to osobny stan, którego nie zdejmie ani Enable-LocalUser, ani zmiana hasła. Odblokowuje się samo po upływie czasu blokady, a ten sprawdzisz tak:

net accounts

Natychmiastowe odblokowanie bez graficznych narzędzi zarządzania załatwia ADSI:

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

Jeśli porty RDP są osiągalne z internetu, blokady zdarzają się praktycznie codziennie, bo boty nieustannie testują hasła do twojego konta administratora. To mocny argument za tym, żeby ograniczyć dostęp, zamiast w kółko odblokowywać konto. Inny port zauważalnie pomaga przeciwko masowym skanom, zobacz zmiana portu RDP bez restartu.

Na koniec przynależność do grupy. Nazwa grupy zależy od języka systemu, co chętnie rozsypuje skrypty. Niezależnie od języka odpytasz ją po znanym identyfikatorze SID:

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

Przyczyna 4: NLA wyłączone albo wyłączone tylko połowicznie

O zachowaniu decydują dwa osobne przełączniki i to właśnie ich kombinacja robi kłopoty. UserAuthentication steruje NLA, a SecurityLayer zabezpieczeniem transportu, z wartościami 0 dla starej warstwy zabezpieczeń RDP, 1 dla negocjacji i 2 dla wymuszonego 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

Typowa ślepa uliczka: ktoś wyłącza NLA, bo podejrzewa problem z certyfikatem, ale zostawia SecurityLayer na 2. Negocjacja TLS z zepsutym certyfikatem zostaje więc w mocy, a błąd zmienia tylko brzmienie. Jeśli do diagnostyki naprawdę chcesz obniżyć jedno i drugie, obniż jedno i drugie, a potem przywróć poprzedni stan.

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

Druga ślepa uliczka jest jeszcze bardziej dokuczliwa: ustawiasz wartość w rejestrze, restartujesz serwer, a ona znowu stoi na 1. Wtedy pochodzi z zasad grupy. Wartości z zasad leżą w innym miejscu i zawsze wygrywają:

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

gpresult /r /scope:computer

Dopóki stoi tam jakaś wartość, każda lokalna zmiana obowiązuje tylko do następnego zastosowania zasad. Zasada nazywa się „Wymagaj uwierzytelniania użytkownika do dostępu zdalnego przy użyciu uwierzytelniania na poziomie sieci” i trzeba ją zmienić na kontrolerze domeny.

I najważniejsza reguła na koniec tej sekcji: trwałe wyłączenie NLA nie jest rozwiązaniem, tylko otwartymi drzwiami. Bez NLA każdy, kto dosięgnie portu, może wywołać ekran logowania, a więc niezabezpieczoną część stosu sesji. Wyłącz je na czas diagnozy i zaraz potem włącz z powrotem.

Przyczyna 5: zerwana relacja zaufania z domeną

Każde konto komputera w domenie ma własne hasło, zmieniane domyślnie automatycznie co 30 dni. Gdy stany po stronie serwera i kontrolera domeny przestają do siebie pasować, serwer nie potrafi już uwierzytelnić żadnego konta domenowego i NLA zawodzi dla wszystkich użytkowników domeny, podczas gdy konta lokalne działają dalej. Dokładnie ten wzorzec jest dowodem na tę przyczynę.

Klasyczny powód w eksploatacji serwerów to przywrócenie starszego stanu, na przykład z kopii zapasowej albo ze snapshotu starszego niż ostatnia zmiana hasła. Sprawdzenie:

Test-ComputerSecureChannel -Verbose

nltest /sc_verify:mojadomena.local

Naprawa, zalogowany jako administrator lokalny przez konsolę:

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

Reset-ComputerMachinePassword -Credential (Get-Credential)

Wypisywanie serwera z domeny i ponowne dołączanie nie jest do tego potrzebne, a często pogarsza sprawę, bo przy okazji można stracić przynależność do grup i uprawnienia starego konta komputera. Po naprawie wystarczy restart usługi Netlogon:

Restart-Service Netlogon

Gdy RDP w ogóle już nie działa: droga przez konsolę

Wszystkie dotychczasowe polecenia zakładają, że jakoś dostajesz się na serwer. Właśnie tego w sytuacji awaryjnej brakuje. Na serwerach root KVM od KernelHost masz dlatego w panelu klienta konsolę VNC, która działa niezależnie od RDP, od firewalla Windows, a nawet od stosu sieciowego systemu gościa. To awaryjne wejście, którym sam wydostaniesz się z każdej z opisanych wyżej sytuacji. Na serwerach dedykowanych dostęp awaryjny prowadzi przez wsparcie.

Trzy rzeczy, które na konsoli VNC wyglądają inaczej niż w sesji RDP i regularnie kosztują czas:

• Układ klawiatury. Konsola często podaje układ US, podczas gdy Windows stoi na polskim, albo odwrotnie. Znaki specjalne w hasłach lądują wtedy nie tam, gdzie trzeba, a ty uznajesz poprawne hasło za błędne. W razie wątpliwości użyj klawiatury ekranowej poleceniem osk.exe prosto z ekranu logowania.
• Schowek. Kopiowanie z własnego komputera do konsoli zwykle nie działa. Licz się z przepisywaniem ręcznym i dobieraj hasła tymczasowe pod tym kątem.
• Logowanie na konto lokalne. Przy problemach z domeną logujesz się jako .\Administrator, kropka i backslash wymuszają konto lokalne zamiast domenowego.

Na konsoli sprawdzasz potem podstawy, zanim zaczniesz grzebać przy NLA:

sc query TermService

netstat -ano | findstr :3389

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

Jeśli fDenyTSConnections stoi na 1, połączenia zdalne są całkowicie wyłączone, niezależnie od NLA:

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

Reguły firewalla włączasz niezależnie od języka przez wewnętrzny identyfikator grupy, bo wyświetlana nazwa grupy brzmi inaczej w każdej wersji językowej systemu:

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

Szczególny przypadek CredSSP, często mylony z NLA

Jeśli komunikat brzmi dosłownie „Żądana funkcja nie jest obsługiwana” i wymienia korektę wyroczni szyfrowania CredSSP, to żadna z pięciu przyczyn powyżej nie jest winna. Tutaj nie pasują do siebie poziomy poprawek klienta i serwera: jedna strona wymaga utwardzonego wariantu CredSSP, a druga jeszcze go nie zna.

Jedynym czystym rozwiązaniem jest zaktualizowanie obu stron. Krążąca po sieci zmiana w rejestrze z AllowEncryptionOracle po stronie klienta wyłącza dokładnie to utwardzenie, które wywołuje błąd, i otwiera z powrotem znaną drogę ataku. Jeśli potrzebujesz jej na chwilę, żeby wgrać aktualizacje, cofnij ją, gdy tylko serwer będzie aktualny.

Po czym poznasz, że naprawdę jest naprawione

Udane połączenie jest najsłabszym dowodem, bo uda się także wtedy, gdy wyłączyłeś NLA na czas diagnozy. Sprawdź zamiast tego po kolei:

1. NLA jest znowu aktywne. UserAuthentication stoi na 1, a SecurityLayer na 2.
2. Zegar się zgadza. Odchylenie ze stripchartu jest mniejsze niż sekunda, a w32tm /query /source wskazuje prawdziwe źródło, nie „Local CMOS Clock” i nie „Free-running System Clock”.
3. Certyfikat jest ważny. NotAfter leży w przyszłości, a powiązany skrót wskazuje dokładnie na ten certyfikat.
4. Dziennik zdarzeń potwierdza zdane uwierzytelnianie sieciowe. Zdarzenie 1149 pojawia się dopiero po przejściu NLA, jest więc właściwym dowodem.

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

Przy kontrolnym sprawdzaniu nieudanych prób kody stanu w zdarzeniu 4625 mówią więcej niż jakikolwiek komunikat klienta: 0xC0000071 oznacza wygasłe hasło, 0xC0000072 konto wyłączone, 0xC0000234 konto zablokowane, a 0xC000006A rzeczywiście błędne hasło.

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

Na koniec same sesje, najlepiej prosto z konsoli:

qwinsta

Krótka ściąga do szukania przyczyny

Jeśli stawiasz serwer Windows od nowa, warto od razu na starcie poprawnie ustawić źródło czasu, zasady kont i drogę dostępu, zamiast naprawiać je później pod presją. Jako punkt odniesienia nadaje się lista kontrolna dla nowego serwera root, a kto chce dodatkowo zabezpieczyć dostęp RDP, znajdzie w artykule zmiana portu RDP bez restartu najmniej pracochłonny pierwszy krok przeciwko automatycznym próbom logowania.