NLA pogreške u RDP-u: uzroci, rješenja i najbolje prakse

Uvod

Autentifikacija na razini mreže (NLA) je osnovna sigurnosna kontrola za protokol daljinske radne površine, koja sprječava neautorizirane korisnike prije nego što se stvori puna sesija. Kada NLA ne uspije, IT timovi se suočavaju s blokiranim prijavama, nejasnim porukama o pogreškama i frustriranim krajnjim korisnicima koji ne mogu doći do kritičnih poslužitelja. Ovaj vodič objašnjava što je NLA, zašto se te pogreške javljaju i kako sustavno dijagnosticirati i riješiti NLA probleme bez slabljenja vaše RDP sigurnosne pozicije.

Što je NLA u RDP-u?

Autentifikacija na razini mreže je poboljšanje sigurnosti RDP-a uvedeno s Windows Vistom i Windows Serverom 2008. Umjesto da se izgradi cijela sesija udaljenog radnog površine i zatim traže vjerodajnice, NLA zahtijeva da se korisnici prvo autentificiraju. Tek nakon uspješne autentifikacije RDP stog stvara grafičku sesiju.

NLA se oslanja na CredSSP (Pružatelj podrške za sigurnost vjerodajnica) kako bi sigurno prenio korisničke vjerodajnice na ciljni sustav. U okruženjima povezanima s domenom, CredSSP komunicira s Active Directoryjem kako bi provjerio račun prije uspostavljanja sesije. Na samostalnim ili radnim grupama, CredSSP provjerava lokalne račune konfigurirane za daljinsko prijavljivanje.

Ključne prednosti NLA uključuju:

• Smanjenje prozora za napade silom i napade uskraćivanja usluge na izloženim RDP krajnjim točkama
• Omogućavanje jedinstveno prijavljivanje (SSO) za korisnike domene, poboljšavajući korisničko iskustvo
• Poboljšanje performansi provodeći autentifikaciju prije stvaranja sesije

Međutim, NLA je osjetljiv na verzije OS-a, zakrpe, TLS konfiguracija i zdravlje domene. Kada bilo koja od tih preduvjeta ne uspije, NLA može potpuno blokirati valjane veze.

Koji su uobičajeni simptomi NLA grešaka u RDP-u?

Problemi povezani s NLA obično se javljaju sličnim porukama, bez obzira na osnovni uzrok. Vjerojatno se suočavate s NLA problemom ako naiđete na:

• “Udaljeno računalo zahtijeva autentifikaciju na razini mreže (NLA), ali vaše računalo to ne podržava.”
• Došlo je do pogreške pri autentifikaciji. Zatražena funkcija nije podržana.
• “Greška u otklanjanju oracle enkripcije CredSSP.”
• Vaše vjerodajnice nisu radile.
• Istezanje ili nagli prekidi tijekom inicijalne RDP rukovanja ili odmah nakon unosa vjerodajnica

Ovi simptomi mogu utjecati na domaćine povezane s domenom i samostalne domaćine. U praksi, često se vraćaju na neusklađene sigurnosne politike, blokirani pristup kontroleru domene ili zastarjele RDP komponente s bilo koje strane.

Koji su uzroci NLA pogrešaka u RDP-u?

Razumijevanje uobičajenih uzroka pomaže vam da brzo riješite probleme i izbjegnete rizična rješenja poput trajnog onemogućavanja NLA.

• Neusklađenost klijenta ili poslužitelja OS
• Kontroler domene nedostupan
• CredSSP zakrpa neslaganja
• TLS ili RDP enkripcija pogrešne konfiguracije
• Sukobi grupe pravila ili registra
• Oštećeni korisnički profili ili vjerodajnice
• Radna grupa i scenariji izvan domene

Neusklađenost klijenta ili poslužitelja OS

Starije verzije sustava Windows ili klijenti trećih strana za RDP možda neće u potpunosti podržavati NLA ili moderno ponašanje CredSSP-a. Na primjer, naslijeđene verzije sustava Windows XP ili rane verzije Viste ne mogu se povezati na poslužitelje koji zahtijevaju NLA bez specifičnih ažuriranja. Čak i na podržanim sustavima, zastarjeli binarni klijenti RDP-a mogu uzrokovati pogreške "vaš računalnik ne podržava NLA" unatoč tome što ga OS nominalno podržava.

Kontroler domene nedostupan

U okruženju pridruženom domeni, NLA ovisi o pristupu kontroleru domene za provjeru vjerodajnica i održavanje sigurnog kanala stroja. Ako je kontroler domene izvan mreže, blokiran od strane a vatrozid ili postoji problem s povjerenjem, NLA autentifikacija može ne uspjeti iako je sam poslužitelj aktivan. Često ćete vidjeti pogreške koje spominju povezanost s kontrolerom domene ili generičke poruke "došlo je do pogreške u autentifikaciji".

