NLA hibák RDP-ben: Okok, megoldások és legjobb gyakorlatok

Bevezetés

A Hálózati Szintű Hitelesítés (NLA) a Távoli Asztali Protokoll alapvető biztonsági ellenőrzése, amely megakadályozza a hitelesítetlen felhasználókat, mielőtt teljes munkamenet jönne létre. Amikor az NLA meghiúsul, az IT csapatok blokkolt bejelentkezésekkel, homályos hibaüzenetekkel és frusztrált végfelhasználókkal szembesülnek, akik nem tudják elérni a kritikus szervereket. Ez az útmutató elmagyarázza, mi az NLA, miért fordulnak elő ezek a hibák, és hogyan lehet rendszerszerűen hibaelhárítani és megoldani az NLA problémákat anélkül, hogy gyengítené az RDP biztonsági helyzetét.

Mi az NLA az RDP-ben?

A Hálózati Szintű Hitelesítés (NLA) egy RDP biztonsági fejlesztés, amelyet a Windows Vista és a Windows Server 2008 vezetett be. Ahelyett, hogy a teljes távoli asztali munkamenetet létrehozná, majd kérné a hitelesítő adatokat, az NLA megköveteli, hogy a felhasználók először hitelesítsenek. Csak a sikeres hitelesítés után hozza létre az RDP verem a grafikus munkamenetet.

Az NLA a CredSSP-re (Credential Security Support Provider) támaszkodik, hogy biztonságosan továbbítsa a felhasználói hitelesítő adatokat a célrendszerhez. Domainhez csatlakozott környezetekben a CredSSP az Active Directoryval kommunikál, hogy érvényesítse a fiókot, mielőtt a munkamenet létrejön. Önálló vagy munkacsoportos hosztokon a CredSSP érvényesíti a távoli bejelentkezéshez konfigurált helyi fiókokat.

NLA fő előnyei a következők:

• A brute-force és szolgáltatásmegtagadási támadások ablakának csökkentése a nyilvános RDP végpontokon
• Engedélyezés egységes bejelentkezés (SSO) domain felhasználók számára, javítva a felhasználói élményt
• A teljesítmény javítása az autentikáció elvégzésével a munkamenet létrehozása előtt

Azonban az NLA érzékeny az operációs rendszer verzióira, javításaira, TLS konfiguráció és domain egészség. Amikor ezek közül bármelyik előfeltétel nem teljesül, az NLA teljesen blokkolhatja a érvényes kapcsolatokat.

Mik a leggyakoribb tünetei az NLA hibáknak az RDP-ben?

Az NLA-hoz kapcsolódó problémák általában hasonló üzenetekkel jelentkeznek, függetlenül a mögöttes okoktól. Valószínűleg NLA problémával áll szemben, ha a következőket tapasztalja:

• A távoli számítógép hálózati szintű hitelesítést (NLA) igényel, de a számítógépe nem támogatja azt.
• “Hitelesítési hiba történt. A kért funkció nem támogatott.”
• “CredSSP titkosítási oracle javítási hiba.”
• A hitelesítő adatai nem működtek.
• Időtúllépések vagy hirtelen megszakadások az első RDP kézfogás során vagy közvetlenül a hitelesítő adatok megadása után

Ezek a tünetek mind a tartományhoz csatlakozott, mind az önálló gazdagépeket érinthetik. A gyakorlatban gyakran visszavezethetők a nem megfelelő biztonsági házirendekre, a blokkolt tartományvezérlő hozzáférésre vagy a régi RDP összetevőkre bármelyik oldalon.

Mik a NLA hibák okai az RDP-ben?

A közös gyökérokok megértése segít gyorsan hibaelhárítani és elkerülni a kockázatos megoldásokat, mint például az NLA véglegesen letiltása.

• Kliens vagy szerver operációs rendszer inkompatibilitás
• Domain Controller elérhetetlen
• CredSSP javítóprogram eltérés
• TLS vagy RDP titkosítási hibás konfiguráció
• Csoportházirend vagy rendszerleíró adatbázis ütközések
• Corrupted User Profiles or Credentials
• Munkacsoport és nem tartományi forgatókönyvek

Kliens vagy szerver operációs rendszer inkompatibilitás

