Chyby NLA v RDP: Příčiny, Opravy a Nejlepší Praktiky

Úvod

Autentizace na úrovni sítě (NLA) je základní bezpečnostní kontrola pro protokol vzdálené plochy, která zastavuje neautentizované uživatele před vytvořením plné relace. Když NLA selže, IT týmy čelí zablokovaným přihlášením, nejasným chybovým zprávám a frustrovaným koncovým uživatelům, kteří se nemohou dostat k důležitým serverům. Tento průvodce vysvětluje, co NLA je, proč k těmto chybám dochází a jak systematicky diagnostikovat a řešit problémy s NLA, aniž byste oslabili svou bezpečnostní pozici RDP.

Co je NLA v RDP?

Síťová úroveň autentizace je vylepšení zabezpečení RDP, které bylo zavedeno s Windows Vista a Windows Server 2008. Místo toho, aby se nejprve vytvořila celá relace vzdálené plochy a poté se požadovalo zadání přihlašovacích údajů, NLA vyžaduje, aby se uživatelé nejprve autentizovali. Teprve po úspěšné autentizaci vytvoří zásobník RDP grafickou relaci.

NLA se spoléhá na CredSSP (Poskytovatel zabezpečení přihlašovacích údajů) pro bezpečné předávání uživatelských přihlašovacích údajů cílovému systému. V prostředích připojených k doméně CredSSP komunikuje s Active Directory, aby ověřil účet před navázáním relace. Na samostatných nebo pracovních skupinách CredSSP ověřuje místní účty nakonfigurované pro vzdálené přihlášení.

Hlavní výhody NLA zahrnují:

• Snížení okna pro útoky hrubou silou a útoky typu denial-of-service na vystavené RDP koncové body
• Povolení jednotné přihlašování (SSO) pro uživatele domény, zlepšení uživatelského zážitku
• Zlepšení výkonu prováděním autentizace před vytvořením relace

Nicméně, NLA je citlivá na verze OS, opravy, TLS konfigurace a zdraví domény. Když některá z těchto podmínek selže, NLA může zcela zablokovat platná připojení.

Jaké jsou běžné příznaky chyb NLA v RDP?

Problémy související s NLA se obvykle projevují podobnými zprávami, bez ohledu na základní příčinu. Pravděpodobně čelíte problému s NLA, pokud narazíte na:

• Vzdálený počítač vyžaduje ověřování na úrovni sítě (NLA), ale váš počítač to nepodporuje.
• Nastala chyba ověřování. Požadovaná funkce není podporována.
• Chyba opravy šifrování oracle CredSSP.
• Vaše přihlašovací údaje nefungovaly, i když je známo, že heslo je správné.
• Časové limity nebo náhlé odpojení během počátečního RDP handshake nebo hned po zadání přihlašovacích údajů

Tyto symptomy mohou ovlivnit jak doménové, tak samostatné hostitele. V praxi se často vracejí k nesouladu bezpečnostních politik, zablokovanému přístupu k doménovému řadiči nebo zastaralým komponentům RDP na obou stranách.

Jaké jsou příčiny chyb NLA v RDP?

Pochopení běžných příčin pomáhá rychle řešit problémy a vyhnout se riskantním obcházením, jako je trvalé zakázání NLA.

• Inkompatibilita klientského nebo serverového operačního systému
• Ovladač domény nedostupný
• Nesoulad záplaty CredSSP
• Nesprávná konfigurace šifrování TLS nebo RDP
• Konflikty skupinových politik nebo registru
• Poškozené uživatelské profily nebo pověření
• Pracovní skupina a scénáře mimo doménu

Inkompatibilita klientského nebo serverového operačního systému

Starší verze Windows nebo klienti RDP třetích stran nemusí plně podporovat NLA nebo moderní chování CredSSP. Například starší verze Windows XP nebo rané verze Vista se nemohou připojit k serverům vyžadujícím NLA bez specifických aktualizací. I na podporovaných systémech mohou zastaralé binární soubory klienta RDP způsobit chyby „váš počítač nepodporuje NLA“, ačkoliv operační systém to nominálně podporuje.

Ovladač domény nedostupný

V prostředí připojeném k doméně závisí NLA na dosažení řadiče domény pro ověření přihlašovacích údajů a udržení zabezpečeného kanálu stroje. Pokud je řadič domény offline, zablokován nějakým způsobem firewall , nebo existuje problém s důvěrou, může selhat ověřování NLA, i když je server sám o sobě funkční. Často uvidíte chyby zmiňující připojení k řadiči domény nebo obecné zprávy „došlo k chybě ověřování“.

