)
)
Úvod
Autentifikácia na úrovni siete (NLA) je základná bezpečnostná kontrola pre protokol vzdialenej plochy, ktorá zastavuje neautentifikovaných používateľov pred vytvorením plnej relácie. Keď NLA zlyhá, IT tímy čelí zablokovaným prihláseniam, nejasným chybovým hláseniam a frustrovaným koncovým používateľom, ktorí sa nemôžu dostať k kritickým serverom. Tento sprievodca vysvetľuje, čo je NLA, prečo k týmto chybám dochádza a ako systematicky diagnostikovať a riešiť problémy s NLA bez oslabenia vašej bezpečnostnej pozície RDP.
Čo je NLA v RDP?
Autentifikácia na úrovni siete je vylepšenie zabezpečenia RDP, ktoré bolo zavedené s Windows Vista a Windows Server 2008. Namiesto vytvárania celej relácie vzdialenej plochy a následného požiadania o poverenia, NLA vyžaduje, aby sa používatelia najprv autentifikovali. Až po úspešnej autentifikácii vytvorí zásobník RDP grafickú reláciu.
NLA sa spolieha na CredSSP (Poskytovateľ zabezpečenia poverení) na bezpečné odovzdanie poverení používateľa cieľovému systému. V prostrediach pripojených k doméne CredSSP komunikuje s Active Directory na overenie účtu pred vytvorením relácie. Na samostatných alebo pracovných skupinách CredSSP overuje miestne účty nakonfigurované na vzdialené prihlásenie.
Kľúčové výhody NLA zahŕňajú:
- Zníženie okna pre útoky hrubou silou a útoky typu denial-of-service na vystavené RDP koncové body
- Povolenie jednotné prihlásenie (SSO) pre doménových používateľov, zlepšovanie používateľskej skúsenosti
- Zlepšenie výkonu vykonaním autentifikácie pred vytvorením relácie
Avšak, NLA je citlivá na verzie OS, opravy, TLS konfigurácia a zdravie domény. Keď niektorá z týchto požiadaviek zlyhá, NLA môže úplne zablokovať platné pripojenia.
Aké sú bežné príznaky chýb NLA v RDP?
Problémy súvisiace s NLA sa zvyčajne prejavujú podobnými správami, bez ohľadu na základnú príčinu. Pravdepodobne čelíte problému s NLA, ak narazíte na:
- Vzdialený počítač vyžaduje autentifikáciu na úrovni siete (NLA), ale váš počítač ju nepodporuje.
- Nastala chyba autentifikácie. Požadovaná funkcia nie je podporovaná.
- Chyba opravy oracle šifrovania CredSSP.
- Vaše poverenia nefungovali.
- Časové limity alebo náhle odpojenia počas počiatočného RDP handshake alebo hneď po zadaní poverení
Tieto symptómy môžu ovplyvniť ako doménové, tak aj samostatné hostiteľské systémy. V praxi sa často vracajú k nezhodným bezpečnostným politikám, zablokovanému prístupu k doménovému ovládaču alebo zastaraným komponentom RDP na oboch stranách.
Aké sú príčiny chýb NLA v RDP?
Pochopenie bežných príčin pomáha rýchlo riešiť problémy a vyhnúť sa riskantným obchádzkam, ako je trvalé vypnutie NLA.
- Nezlučiteľnosť klienta alebo servera OS
- Doménový ovládač nedostupný
- Nesúlad s opravou CredSSP
- Nesprávna konfigurácia šifrovania TLS alebo RDP
- Konflikty skupinovej politiky alebo registra
- Skazené používateľské profily alebo poverenia
- Pracovná skupina a scenáre mimo domény
Nezlučiteľnosť klienta alebo servera OS
Staršie verzie systému Windows alebo klienti RDP tretích strán nemusia plne podporovať NLA alebo moderné správanie CredSSP. Napríklad, staršie verzie Windows XP alebo rané verzie Vista sa nemôžu pripojiť k serverom, ktoré vyžadujú NLA, bez špecifických aktualizácií. Aj na podporovaných systémoch môžu zastarané binárne súbory klienta RDP spôsobiť chyby „váš počítač nepodporuje NLA“, aj keď operačný systém to nominálne podporuje.
Doménový ovládač nedostupný
V prostredí pripojenom k doméne závisí NLA od dosiahnutia doménového riadiaceho prvku na overenie poverení a udržanie zabezpečeného kanála stroja. Ak je doménový riadiaci prvok offline, zablokovaný pomocou a firewall , alebo môže nastať problém s dôverou, autentifikácia NLA môže zlyhať, aj keď je server sám v prevádzke. Často uvidíte chyby spomínajúce pripojenie k doménovému ovládaču alebo všeobecné správy „nastala chyba autentifikácie“.
Nesúlad s opravou CredSSP
Začínajúc aktualizáciami „Oprava šifrovacieho orákula“ z roku 2018, CredSSP sa stal prísnejším v tom, ako sú chránené poverenia. Ak má klient aktualizáciu, ale server nie (alebo naopak), dva koncové body sa nemusia dohodnúť na bezpečnej konfigurácii. Tento nesúlad môže generovať chyby „Oprava šifrovacieho orákula CredSSP“ a zabrániť prihláseniam NLA, kým nie sú obidve strany opravené alebo kým nie je upravená skupinová politika.
Nesprávna konfigurácia šifrovania TLS alebo RDP
NLA sa spolieha na zabezpečenie prenosovej vrstvy (TLS) na ochranu výmeny poverení. Ak je TLS 1.0/1.1 zakázané bez správneho povolenia TLS 1.2, alebo ak sú vynútené slabé šifrovacie súpravy, môže zlyhať handshake medzi klientom a serverom pred dokončením NLA. Vlastné zabezpečenie, režim FIPS alebo nesprávne nakonfigurované certifikáty môžu všetky narušiť NLA, aj keď štandardný RDP bez NLA môže za určitých podmienok stále fungovať.
Konflikty skupinovej politiky alebo registra
Objekty skupinovej politiky (GPO) a miestne bezpečnostné politiky kontrolujú, ako sa správa RDP, CredSSP a šifrovanie. Konfliktné alebo príliš prísne politiky môžu vynucovať NLA v scenároch, kde klienti to nepodporujú alebo vyžadujú algoritmy kompatibilné s FIPS, ktoré vaši klienti nemôžu použiť. Prepisy registru pre SCHANNEL alebo CredSSP môžu zavádzať podobné nekonzistencie, čo vedie k chybám ako „požadovaná funkcia nie je podporovaná“ a iným všeobecným chybám.
Skazené používateľské profily alebo poverenia
Občas je problém obmedzený na jedného používateľa alebo stroj. Poškodené uložené poverenia, nesprávne zarovnané Identifikátor zabezpečenia (SID) alebo poškodený súbor Default.rdp môžu narušiť autentifikáciu NLA. V týchto prípadoch môžete zistiť, že iný používateľ sa môže prihlásiť z toho istého zariadenia, alebo ten istý používateľ sa môže prihlásiť z iného klienta, ale nie obaja spolu.
Pracovná skupina a scenáre mimo domény
NLA predpokladá prostredie, kde môžu byť identity používateľov silne autentifikované, zvyčajne prostredníctvom Active Directory. V systémoch pracovnej skupiny musia byť miestne účty starostlivo nakonfigurované a musia mať povolenie na prihlásenie cez Remote Desktop. Ak je NLA vynútené, ale nie je k dispozícii žiadny doménový ovládač, alebo nastavenia miestneho účtu sú nesprávne, pravdepodobne uvidíte chyby súvisiace s NLA, aj keď sa server zdá byť dostupný.
Ako opraviť chyby NLA v RDP?
Použite nasledujúce kroky v poradí, od najmenej invazívnych po najviac invazívne. Tento prístup pomáha obnoviť prístup pri zachovaní bezpečnosti, kde je to možné.
- Potvrdiť podporu NLA na klientovi a serveri
- Overte pripojenie k ovládaciemu serveru domény (ak je to relevantné)
- Zladiť úrovne a politiky záplaty CredSSP
- Povoliť a overiť požadované protokoly TLS
- Skontrolovať a upraviť skupinovú politiku
- Dočasne zakázať NLA na obnovenie prístupu
- Obnoviť konfiguráciu klienta RDP a siete
Potvrdiť podporu NLA na klientovi a serveri
Najprv sa uistite, že oba koncové body sú schopné NLA.
-
Spustiť
winverna oboch klientoch a serveri, aby sa potvrdilo, že sú to Windows Vista / Windows Server 2008 alebo novšie. - Zabezpečte, aby boli nainštalované najnovšie aktualizácie klienta Remote Desktop (cez Windows Update alebo aplikáciu Microsoft Remote Desktop na platformách, ktoré nie sú Windows).
- Ak používate klientov RDP tretích strán, overte, či je podpora NLA výslovne zdokumentovaná a povolená v nastaveniach klienta.
Ak žiadna strana nepodporuje NLA, plánujte upgrade alebo výmenu tejto súčasti, namiesto oslabenia bezpečnosti globálne.
Overte pripojenie k ovládaciemu serveru domény (ak je to relevantné)
Na počítačoch pripojených k doméne overte pripojenie k doméne pred zmenou nastavení RDP.
-
Test základnej dostupnosti siete na doménové ovládače (napríklad,
ping dc01.yourdomain.com). -
Použiť
nltest /dsgetdc:yourdomain.comna potvrdenie, že klient môže nájsť riadiaci doménový server. -
V PowerShell spustite
Testovanie zabezpečeného kanála počítačana overenie zabezpečeného kanála stroja k doméne.
Ak je zabezpečený kanál prerušený, opravte ho pomocou:
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)
Po oprave reštartujte stroj, ak sa to vyžaduje, a potom znova otestujte NLA. Riešte nesprávne konfigurácie DNS, pravidlá firewallu alebo problémy s VPN, ktoré môžu občas blokovať prístup k doméne.
Zladiť úrovne a politiky záplaty CredSSP
Ďalej potvrďte, že klient aj server majú aktuálne bezpečnostné aktualizácie, najmä tie, ktoré sa týkajú CredSSP.
- Nainštalujte všetky dôležité a bezpečnostné aktualizácie na oboch koncových bodoch.
-
Skontrolujte, či bola skupinová politika použitá na konfiguráciu „Oprava šifrovania Oracle“ pod:
Konfigurácia počítača → Správne šablóny → Systém → Delegovanie poverení.
Na dočasnej báze v testovacom prostredí môžete nastaviť politiku na povolenejšiu hodnotu, aby ste potvrdili, že prísne nastavenie spôsobuje zlyhanie. V produkcii by dlhodobé riešenie malo byť priniesť všetky systémy na konzistentnú úroveň opravy, namiesto trvalého uvoľnenia politiky.
Povoliť a overiť požadované protokoly TLS
Zabezpečte, aby bol podporovaný a povolený TLS 1.2, pretože mnohé prostredia teraz zakazujú staršie verzie TLS.
Na serveri Windows, overte nastavenia SCHANNEL v registri pod:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
Pre podporu klienta TLS 1.2 potvrďte, že:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client "Enabled"=dword:00000001
Možno budete musieť upraviť kľúče TLS 1.2 na strane servera a potom reštartovať server alebo aspoň Služby vzdialenej plochy. Taktiež potvrďte, že certifikát RDP je platný, dôveryhodný a nepoužíva zastarané podpisy.
Skontrolovať a upraviť skupinovú politiku
Skupinová politika je často miestom, kde sú definované vynucovanie NLA a konfigurácia zabezpečenia RDP.
Otvorené
gpedit.msc
(a alebo ekvivalentný objekt GPMC) a prejdite na:
Konfigurácia počítača → Nastavenia systému Windows → Nastavenia zabezpečenia → Miestne politiky → Možnosti zabezpečenia
Skontrolujte najmä:
- "Vyžadovať overenie používateľa pre vzdialené pripojenia pomocou overenia na úrovni siete"
- Akékoľvek politiky, ktoré vynucujú algoritmy v súlade s FIPS alebo obmedzujú typy šifrovania
Zabezpečte, aby vynucovanie NLA zodpovedalo tomu, čo vaši klienti zvládnu. Ak uvoľníte politiku na obnovenie prístupu, zdokumentujte zmenu a naplánujte čas na opravu základných problémov klientov namiesto toho, aby ste nechali slabšie nastavenia na neurčito.
Dočasne zakázať NLA na obnovenie prístupu
Ak ste stratili všetok vzdialený prístup k kritickému serveru, dočasné vypnutie NLA môže byť nevyhnutným posledným riešením.
Môžete:
- Spustite v núdzovom režime s pripojením na internet a upravte nastavenia vzdialenej plochy, alebo
- Spustite pomocou obnovovacieho média, načítajte systémový hniezdo a upravte kľúč RDP-Tcp v registri.
Nastaviť:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp "UserAuthentication"=dword:00000000
Týmto sa deaktivuje NLA pre RDP poslucháča. Akonáhle získate prístup, opravte základnú príčinu (pripojenie k doméne, opravy, TLS alebo politiky), potom znovu aktivujte NLA obnovením hodnoty na 1. Dlhodobé ponechanie NLA deaktivovaného výrazne zvyšuje vystavenie pokusom o hrubú silu a zneužitie.
Obnoviť konfiguráciu klienta RDP a siete
Ak sa problémy s NLA zdajú byť izolované na konkrétnom klientskom zariadení, vykonajte miestne resetovanie pred zmenou politiky servera.
-
Vymažte
Default.rdpsúbor v%userprofile%\Documentsna vymazanie vyrovnávacích nastavení. - Odstráňte a znova pridajte akékoľvek uložené poverenia v Správcovi poverení systému Windows.
- Potvrďte, že je povolený TCP 3389 (alebo váš vlastný RDP port) cez miestne firewally a medziľahlé sieťové zariadenia.
- Test z iného klienta v tej istej sieti na určenie, či je problém špecifický pre klienta alebo je globálnejší.
Tento jednoduchý hygienický krok často rieši problémy s poškodenými uloženými povereniami alebo nesprávne aplikovanými možnosťami zobrazenia a zabezpečenia v RDP klientovi.
Aké sú najlepšie praktiky na vyhnutie sa chybám NLA v budúcnosti?
Akonáhle je okamžitý problém vyriešený, zabezpečte svoje prostredie, aby NLA zostalo bezpečné a spoľahlivé.
- Udržujte operačné systémy a RDP klientov aktualizované
- Monitorovanie domény a zdravia identity
- Štandardizujte politiky RDP a NLA prostredníctvom GPO
- Povoliť protokolovanie udalostí a monitorovanie zabezpečenia
- Izolujte RDP za zabezpečené vstupné body
Udržujte operačné systémy a RDP klientov aktualizované
Udržujte štandardný cyklus záplatovania pre servery aj koncové body. Zlaďte podporované verzie Windows a vyhnite sa ponechávaniu starších, nezáplatovaných klientov v produkcii. Konzistentné základne aktualizácií znižujú nezhody CredSSP a TLS, ktoré bežne narušujú NLA.
Monitorovanie domény a zdravia identity
Pre systémy pripojené k doméne považujte zdravie doménového ovládača za súčasť svojho RDP zásobníka. Použite nástroje ako
dcdiag
,
repadmin
a protokoly udalostí ovládača domény na včasné zachytenie problémov s replikáciou alebo DNS. Prerušované zlyhania domény sa môžu prejaviť ako problémy s RDP a NLA dlho predtým, ako si používatelia všimnú iné príznaky.
Štandardizujte politiky RDP a NLA prostredníctvom GPO
Definujte svoj RDP šifrovanie, vynucovanie NLA a politiky CredSSP centrálne. Aplikujte ich podľa OU alebo bezpečnostnej skupiny na základe rolí zariadení, ako sú produkčné servery vs. testovacie laboratóriá. Štandardizácia znižuje odchýlky v konfigurácii a výrazne urýchľuje riešenie problémov, keď sa vyskytnú.
Povoliť protokolovanie udalostí a monitorovanie zabezpečenia
Monitorovanie udalostí na hostiteľoch RDP, najmä:
- Windows Logs → Bezpečnosť
- Windows Logs → Systém
- Aplikácie a služby protokoly → Microsoft → Windows → TerminalServices
Korelujte opakované neúspešné prihlásenia, zlyhania TLS handshake alebo chyby CredSSP so svojím SIEM, ak je to možné. Tento monitoring pomáha rozlíšiť medzi problémami s konfiguráciou a aktívnymi útokmi.
Izolujte RDP za zabezpečené vstupné body
Aj s NLA je vystavenie RDP priamo na internet vysoké riziko. Umístite RDP za bezpečnú bránu, VPN alebo proxy v štýle ZTNA. Pridajte MFA, kde je to možné. Nástroje ako TSplus Advanced Security môžu ďalej obmedziť, kde, kedy a ako sa používatelia pripájajú, čím sa znižuje pravdepodobnosť, že incidenty súvisiace s NLA sa dostanú na server.
Posilnite bezpečnosť RDP s TSplus Advanced Security
NLA rieši iba časť rovnice rizika RDP. TSplus Advanced Security pridáva ďalšie vrstvy ochrany okolo vašich serverov Windows a vzdialených pracovných plôch bez zložitosti plne vyvinutých VDI stackov. Funkcie ako dynamická ochrana proti hrubej sile, obmedzenia na základe IP a krajiny, politiky pracovných hodín a pravidlá prístupu na úrovni aplikácií pomáhajú udržiavať útočníkov vonku, zatiaľ čo legitímni používatelia zostávajú produktívni.
Pre organizácie, ktoré sa spoliehajú na RDP, ale chcú silnejšie a jednoduchšie bezpečnostné kontroly, kombinovanie NLA s TSplus Advanced Security ponúka praktický spôsob, ako zabezpečiť vzdialený prístup a znížiť pracovnú záťaž pri reakcii na incidenty.
Záver
Chyby NLA v RDP sú frustrujúce, najmä keď sa objavia bez zjavnej zmeny prostredia. V skutočnosti takmer vždy poukazujú na konkrétne problémy vo verziách OS, pripojení k doméne, patchovaní CredSSP, konfigurácii TLS alebo bezpečnostných politikách. Prácou cez štruktúrovaný kontrolný zoznam môžete obnoviť bezpečný prístup bez toho, aby ste sa uchýlili k riskantným trvalým obchádzkam.
Považujte NLA za základnú bezpečnostnú kontrolu, nie za voliteľnú funkciu. Nechajte ho povolené, overené a monitorované ako súčasť vašej celkovej pozície vzdialeného prístupu. Keď ho potrebujete vypnúť, obmedzte rozsah poškodenia, vyriešte základný problém a čo najskôr znovu zapnite NLA.
)
)
)