Régebbi Windows verziók vagy harmadik féltől származó RDP kliensek lehet, hogy nem támogatják teljes mértékben az NLA-t vagy a modern CredSSP viselkedést. Például a régi Windows XP vagy korai Vista verziók nem tudnak csatlakozni az NLA által érvényesített szerverekhez specifikus frissítések nélkül. Még a támogatott rendszereken is, az elavult RDP kliens binárisok „a számítógépe nem támogatja az NLA-t” hibákat okozhatnak, annak ellenére, hogy az operációs rendszer névlegesen támogatja azt.

Domain Controller elérhetetlen

A tartományhoz csatlakozott környezetben az NLA a hitelesítő adatok érvényesítéséhez és a gép biztonságos csatornájának fenntartásához egy tartományvezérlő elérésétől függ. Ha a tartományvezérlő offline van, blokkolva van egy tűzfal vagy ha bizalmi probléma merül fel, az NLA hitelesítés meghiúsulhat, még akkor is, ha a szerver maga működik. Gyakran láthat hibákat, amelyek a tartományvezérlő kapcsolódási problémáira vagy általános "hitelesítési hiba történt" üzenetekre utalnak.

CredSSP javítóprogram eltérés

A 2018-as „Titkosítási Oracle Hibaelhárítás” frissítésekkel a CredSSP szigorúbbá vált a hitelesítési adatok védelme terén. Ha egy kliens rendelkezik a frissítéssel, de a szerver nem (vagy fordítva), a két végpont nem biztos, hogy egyetértenek a biztonságos konfigurációval. Ez az eltérés „CredSSP titkosítási oracle hibaelhárítás” hibákat generálhat, és megakadályozhatja az NLA bejelentkezéseket, amíg mindkét oldal nem kerül javításra, vagy a Csoportházirend nincs módosítva.

TLS vagy RDP titkosítási hibás konfiguráció

Az NLA a Transport Layer Security (TLS) protokollra támaszkodik a hitelesítő adatok cseréjének védelme érdekében. Ha a TLS 1.0/1.1 le van tiltva anélkül, hogy a TLS 1.2-t helyesen engedélyeznék, vagy ha gyenge titkosítási algoritmusok vannak érvényben, a kliens és a szerver közötti kézfogás meghiúsulhat, mielőtt az NLA befejeződik. A testreszabott biztonsági megerősítés, a FIPS mód vagy a hibásan konfigurált tanúsítványok mind megszakíthatják az NLA működését, még akkor is, ha a standard RDP NLA nélkül bizonyos körülmények között még működhet.

Csoportházirend vagy rendszerleíró adatbázis ütközések

A Csoportházirend-objektumok (GPO-k) és a helyi biztonsági házirendek szabályozzák, hogy az RDP, a CredSSP és a titkosítás hogyan viselkedik. Az ellentmondásos vagy túlságosan szigorú házirendek érvényesíthetik az NLA-t olyan helyzetekben, ahol az ügyfelek nem támogatják azt, vagy FIPS-kompatibilis algoritmusokat igényelnek, amelyeket az ügyfelei nem tudnak használni. A SCHANNEL vagy a CredSSP regisztrációs felülírásai hasonló inkonzisztenciákat okozhatnak, amelyek "a kért funkció nem támogatott" és egyéb általános hibákhoz vezetnek.

Corrupted User Profiles or Credentials

Időnként a probléma egyetlen felhasználóra vagy gépre korlátozódik. A sérült gyorsítótárazott hitelesítő adatok, egy nem megfelelően beállított Biztonsági azonosító (SID), vagy egy sérült Default.rdp fájl mind befolyásolhatja az NLA hitelesítést. Ezekben az esetekben előfordulhat, hogy egy másik felhasználó be tud jelentkezni ugyanarról az eszközről, vagy ugyanaz a felhasználó be tud jelentkezni egy másik kliensről, de nem mindkettő egyszerre.

Munkacsoport és nem tartományi forgatókönyvek

Az NLA egy olyan környezetet feltételez, ahol a felhasználói identitások erősen hitelesíthetők, jellemzően az Active Directory-n keresztül. Munkacsoport rendszerekben a helyi fiókokat gondosan kell konfigurálni, és engedéllyel kell rendelkezniük a Remote Desktop-on való bejelentkezéshez. Ha az NLA érvényesítve van, de nincs elérhető tartományvezérlő, vagy a helyi fiókbeállítások helytelenek, valószínű, hogy NLA-val kapcsolatos hibákat fog látni, még akkor is, ha a szerver elérhetőnek tűnik.