CredSSP zakrpa neslaganja

Počevši s ažuriranjima "Encryption Oracle Remediation" iz 2018. godine, CredSSP postao je stroži u pogledu zaštite vjerodajnica. Ako klijent ima ažuriranje, ali poslužitelj ne (ili obrnuto), dva krajnja uređaja možda se neće složiti oko sigurne konfiguracije. Ova nesukladnost može generirati pogreške "CredSSP encryption oracle remediation" i spriječiti NLA prijave dok obje strane ne budu ispravljene ili dok se ne prilagodi Grupa pravila.

TLS ili RDP enkripcija pogrešne konfiguracije

NLA se oslanja na sigurnost transportnog sloja (TLS) za zaštitu razmjene vjerodajnica. Ako je TLS 1.0/1.1 onemogućen bez ispravnog omogućavanja TLS 1.2, ili ako su prisiljeni slabi kriptografski skupovi, uspostavljanje veze između klijenta i poslužitelja može propasti prije nego što NLA završi. Prilagođeno osnaživanje sigurnosti, FIPS način rada ili pogrešno konfigurirani certifikati mogu sve prekinuti NLA, iako standardni RDP bez NLA možda još uvijek radi pod nekim uvjetima.

Sukobi grupe pravila ili registra

Objekti grupne politike (GPO) i lokalne sigurnosne politike kontroliraju kako RDP, CredSSP i enkripcija funkcioniraju. Sukobljene ili previše stroge politike mogu nametnuti NLA u scenarijima gdje klijenti to ne podržavaju ili zahtijevaju FIPS-usklađene algoritme koje vaši klijenti ne mogu koristiti. Registrijske preinake za SCHANNEL ili CredSSP mogu uvesti slične nedosljednosti, što rezultira porukama "zahtijevana funkcija nije podržana" i drugim generičkim pogreškama.

Oštećeni korisnički profili ili vjerodajnice

Ponekad je problem ograničen na jednog korisnika ili stroj. Oštećene predmemorirane vjerodajnice, nepravilno usklađene Identifikator sigurnosti (SID), ili oštećena Default.rdp datoteka mogu ometati NLA autentifikaciju. U tim slučajevima, možete primijetiti da se drugi korisnik može prijaviti s istog uređaja, ili se isti korisnik može prijaviti s drugog klijenta, ali ne oboje zajedno.

Radna grupa i scenariji izvan domene

NLA pretpostavlja okruženje u kojem se identiteti korisnika mogu snažno autentificirati, obično putem Active Directory. U radnim grupama, lokalni računi moraju biti pažljivo konfigurirani i moraju imati dopuštenje za prijavu putem Remote Desktop. Ako je NLA primijenjen, ali nije dostupan kontroler domene, ili su postavke lokalnog računa netočne, vjerojatno ćete vidjeti pogreške povezane s NLA-om, iako se čini da je poslužitelj dostupan.

Kako popraviti NLA greške u RDP-u?

Koristite sljedeće korake redom, od najmanje invazivnog do najintruzivnijeg. Ovaj pristup pomaže u vraćanju pristupa uz očuvanje sigurnosti gdje god je to moguće.

• Potvrdite NLA podršku na klijentu i poslužitelju
• Provjerite povezanost s kontrolerom domene (ako je primjenjivo)
• Uskladite razine i politike CredSSP zakrpa
• Omogućite i potvrdite potrebne TLS protokole
• Pregledaj i prilagodi grupnu politiku
• Privremeno onemogućite NLA za oporavak pristupa
• Resetiranje RDP klijenta i mrežne konfiguracije

Potvrdite NLA podršku na klijentu i poslužitelju

Prvo, provjerite jesu li oba krajnja uređaja sposobna za NLA.

• Pokreni winver na klijentu i poslužitelju kako bi se potvrdilo da su Windows Vista / Windows Server 2008 ili noviji.
• Osigurajte da su instalirane najnovije nadogradnje klijenta za Remote Desktop (putem Windows Update ili aplikacije Microsoft Remote Desktop na ne-Windows platformama).
• Ako koristite klijente trećih strana za RDP, provjerite da je podrška za NLA izričito dokumentirana i omogućena u postavkama klijenta.

Ako nijedna strana ne podržava NLA, planirajte nadogradnju ili zamjenu te komponente umjesto slabljenja sigurnosti globalno.

Provjerite povezanost s kontrolerom domene (ako je primjenjivo)

Na računalima pridruženim domeni, provjerite povezanost s domenom prije promjene RDP postavki.