Nesoulad záplaty CredSSP

S počátkem aktualizací „Oprava šifrovacího orákula“ z roku 2018 se CredSSP stal přísnějším ohledně ochrany přihlašovacích údajů. Pokud má klient aktualizaci, ale server nikoli (nebo naopak), mohou si obě koncové body nesouhlasit na bezpečné konfiguraci. Tento nesoulad může generovat chyby „Oprava šifrovacího orákula CredSSP“ a zabránit přihlášení NLA, dokud nebudou obě strany opraveny nebo upravena skupinová politika.

Nesprávná konfigurace šifrování TLS nebo RDP

NLA se spoléhá na zabezpečení transportní vrstvy (TLS) k ochraně výměny přihlašovacích údajů. Pokud je TLS 1.0/1.1 zakázáno bez správného povolení TLS 1.2, nebo pokud jsou vynuceny slabé šifrovací sady, může handshake mezi klientem a serverem selhat, než NLA dokončí. Vlastní zabezpečení, režim FIPS nebo nesprávně nakonfigurované certifikáty mohou všechny narušit NLA, i když standardní RDP bez NLA může za určitých podmínek stále fungovat.

Konflikty skupinových politik nebo registru

Skupinové zásady (GPO) a místní bezpečnostní politiky řídí, jak se chovají RDP, CredSSP a šifrování. Konfliktní nebo příliš přísné politiky mohou vynucovat NLA v situacích, kdy klienti jej nepodporují, nebo vyžadovat algoritmy splňující FIPS, které vaši klienti nemohou použít. Přepsání registru pro SCHANNEL nebo CredSSP může zavést podobné nekonzistence, což vede k chybám jako „požadovaná funkce není podporována“ a dalším obecným chybám.

Poškozené uživatelské profily nebo pověření

Občas je problém omezen na jednoho uživatele nebo stroj. Poškozené uložené přihlašovací údaje, nesprávně zarovnané Identifikátor zabezpečení (SID) nebo poškozený soubor Default.rdp mohou narušit ověřování NLA. V těchto případech můžete zjistit, že se jiný uživatel může přihlásit ze stejného zařízení, nebo se stejný uživatel může přihlásit z jiného klienta, ale ne oba současně.

Pracovní skupina a scénáře mimo doménu

NLA předpokládá prostředí, kde mohou být identity uživatelů silně ověřeny, obvykle prostřednictvím Active Directory. V systémech pracovních skupin musí být místní účty pečlivě nakonfigurovány a musí mít oprávnění k přihlášení prostřednictvím Remote Desktop. Pokud je NLA vynuceno, ale není k dispozici žádný řadič domény, nebo jsou nastavení místního účtu nesprávná, pravděpodobně uvidíte chyby související s NLA, i když se server zdá být dostupný.

Jak opravit chyby NLA v RDP?

Použijte následující kroky v tomto pořadí, od nejméně invazivního po nejvíce invazivní. Tento přístup pomáhá obnovit přístup při zachování bezpečnosti, kde je to možné.

• Potvrďte podporu NLA na klientovi a serveru
• Ověřte připojení k řadiči domény (pokud je to relevantní)
• Zarovnejte úrovně a politiky záplat CredSSP
• Povolit a ověřit požadované protokoly TLS
• Zkontrolujte a upravte skupinovou politiku
• Dočasně deaktivujte NLA pro obnovení přístupu
• Resetovat klienta RDP a síťové nastavení

Potvrďte podporu NLA na klientovi a serveru

Nejprve se ujistěte, že oba koncové body podporují NLA.

• Spustit winver na obou klientech a serveru, aby se potvrdilo, že jsou to Windows Vista / Windows Server 2008 nebo novější.
• Zajistěte, aby byly nainstalovány nejnovější aktualizace klienta Remote Desktop (prostřednictvím Windows Update nebo aplikace Microsoft Remote Desktop na platformách, které nejsou Windows).
• Pokud používáte klienty RDP třetích stran, ověřte, že je podpora NLA výslovně zdokumentována a povolena v nastavení klienta.

Pokud žádná strana nepodporuje NLA, naplánujte upgrade nebo výměnu této součásti, místo abyste oslabovali bezpečnost globálně.

Ověřte připojení k řadiči domény (pokud je to relevantní)

Na strojích připojených k doméně ověřte připojení k doméně před změnou nastavení RDP.