Hogyan javítsuk ki az NLA hibákat az RDP-ben?

Használja az alábbi lépéseket sorrendben, a legkevésbé invazívtól a legintruzívabbig. Ez a megközelítés segít helyreállítani a hozzáférést, miközben lehetőség szerint megőrzi a biztonságot.

• Erősítse meg az NLA támogatást az ügyfélen és a szerveren
• Ellenőrizze a kapcsolatot a tartományvezérlővel (ha alkalmazható)
• Igazítsa a CredSSP javító szinteket és irányelveket
• TLS protokollok engedélyezése és érvényesítése
• Csoportházirend felülvizsgálata és módosítása
• Ideiglenesen tiltsa le az NLA-t a hozzáférés helyreállításához
• RDP kliens és hálózati konfiguráció visszaállítása

Erősítse meg az NLA támogatást az ügyfélen és a szerveren

Először győződjön meg arról, hogy mindkét végpont képes az NLA-ra.

• Futtatás winver mind a kliensen, mind a szerveren, hogy megerősítsék, hogy Windows Vista / Windows Server 2008 vagy újabb verzió.
• Biztosítsa, hogy a legfrissebb Remote Desktop kliensfrissítések telepítve legyenek (Windows Update-en vagy a Microsoft Remote Desktop alkalmazáson keresztül nem Windows platformokon).
• Ha harmadik féltől származó RDP klienseket használ, ellenőrizze, hogy az NLA támogatás kifejezetten dokumentálva van-e és engedélyezve van a kliens beállításaiban.

Ha egyik fél sem támogatja az NLA-t, tervezze meg a frissítést vagy a komponens cseréjét, ahelyett, hogy globálisan gyengítené a biztonságot.

Ellenőrizze a kapcsolatot a tartományvezérlővel (ha alkalmazható)

A tartományhoz csatlakozott gépeken érvényesítse a tartományi kapcsolatot az RDP-beállítások megváltoztatása előtt.

• Tesztelje az alapvető hálózati elérhetőséget a tartományvezérlők felé (például, ping dc01.yourdomain.com ).
• Használat nltest /dsgetdc:yourdomain.com a kliens tudja helyezni a tartományvezérlőt.
• A PowerShell-ben futtassa Test-ComputerSecureChannel a gép biztonságos csatornájának ellenőrzése a tartományhoz.

Ha a biztonságos csatorna megszakad, javítsa meg a következővel:

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

A javítás után indítsa újra a gépet, ha erre kérik, majd tesztelje újra az NLA-t. Kezelje a DNS hibás konfigurációkat, a tűzfal szabályokat vagy a VPN problémákat, amelyek időszakosan blokkolhatják a domain hozzáférést.

Igazítsa a CredSSP javító szinteket és irányelveket

Ezután erősítse meg, hogy mind a kliens, mind a szerver rendelkezik a legfrissebb biztonsági frissítésekkel, különösen a CredSSP-vel kapcsolatosakkal.

• Telepítse az összes fontos és biztonsági frissítést mindkét végponton.
• Ellenőrizze, hogy a Csoportházirend használatban volt-e az "Encryption Oracle Remediation" konfigurálásához a következő helyen:
  Számítógép konfiguráció → Adminisztratív sablonok → Rendszer → Hitelesítési delegálás .

Ideiglenesen egy tesztkörnyezetben beállíthatja a politikát egy engedékenyebb értékre, hogy megerősítse, hogy a szigorú beállítás okozza a hibát. A termelésben a hosszú távú megoldás az összes rendszer egységes javítási szintre hozása kell, hogy legyen, a politika tartós lazítása helyett.

TLS protokollok engedélyezése és érvényesítése

Biztosítsa, hogy a TLS 1.2 támogatott és engedélyezett legyen, mivel sok környezet most letiltja a régebbi TLS verziókat.

A Windows Server rendszeren ellenőrizze a SCHANNEL beállításokat a rendszerleíró adatbázisban a következő helyen:

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

TLS 1.2 kliens támogatásának megerősítéséhez, győződjön meg arról, hogy:

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