• Testirajte osnovnu mrežnu dostupnost do kontrolera domene (na primjer, ping dc01.yourdomain.com ).
• Koristite nltest /dsgetdc:yourdomain.com da potvrdi da klijent može locirati kontroler domene.
• U PowerShellu, pokrenite Test-ComputerSecureChannel da provjeri sigurni kanal uređaja prema domeni.

Ako je siguran kanal prekinut, popravite ga s:

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

Nakon popravka, ponovno pokrenite uređaj ako se to zatraži, a zatim ponovno testirajte NLA. Riješite DNS pogrešne konfiguracije, pravila vatrozida ili VPN probleme koji bi mogli povremeno blokirati pristup domeni.

Uskladite razine i politike CredSSP zakrpa

Sljedeće, potvrdite da i klijent i poslužitelj imaju aktualne sigurnosne nadogradnje, posebno one koje se odnose na CredSSP.

• Instalirajte sve važne i sigurnosne nadogradnje na oba krajnja uređaja.
• Provjerite je li Grupa pravila korištena za konfiguriranje "Ispravka enkripcijskog orakula" pod:
  Konfiguracija računala → Administrativne predloške → Sustav → Delegiranje vjerodajnica .

Na privremenoj osnovi u testnom okruženju, možete postaviti politiku na permisivniju vrijednost kako biste potvrdili da stroga postavka uzrokuje neuspjeh. U produkciji, dugoročno rješenje bi trebalo biti dovođenje svih sustava na dosljednu razinu zakrpa umjesto trajnog popuštanja politike.

Omogućite i potvrdite potrebne TLS protokole

Osigurajte da je TLS 1.2 podržan i omogućen, jer mnogi sustavi sada onemogućuju starije verzije TLS-a.

Na Windows Serveru provjerite SCHANNEL postavke u registru pod:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

Za podršku klijentu TLS 1.2, potvrdite da:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client

"Enabled"=dword:00000001

Možda ćete morati prilagoditi ključeve TLS 1.2 na strani poslužitelja, a zatim ponovno pokrenuti poslužitelj ili barem Usluge udaljene radne površine. Također potvrdite da je RDP certifikat valjan, pouzdan i da ne koristi zastarjele potpise.

Pregledaj i prilagodi grupnu politiku

Grupna pravila često su mjesto gdje se definira provedba NLA i konfiguracija sigurnosti RDP-a.

Otvoreno gpedit.msc ili ekvivalentnom GPMC objektu i navigirajte do:

Konfiguracija računala → Postavke sustava Windows → Postavke sigurnosti → Lokalna pravila → Opcije sigurnosti

Provjerite posebno:

• Zatražite autentifikaciju korisnika za udaljene veze korištenjem autentifikacije na razini mreže.
• Bilo koje politike koje provode FIPS-usklađene algoritme ili ograničavaju vrste enkripcije

Osigurajte da provedba NLA odgovara onome što vaši klijenti mogu podnijeti. Ako opustite politiku kako biste obnovili pristup, dokumentirajte promjenu i zakazujte vrijeme za ispravljanje temeljnih problema klijenata umjesto da neprekidno ostavljate slabije postavke.

Privremeno onemogućite NLA za oporavak pristupa

Ako ste izgubili sav daljinski pristup kritičnom poslužitelju, privremeno isključivanje NLA može biti nužno posljednje sredstvo.

Možete:

• Pokrenite u sigurnom načinu rada s umrežavanjem i prilagodite postavke Remote Desktop, ili
• Pokrenite s medija za oporavak, učitajte sustavsku hives i uredite RDP-Tcp ključ u registru.

Postavi:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

"UserAuthentication"=dword:00000000

Ovo onemogućuje NLA za RDP slušatelja. Kada ponovno dobijete pristup, ispravite osnovni uzrok (povezivost s domenom, zakrpe, TLS ili politike), a zatim ponovo omogućite NLA vraćanjem vrijednosti na 1. Dugotrajno onemogućavanje NLA značajno povećava izloženost pokušajima napada brute-force i iskorištavanja.

Resetiranje RDP klijenta i mrežne konfiguracije

Ako se čini da su problemi s NLA izolirani na određenom klijentskom uređaju, izvršite lokalno resetiranje prije nego što promijenite pravila poslužitelja.

• Izbriši Default.rdp datoteka u %userprofile%\Documents da biste očistili predmemorene postavke.
• Uklonite i ponovo dodajte sve spremljene vjerodajnice u Upravitelju vjerodajnica sustava Windows.
• Potvrdite da je TCP 3389 (ili vaš prilagođeni RDP port) dopušten kroz lokalne vatrozide i međuređajne mrežne uređaje.
• Test s drugog klijenta na istoj mreži kako bi se utvrdilo je li problem specifičan za klijenta ili je globalniji.