• Test základní dostupnosti sítě k řadičům domény (například, ping dc01.yourdomain.com ).
• Použít nltest /dsgetdc:yourdomain.com aby potvrdil, že klient může najít řadič domény.
• V PowerShellu spusťte Test-ComputerSecureChannel zkontrolovat zabezpečený kanál stroje k doméně.

Pokud je zabezpečený kanál přerušen, opravte ho pomocí:

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

Po opravě restartujte stroj, pokud budete vyzváni, a poté znovu otestujte NLA. Řešte nesprávné konfigurace DNS, pravidla firewallu nebo problémy s VPN, které mohou občas blokovat přístup k doméně.

Zarovnejte úrovně a politiky záplat CredSSP

Další krok, potvrďte, že jak klient, tak server mají aktuální bezpečnostní aktualizace, zejména ty, které se týkají CredSSP.

• Nainstalujte všechny důležité a bezpečnostní aktualizace na obou koncových bodech.
• Zkontrolujte, zda byla použita skupinová politika k nastavení „Opravy šifrovacího oracle“ pod:
  Konfigurace počítače → Správní šablony → Systém → Delegace pověření .

Na dočasné bázi v testovacím prostředí můžete nastavit politiku na povolnější hodnotu, abyste potvrdili, že přísné nastavení způsobuje selhání. V produkčním prostředí by dlouhodobým řešením mělo být přivést všechny systémy na konzistentní úroveň záplat, spíše než trvale uvolňovat politiku.

Povolit a ověřit požadované protokoly TLS

Zajistěte, aby byla podporována a povolena verze TLS 1.2, protože mnoho prostředí nyní zakazuje starší verze TLS.

Na Windows Serveru zkontrolujte nastavení SCHANNEL v registru pod:

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

Pro 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žná budete muset také upravit klíče TLS 1.2 na straně serveru a poté restartovat server nebo alespoň Služby vzdálené plochy. Také potvrďte, že certifikát RDP je platný, důvěryhodný a nepoužívá zastaralé podpisy.

Zkontrolujte a upravte skupinovou politiku

Skupinová politika je často místem, kde jsou definovány vynucení NLA a konfigurace zabezpečení RDP.

Otevřeno gpedit.msc (a nebo ekvivalentní objekt GPMC) a přejděte na:

Konfigurace počítače → Nastavení systému Windows → Nastavení zabezpečení → Místní zásady → Možnosti zabezpečení

Zkontrolujte zejména:

• Požadovat ověření uživatele pro vzdálené připojení pomocí ověřování na úrovni sítě
• Jakékoli politiky, které vynucují algoritmy shodné s FIPS nebo omezují typy šifrování

Zajistěte, aby vynucení NLA odpovídalo tomu, co vaši klienti zvládnou. Pokud uvolníte politiku pro obnovení přístupu, zdokumentujte změnu a naplánujte čas na opravu základních problémů klienta místo toho, abyste nechali slabší nastavení v platnosti na neurčito.

Dočasně deaktivujte NLA pro obnovení přístupu

Pokud jste ztratili veškerý vzdálený přístup k důležitému serveru, dočasné vypnutí NLA může být nezbytnou poslední možností.

Můžete:

• Zavést do nouzového režimu s připojením k síti a upravit nastavení vzdálené plochy, nebo
• Zavést pomocí média pro obnovení, načíst systémový hnízdo a upravit klíč RDP-Tcp v registru.

Nastavit:

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

"UserAuthentication"=dword:00000000

Tímto se deaktivuje NLA pro RDP posluchač. Jakmile získáte přístup, opravte základní příčinu (konektivita domény, záplaty, TLS nebo politiky), poté znovu povolte NLA obnovením hodnoty na 1. Dlouhodobé udržování NLA v deaktivovaném stavu výrazně zvyšuje vystavení pokusům o hrubou sílu a zneužití.

Resetovat klienta RDP a síťové nastavení

Pokud se problémy s NLA zdají být izolované na konkrétním klientském zařízení, proveďte místní reset před změnou serverové politiky.

• Smazat Default.rdp soubor v %userprofile%\Documents vymazat uložená nastavení.
• Odstraňte a znovu přidejte jakékoli uložené přihlašovací údaje v Správci přihlašovacích údajů systému Windows.
• Potvrďte, že je port TCP 3389 (nebo váš vlastní RDP port) povolen prostřednictvím místních firewallů a mezičlánkových síťových zařízení.
• Test z jiného klienta na stejné síti, abychom zjistili, zda je problém specifický pro klienta, nebo je globálnější.