"Enabled"=dword:00000001

Lehet, hogy a szerveroldali TLS 1.2 kulcsokat is módosítania kell, majd indítsa újra a szervert, vagy legalább a Remote Desktop Services-t. Ezenkívül erősítse meg, hogy az RDP tanúsítvány érvényes, megbízható, és nem használ elavult aláírásokat.

Csoportházirend felülvizsgálata és módosítása

A Csoportházirend gyakran az a hely, ahol az NLA érvényesítése és az RDP biztonsági konfigurációja van meghatározva.

Nyitva gpedit.msc (vagy a megfelelő GPMC objektum) és navigáljon a:

Számítógép konfiguráció → Windows beállítások → Biztonsági beállítások → Helyi irányelvek → Biztonsági lehetőségek

Különösen ellenőrizze:

• “Kérje meg a felhasználót, hogy hitelesítse magát a távoli kapcsolatokhoz a Hálózati Szintű Hitelesítés használatával”
• Bármely olyan irányelv, amely érvényesíti a FIPS-kompatibilis algoritmusokat vagy korlátozza a titkosítási típusokat

Biztosítsa, hogy az NLA érvényesítése megfeleljen az ügyfelei igényeinek. Ha enyhít egy politikát a hozzáférés helyreállítása érdekében, dokumentálja a változást, és ütemezzen időt az alapvető ügyfélproblémák kijavítására, ahelyett, hogy határozatlan ideig gyengébb beállításokat hagyna érvényben.

Ideiglenesen tiltsa le az NLA-t a hozzáférés helyreállításához

Ha elvesztette az összes távoli hozzáférést egy kritikus szerverhez, a NLA ideiglenes letiltása szükséges végső megoldás lehet.

Ön képes:

• Indítsa el a Biztonságos módot hálózati kapcsolattal, és állítsa be a Távoli asztal beállításait, vagy
• Indítsa el a helyreállító médiával, töltse be a rendszer hívját, és szerkessze az RDP-Tcp kulcsot a rendszerleíró adatbázisban.

Beállítás:

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

"UserAuthentication"=dword:00000000

Ez letiltja az NLA-t az RDP hallgató számára. Miután visszanyerte a hozzáférést, javítsa ki az alapvető okot (domain kapcsolat, javítások, TLS vagy irányelvek), majd engedélyezze újra az NLA-t az érték 1-re állításával. Az NLA hosszú távú letiltása jelentősen növeli a brute-force és kihasználási kísérleteknek való kitettséget.

RDP kliens és hálózati konfiguráció visszaállítása

Ha az NLA problémák úgy tűnnek, hogy egy adott kliens eszközre korlátozódnak, végezzen el egy helyi visszaállítást, mielőtt megváltoztatná a szerver politikáját.

• Törölje a Default.rdp fájlban %userprofile%\Documents a gyorsítótárazott beállítások törléséhez.
• Távolítsa el és adja hozzá újra a mentett hitelesítő adatokat a Windows Hitelesítőadat-kezelőjében.
• Megerősíti, hogy a TCP 3389 (vagy a saját RDP portja) engedélyezve van a helyi tűzfalakon és a köztes hálózati eszközökön.
• Teszt egy másik klienssel ugyanazon a hálózaton, hogy meghatározzuk, vajon a probléma kliensspecifikus vagy globálisabb.

Ez az egyszerű higiéniai lépés gyakran megoldja a problémákat a sérült gyorsítótárazott hitelesítő adatokkal vagy a RDP kliensben helytelenül alkalmazott megjelenítési és biztonsági beállításokkal.

Mik a legjobb gyakorlatok az NLA hibák elkerülésére a jövőben?

Miután a közvetlen problémát megoldották, erősítse meg a környezetét, hogy az NLA továbbra is biztonságos és megbízható maradjon.

• Tartsa naprakészen az operációs rendszereket és az RDP klienseket
• Monitorozza a Domain és Identitás Egészséget
• Standardizálja az RDP és NLA irányelveket GPO-n keresztül
• Eseménynapló és biztonsági megfigyelés engedélyezése
• Isolálja az RDP-t biztonságos belépési pontok mögött

Tartsa naprakészen az operációs rendszereket és az RDP klienseket