Ovaj jednostavni higijenski korak često rješava probleme s oštećenim predmemoriranim vjerodajnicama ili pogrešno primijenjenim opcijama prikaza i sigurnosti u RDP klijentu.

Koje su najbolje prakse za izbjegavanje NLA grešaka u budućnosti?

Jednom kada se trenutni problem reši, ojačajte svoje okruženje kako bi NLA ostao siguran i pouzdan.

• Održavajte operacijske sustave i RDP klijente ažuriranima
• Nadzor zdravlja domene i identiteta
• Standardizirajte RDP i NLA politike putem GPO-a
• Omogućite praćenje dnevnika događaja i sigurnosti
• Izolirajte RDP iza sigurnih ulaznih točaka

Održavajte operacijske sustave i RDP klijente ažuriranima

Održavajte standardni ritam zakrpa za poslužitelje i krajnje točke. Uskladite se s podržanim verzijama sustava Windows i izbjegavajte ostavljanje starijih, neispravljenih klijenata u produkciji. Dosljedne osnovne linije ažuriranja smanjuju nesukladnosti CredSSP-a i TLS-a koje obično prekidaju NLA.

Nadzor zdravlja domene i identiteta

Za sustave povezane s domenom, tretirajte zdravlje kontrolera domene kao dio vašeg RDP stoga. Koristite alate kao što su dcdiag , repadmin i zapisnike događaja kontrolera domene kako bi se rano uhvatili problemi s replikacijom ili DNS-om. Intermitentni problemi s domenom mogu se pojaviti kao RDP i NLA problemi dugo prije nego što korisnici primijete druge simptome.

Standardizirajte RDP i NLA politike putem GPO-a

Definirajte svoj RDP enkripcija, provođenje NLA i CredSSP politika centralno. Primijenite ih po OU ili sigurnosnoj grupi na temelju uloga uređaja, kao što su produkcijski poslužitelji naspram testnih laboratorija. Standardizacija smanjuje odstupanje u konfiguraciji i znatno ubrzava rješavanje problema kada se pojave.

Omogućite praćenje dnevnika događaja i sigurnosti

Pratite Event Viewer na RDP poslužiteljima, posebno:

• Windows Logs → Sigurnost
• Windows Zapisi → Sustav
• Aplikacije i usluge zapisi → Microsoft → Windows → TerminalServices

Korelirajte ponovljene neuspješne prijave, neuspjehe TLS rukovanja ili CredSSP pogreške s vašim SIEM-om gdje je to moguće. Ovo praćenje pomaže u razlikovanju između problema s konfiguracijom i aktivnih napada.

Izolirajte RDP iza sigurnih ulaznih točaka

Čak i s NLA, izlaganje RDP-a izravno internetu predstavlja visok rizik. Postavite RDP iza sigurnog prolaza, VPN-a ili ZTNA-stil proxyja. Dodajte MFA gdje god je to moguće. Alati kao što je TSplus Advanced Security mogu dodatno ograničiti gdje, kada i kako se korisnici povezuju, smanjujući vjerojatnost da incidenti povezani s NLA-om uopće dođu do poslužitelja.

Ojačajte RDP sigurnost s TSplus Advanced Security

NLA rješava samo dio RDP rizika. TSplus Napredna sigurnost dodaje dodatne slojeve zaštite oko vaših Windows poslužitelja i udaljenih radnih površina bez složenosti punih VDI stogova. Značajke kao što su dinamička zaštita od napada brute-force, IP i zemljopisna ograničenja, politike radnog vremena i pravila pristupa na razini aplikacije pomažu u održavanju napadača vani dok legitimni korisnici ostaju produktivni.

Za organizacije koje se oslanjaju na RDP, ali žele jače, jednostavnije sigurnosne kontrole, kombiniranje NLA s TSplus Napredna sigurnost nudi praktičan način za jačanje udaljenog pristupa i smanjenje opterećenja na odgovor na incidente.

Zaključak

NLA greške u RDP-u su frustrirajuće, posebno kada se pojavljuju bez očitih promjena u okruženju. U stvarnosti, gotovo uvijek ukazuju na specifične probleme u verzijama OS-a, povezivosti domene, CredSSP zakrpama, TLS konfiguraciji ili sigurnosnim politikama. Radom kroz strukturiranu kontrolnu listu, možete obnoviti siguran pristup bez pribjegavanja rizičnim trajnim zaobilaznim rješenjima.

Tretirajte NLA kao osnovnu sigurnosnu kontrolu, a ne kao opcionalnu funkciju. Držite je omogućenu, validiranu i nadziranu kao dio vašeg ukupnog stanja daljinskog pristupa. Kada je trebate onemogućiti, ograničite područje utjecaja, riješite osnovni problem i ponovno uključite NLA što je prije moguće.