Tento jednoduchý hygienický krok často vyřeší problémy s poškozenými uloženými přihlašovacími údaji nebo nesprávně aplikovanými možnostmi zobrazení a zabezpečení v klientu RDP.

Jaké jsou nejlepší postupy, jak se v budoucnu vyhnout chybám NLA?

Jakmile bude okamžitý problém vyřešen, zabezpečte své prostředí, aby NLA zůstalo jak bezpečné, tak spolehlivé.

• Udržujte operační systémy a RDP klienty aktuální
• Sledování zdraví domény a identity
• Standardizujte politiky RDP a NLA pomocí GPO
• Povolit protokol událostí a monitorování zabezpečení
• Izolujte RDP za zabezpečenými vstupními body

Udržujte operační systémy a RDP klienty aktuální

Udržujte standardní frekvenci záplatování pro servery i koncové body. Ujistěte se, že používáte podporované verze Windows a vyhněte se ponechání starších, nezáplatovaných klientů v produkci. Konzistentní základny aktualizací snižují nesoulady CredSSP a TLS, které běžně narušují NLA.

Sledování zdraví domény a identity

Pro systémy připojené k doméně považujte zdraví doménového řadiče za součást svého RDP stacku. Použijte nástroje, jako jsou dcdiag , repadmin a protokoly událostí řadiče domény, aby se včas zachytily problémy s replikací nebo DNS. Přerušované selhání domény se může projevit jako problémy s RDP a NLA dlouho předtím, než si uživatelé všimnou jiných příznaků.

Standardizujte politiky RDP a NLA pomocí GPO

Definujte svůj RDP šifrování, vynucení NLA a politiky CredSSP centrálně. Aplikujte je podle OU nebo bezpečnostní skupiny na základě rolí zařízení, jako jsou produkční servery vs. testovací laboratoře. Standardizace snižuje odchylky v konfiguraci a výrazně urychluje odstraňování problémů, když nastanou.

Povolit protokol událostí a monitorování zabezpečení

Monitorování prohlížeče událostí na RDP hostitelích, zejména:

• Windows Logs → Bezpečnost
• Windows protokoly → Systém
• Aplikace a služby protokoly → Microsoft → Windows → TerminalServices

Sledujte opakované neúspěšné přihlášení, selhání TLS handshake nebo chyby CredSSP ve vašem SIEM, pokud je to možné. Toto monitorování pomáhá rozlišovat mezi problémy s konfigurací a aktivními útoky.

Izolujte RDP za zabezpečenými vstupními body

I když je NLA, vystavení RDP přímo na internet je vysoce rizikové. Umístěte RDP za zabezpečenou bránu, VPN nebo proxy ve stylu ZTNA. Přidejte MFA, kde je to možné. Nástroje jako TSplus Advanced Security mohou dále omezit, kde, kdy a jak se uživatelé připojují, čímž se snižuje pravděpodobnost, že incidenty související s NLA se dostanou na server.

Zesilte zabezpečení RDP s TSplus Advanced Security

NLA řeší pouze část rovnice rizika RDP. TSplus Advanced Security přidává další vrstvy ochrany kolem vašich serverů Windows a vzdálených desktopů bez složitosti plně rozvinutých VDI stacků. Funkce jako dynamická ochrana proti hrubé síle, omezení na základě IP a země, politiky pracovní doby a pravidla přístupu na úrovni aplikace pomáhají udržet útočníky venku, zatímco legitimní uživatelé zůstávají produktivní.

Pro organizace, které se spoléhají na RDP, ale chtějí silnější a jednodušší bezpečnostní kontroly, spojení NLA s TSplus Advanced Security nabízí praktický způsob, jak zpevnit vzdálený přístup a snížit pracovní zátěž při reakci na incidenty.

Závěr

Chyby NLA v RDP jsou frustrující, zejména když se objevují bez zřejmých změn v prostředí. Ve skutečnosti téměř vždy ukazují na konkrétní problémy ve verzích OS, připojení k doméně, patchování CredSSP, konfiguraci TLS nebo bezpečnostních politikách. Prací podle strukturovaného kontrolního seznamu můžete obnovit bezpečný přístup, aniž byste museli sahat po riskantních trvalých obchvatech.

Považujte NLA za základní bezpečnostní kontrolu spíše než za volitelnou funkci. Mějte ji povolenou, ověřenou a monitorovanou jako součást vaší celkové pozice vzdáleného přístupu. Když ji potřebujete vypnout, omezte rozsah dopadu, vyřešte základní problém a co nejdříve znovu zapněte NLA.