Tartson fenn egy standard javítási ütemtervet mind a szerverek, mind a végpontok számára. Igazodjon a támogatott Windows verziókhoz, és kerülje az idősebb, javítatlan kliensek termelésben való hagyását. A következetes frissítési alapok csökkentik a CredSSP és TLS eltéréseket, amelyek gyakran megszakítják az NLA-t.

Monitorozza a Domain és Identitás Egészséget

A tartományhoz csatlakozott rendszerek esetében a tartományvezérlő állapotát kezelje az RDP stack részeként. Használjon olyan eszközöket, mint a dcdiag , repadmin és a tartományvezérlő eseménynaplói, hogy korán észleljék a replikációs vagy DNS problémákat. Az időszakos tartományhibák RDP és NLA problémákként jelentkezhetnek, még mielőtt a felhasználók más tüneteket észlelnének.

Standardizálja az RDP és NLA irányelveket GPO-n keresztül

Határozza meg a RDP titkosítás, NLA érvényesítés és CredSSP irányelvek központilag. Alkalmazza őket OU vagy biztonsági csoport szerint az eszközök szerepe alapján, például termelési szerverek és tesztlaborok esetén. A standardizálás csökkenti a konfigurációs eltéréseket, és sokkal gyorsabbá teszi a hibaelhárítást, amikor problémák merülnek fel.

Eseménynapló és biztonsági megfigyelés engedélyezése

Monitor eseménynézőt RDP hosztokon, különösen:

• Windows naplók → Biztonság
• Windows naplók → Rendszer
• Alkalmazások és Szolgáltatások Naplói → Microsoft → Windows → TerminalServices

Korrellálja az ismétlődő sikertelen bejelentkezéseket, TLS kézfogási hibákat vagy CredSSP hibákat a SIEM-jével, ahol lehetséges. Ez a megfigyelés segít megkülönböztetni a konfigurációs problémákat és az aktív támadásokat.

Isolálja az RDP-t biztonságos belépési pontok mögött

Még NLA-val is, az RDP közvetlen internetre való kitettsége magas kockázatot jelent. Helyezze az RDP-t egy biztonságos átjáró, VPN vagy ZTNA-stílusú proxy mögé. Adjon hozzá MFA-t, ahol lehetséges. Az olyan eszközök, mint a TSplus Advanced Security, tovább korlátozhatják, hogy hol, mikor és hogyan csatlakoznak a felhasználók, csökkentve ezzel az NLA-val kapcsolatos események valószínűségét, hogy egyáltalán elérjék a szervert.

Erősítse meg az RDP biztonságát a TSplus Advanced Security segítségével

Az NLA csak a RDP kockázati egyenletének egy részét oldja meg. TSplus Advanced Security további védelmi rétegeket ad a Windows szervereihez és távoli asztalaihoz anélkül, hogy a teljes VDI stackek bonyolultságával kellene foglalkoznia. Az olyan funkciók, mint a dinamikus bruteforce védelem, az IP- és országalapú korlátozások, a munkaidő politikák és az alkalmazás szintű hozzáférési szabályok segítenek megakadályozni a támadókat, miközben a jogos felhasználók produktívak maradnak.

A RDP-re támaszkodó, de erősebb, egyszerűbb biztonsági intézkedéseket kereső szervezetek számára az NLA párosítása a TSplus Advanced Security praktikus módot kínál a távoli hozzáférés megerősítésére és az incidensválasz munkaterhelés csökkentésére.

Következtetés

Az NLA hibák az RDP-ben frusztrálóak, különösen, amikor nyilvánvaló környezeti változások nélkül jelentkeznek. A valóságban szinte mindig konkrét problémákra utalnak az operációs rendszer verzióiban, a domain kapcsolódásban, a CredSSP javításában, a TLS konfigurációban vagy a biztonsági politikákban. Egy strukturált ellenőrzőlista segítségével helyreállíthatja a biztonságos hozzáférést kockázatos állandó megoldások igénybevétele nélkül.

A NLA-t alapvető biztonsági intézkedésként kezelje, ne pedig opcionális funkcióként. Tartsa bekapcsolva, érvényesítse és figyelje, mint a távoli hozzáférés általános helyzetének részét. Amikor szüksége van a letiltására, korlátozza a hatósugarat, javítsa ki az alapvető problémát, és kapcsolja vissza a NLA-t, amint lehetséges.