NLA-virheet RDP: Syyt, korjaukset ja parhaat käytännöt

Johdanto

Verkkotason todennus (NLA) on keskeinen turvallisuusohjaus Remote Desktop Protocolissa, joka estää todennetut käyttäjät ennen kuin täysi istunto luodaan. Kun NLA epäonnistuu, IT-tiimit kohtaavat estettyjä kirjautumisia, epämääräisiä virheilmoituksia ja turhautuneita loppukäyttäjiä, jotka eivät pääse kriittisiin palvelimiin. Tämä opas selittää, mitä NLA on, miksi näitä virheitä esiintyy ja miten NLA-ongelmia voidaan järjestelmällisesti vianetsitä ja ratkaista heikentämättä RDP-turvallisuusasetustasi.

Mikä on NLA RDP:ssä?

Verkkotason todennus on RDP:n turvallisuuden parannus, joka esiteltiin Windows Vistan ja Windows Server 2008:n myötä. Sen sijaan, että rakennettaisiin koko etätyöpöytäistunto ja sitten pyydettäisiin käyttäjätietoja, NLA vaatii käyttäjiä todentamaan itsensä ensin. Vasta onnistuneen todennuksen jälkeen RDP-pino luo graafisen istunnon.

NLA luottaa CredSSP:hen (Credential Security Support Provider) käyttäjätietojen turvalliseen siirtämiseen kohdejärjestelmään. Verkkotunnukseen liittyvissä ympäristöissä CredSSP kommunikoi Active Directoryn kanssa varmistaakseen tilin ennen istunnon aloittamista. Itsenäisillä tai työryhmäisillä isännillä CredSSP vahvistaa etäkirjautumiseen määritellyt paikalliset tilit.

NLA:n keskeiset edut ovat:

• RDP-päätteiden altistuneiden brute-force- ja palvelunestohyökkäysten ikkunan vähentäminen
• Mahdollistaminen yksittäinen kirjautuminen (Single-Sign On) verkkotunnuksen käyttäjille, parantaen käyttäjäkokemusta
• Suorituskyvyn parantaminen suorittamalla todennus ennen istunnon luomista

Kuitenkin, NLA on herkkä käyttöjärjestelmäversioille, päivityksille, TLS konfigurointi ja verkkotunnuksen terveys. Kun jokin näistä edellytyksistä epäonnistuu, NLA voi estää voimassa olevat yhteydet kokonaan.

Mitä ovat NLA-virheiden yleiset oireet RDP:ssä?

NLA:han liittyvät ongelmat ilmenevät yleensä samankaltaisilla viesteillä, riippumatta taustalla olevasta syystä. Kohtaat todennäköisesti NLA-ongelman, jos kohtaat:

• Etäkäyttöön tarvitaan verkon tason todennus (NLA), mutta tietokoneesi ei tue sitä.
• "Kirjautumisvirhe on tapahtunut. Pyydetty toimintoa ei tueta."
• CredSSP-salausorakkeen korjausvirhe.
• Käyttäjätunnuksesi eivät toimineet.
• Aikakatkaisut tai äkilliset katkokset alkuperäisessä RDP-kättelyssä tai heti kirjautumistietojen syöttämisen jälkeen

Nämä oireet voivat vaikuttaa sekä verkkotunnukseen liitettyihin että itsenäisiin isäntiin. Käytännössä ne johtuvat usein yhteensopimattomista tietoturvapolitiikoista, estetystä verkkotunnuksen ohjaimen pääsystä tai vanhentuneista RDP-komponenteista kummallakin puolella.

Mitä ovat NLA-virheiden syyt RDP:ssä?

Ymmärtäminen yleisistä juurisyistä auttaa sinua vianetsimään nopeasti ja välttämään riskialttiita kiertoteitä, kuten NLA:n pysyvää poistamista käytöstä.

• Asiakas- tai palvelin-Käyttöjärjestelmän yhteensopimattomuus
• Verkkotunnuksen ohjauspalvelin ei saavutettavissa
• CredSSP-päivityksen yhteensopimattomuus
• TLS- tai RDP-salausvirheellinen konfigurointi
• Ryhmän politiikka tai rekisterin ristiriidat
• Viatut käyttäjäprofiilit tai tunnistetiedot
• Työryhmä- ja ei-alueen skenaariot

Asiakas- tai palvelin-Käyttöjärjestelmän yhteensopimattomuus

Vanhemmat Windows-versiot tai kolmannen osapuolen RDP-asiakkaat eivät välttämättä tue NLA:ta tai nykyaikaista CredSSP-käyttäytymistä täysin. Esimerkiksi vanhat Windows XP- tai varhaiset Vista-versiot eivät voi muodostaa yhteyttä NLA:n pakottamiin palvelimiin ilman erityisiä päivityksiä. Jopa tuetuilla järjestelmillä vanhentuneet RDP-asiakasohjelmat voivat aiheuttaa "tietokoneesi ei tue NLA:ta" -virheitä, vaikka käyttöjärjestelmä nimellisesti tukisi sitä.

Verkkotunnuksen ohjauspalvelin ei saavutettavissa

Verkko-osoitteeseen liittyvässä ympäristössä NLA riippuu pääsyssä verkkotunnuksen ohjaimeen varmistaakseen käyttöoikeudet ja ylläpitääkseen koneen turvallista kanavaa. Jos verkkotunnuksen ohjain on offline-tilassa, estettynä palomuuri tai luottamusongelman vuoksi NLA-todennus voi epäonnistua, vaikka palvelin itsessään olisi toiminnassa. Näet usein virheitä, joissa mainitaan verkkotunnuksen ohjaimen yhteys tai yleisiä "todennusvirhe on tapahtunut" -viestejä.

CredSSP-päivityksen yhteensopimattomuus

Aloittaen vuoden 2018 "Salaus Oracle Korjaus" päivityksistä, CredSSP tuli tiukemmaksi sen suhteen, miten käyttäjätietoja suojataan. Jos asiakkaalla on päivitys, mutta palvelimella ei ole (tai päinvastoin), kaksi päätepistettä eivät välttämättä sovi yhteen turvallisen kokoonpanon osalta. Tämä yhteensopimattomuus voi aiheuttaa "CredSSP salaus oracle korjaus" virheitä ja estää NLA-kirjautumiset, kunnes molemmat osapuolet on korjattu tai ryhmäkäytäntöä on säädetty.

TLS- tai RDP-salausvirheellinen konfigurointi

NLA luottaa kuljetustason turvallisuuteen (TLS) suojaamaan tunnistetietojen vaihtoa. Jos TLS 1.0/1.1 on poistettu käytöstä ilman, että TLS 1.2 on oikein otettu käyttöön, tai jos heikkoja salausprotokollia pakotetaan, asiakas- ja palvelinpuolen välinen kättely voi epäonnistua ennen kuin NLA valmistuu. Mukautettu turvallisuuden koventaminen, FIPS-tila tai väärin konfiguroidut varmenteet voivat kaikki rikkoa NLA:ta, vaikka standardi RDP ilman NLA saattaisi silti toimia tietyissä olosuhteissa.

Ryhmän politiikka tai rekisterin ristiriidat

Ryhmän politiikkaobjektit (GPO) ja paikalliset turvallisuuspolitiikat hallitsevat, miten RDP, CredSSP ja salaus käyttäytyvät. Vastaamattomat tai liian tiukat politiikat voivat pakottaa NLA: n tilanteissa, joissa asiakkaat eivät tue sitä tai vaativat FIPS-yhteensopivia algoritmeja, joita asiakkaasi eivät voi käyttää. Rekisterin ohitukset SCHANNELille tai CredSSP: lle voivat aiheuttaa samanlaisia epäjohdonmukaisuuksia, mikä johtaa "pyydettyä toimintoa ei tueta" ja muihin yleisiin virheisiin.

Viatut käyttäjäprofiilit tai tunnistetiedot

Ajoittain ongelma rajoittuu yhteen käyttäjään tai koneeseen. Vialliset välimuistissa olevat tunnistetiedot, väärin kohdistettu Turvallisuus tunnus (SID) tai vaurioitunut Default.rdp-tiedosto voivat kaikki häiritä NLA-todennusta. Näissä tapauksissa saatat huomata, että toinen käyttäjä voi kirjautua sisään samalta laitteelta, tai sama käyttäjä voi kirjautua sisään eri asiakkaasta, mutta ei molemmat yhdessä.

Työryhmä- ja ei-alueen skenaariot

NLA olettaa ympäristön, jossa käyttäjätunnukset voidaan vahvasti todentaa, tyypillisesti Active Directoryn kautta. Työryhmäjärjestelmissä paikalliset tilit on konfiguroitava huolellisesti ja niillä on oltava lupa kirjautua sisään Remote Desktopin kautta. Jos NLA on pakotettu, mutta verkkotunnuspalvelinta ei ole saatavilla tai paikallisten tilien asetukset ovat virheellisiä, saatat nähdä NLA:han liittyviä virheitä, vaikka palvelin vaikuttaisi olevan saavutettavissa.

Kuinka korjata NLA-virheitä RDP:ssä?

Käytä seuraavia vaiheita järjestyksessä, vähiten tunkeilevasta eniten tunkeilevaan. Tämä lähestymistapa auttaa palauttamaan pääsyn samalla kun säilytetään turvallisuus mahdollisimman paljon.

• Vahvista NLA-tuki asiakas- ja palvelimella
• Varmista yhteys verkkotunnuksen ohjaimeen (jos sovellettavissa)
• Säädä CredSSP-päivitystasot ja -käytännöt
• Ota käyttöön ja vahvista vaaditut TLS-protokollat
• Tarkista ja säädä ryhmäkäytäntöä
• Tilapäisesti poista NLA käytöstä pääsyn palauttamiseksi
• Nollaa RDP-asiakas ja verkkokonfiguraatio

Vahvista NLA-tuki asiakas- ja palvelimella

Ensinnäkin varmista, että molemmat päätepisteet tukevat NLA:ta.

• Suorita winver molemmilla asiakas- ja palvelinpuolella varmistaaksesi, että ne ovat Windows Vista / Windows Server 2008 tai uudempi.
• Varmista, että uusimmat etätyöpöytäasiakas päivitykset on asennettu (Windows Updaten tai Microsoftin etätyöpöytä sovelluksen kautta ei-Windows alustoilla).
• Jos käytät kolmannen osapuolen RDP-asiakkaita, varmista, että NLA-tuki on nimenomaisesti dokumentoitu ja otettu käyttöön asiakkaan asetuksissa.

Jos kumpikaan osapuoli ei tue NLA:ta, suunnittele komponentin päivittäminen tai vaihtaminen sen sijaan, että heikentäisit turvallisuutta globaalisti.

Varmista yhteys verkkotunnuksen ohjaimeen (jos sovellettavissa)

Verkkotunnukseen liitetyillä koneilla varmista verkkotunnuksen yhteys ennen RDP-asetusten muuttamista.

• Testaa perusverkon saavutettavuutta verkkotunnusohjaimiin (esimerkiksi, ping dc01.yourdomain.com ).
• Käytä nltest /dsgetdc:yourdomain.com vahvistaakseen, että asiakas voi löytää verkkotunnuksen ohjaimen.
• PowerShellissa, suorita Testaa-tietokoneen turvallista kanavaa tarkista koneen turvallinen kanava verkkotunnukseen.

Jos suojattu kanava on rikki, korjaa se seuraavalla:

Testaa-TietokoneTurvakanava -Korjaa -Tunnistetiedot (Hae-Tunnistetiedot)

Korjauksen jälkeen käynnistä kone uudelleen, jos kehotetaan, ja testaa NLA uudelleen. Ota huomioon DNS-väärinkonfiguraatiot, palomuurisäännöt tai VPN-ongelmat, jotka saattavat ajoittain estää verkkotunnuksen pääsyn.

Säädä CredSSP-päivitystasot ja -käytännöt

Seuraavaksi varmista, että sekä asiakas että palvelin ovat ajan tasalla turvallisuuspäivityksistä, erityisesti niistä, jotka liittyvät CredSSP:hen.

• Asenna kaikki tärkeät ja turvallisuuspäivitykset molemmille päätepisteille.
• Tarkista, onko ryhmäkäytäntöä käytetty "Encryption Oracle Remediation" -asetuksen määrittämiseen kohdassa:
  Tietokoneen kokoonpano → Hallintamallit → Järjestelmä → Todistusten delegointi .

Tilapäisesti testausympäristössä voit asettaa politiikan sallivammaksi arvoksi varmistaaksesi, että tiukka asetus aiheuttaa epäonnistumisen. Tuotannossa pitkäaikainen ratkaisu tulisi olla kaikkien järjestelmien saattaminen johdonmukaiseen päivitystasoon sen sijaan, että politiikkaa löysennetään pysyvästi.

Ota käyttöön ja vahvista vaaditut TLS-protokollat

Varmista, että TLS 1.2 on tuettu ja käytössä, sillä monet ympäristöt poistavat käytöstä vanhemmat TLS-versiot.

Windows Serverissä tarkista SCHANNEL-asetukset rekisteristä kohdasta:

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

TLS 1.2 -asiakastuen varmistamiseksi, vahvista että:

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

"Enabled"=dword:00000001

Saatat joutua säätämään palvelinpuolen TLS 1.2 -avaimia myös, ja sitten käynnistämään palvelimen uudelleen tai ainakin etätyöpöytäpalvelut. Vahvista myös, että RDP-sertifikaatti on voimassa, luotettu ja ettei se käytä vanhentuneita allekirjoituksia.

Tarkista ja säädä ryhmäkäytäntöä

Ryhmätietopolitiikka on usein paikka, jossa NLA:n täytäntöönpano ja RDP:n turvallisuusasetukset määritellään.

Avaa gpedit.msc tai vastaava GPMC-objekti ja siirry:

Tietokoneen kokoonpano → Windows-asetukset → Tietoturva-asetukset → Paikalliset käytännöt → Tietoturva-vaihtoehdot

Tarkista erityisesti:

• Vaadi käyttäjän todennus etäyhteyksille käyttämällä verkon tason todennusta
• Mikä tahansa käytäntö, joka pakottaa FIPS-yhteensopivia algoritmeja tai rajoittaa salausmuotoja

Varmista, että NLA-valvonta vastaa sitä, mitä asiakkaasi voivat käsitellä. Jos lievennät käytäntöä palauttaaksesi pääsyn, dokumentoi muutos ja aikatauluta aikaa korjata asiakkaiden taustalla olevia ongelmia sen sijaan, että jättäisit heikommat asetukset voimaan määräämättömäksi ajaksi.

Tilapäisesti poista NLA käytöstä pääsyn palauttamiseksi

Jos olet menettänyt kaiken etäyhteyden kriittiseen palvelimeen, NLA:n tilapäinen poistaminen käytöstä voi olla tarpeellinen viimeinen keino.

Voit:

• Käynnistä turvallinen tila verkkoyhteydellä ja säädä etätyöpöydän asetuksia, tai
• Käynnistä palautusmedian avulla, lataa järjestelmäkanta ja muokkaa RDP-Tcp-avainta rekisterissä.

Aseta:

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

"UserAuthentication"=dword:00000000

Tämä poistaa NLA:n käytöstä RDP-kuuntelijalta. Kun saat pääsyn takaisin, korjaa perussyyt (verkkoyhteys, päivitykset, TLS tai politiikat), ja ota sitten NLA uudelleen käyttöön palauttamalla arvo 1:ksi. NLA:n pitämisestä pois käytöstä pitkällä aikavälillä lisää merkittävästi altistumista bruteforce- ja hyväksikäyttöyrityksille.

Nollaa RDP-asiakas ja verkkokonfiguraatio

Jos NLA-ongelmat näyttävät olevan eristyksissä tiettyyn asiakaslaitteeseen, suorita paikallinen nollaus ennen palvelinpolitiikan muuttamista.

• Poista Default.rdp tiedosto sisällä %userprofile%\Documents tyhjentää välimuistissa olevat asetukset.
• Poista ja lisää uudelleen kaikki tallennetut käyttäjätiedot Windowsin tunnistetietojen hallinnassa.
• Vahvista, että TCP 3389 (tai oma RDP-porttisi) on sallittu paikallisten palomuurien ja väliverkkolaitteiden läpi.
• Testi toiselta asiakkaalta samalla verkolla selvittääksesi, onko ongelma asiakaskohtainen vai laajempi.

Tämä yksinkertainen hygieniatoimenpide ratkaisee usein ongelmat, jotka liittyvät vioittuneisiin välimuistissa oleviin tunnistetietoihin tai väärin sovellettuihin näyttö- ja turvallisuusasetuksiin RDP-asiakkaassa.

Mitä ovat parhaat käytännöt NLA-virheiden välttämiseksi tulevaisuudessa?

Kun välitön ongelma on ratkaistu, vahvista ympäristösi, jotta NLA pysyy sekä turvallisena että luotettavana.

• Pidä käyttöjärjestelmät ja RDP-asiakkaat ajan tasalla
• Seuraa verkkotunnuksen ja identiteetin terveyttä
• Standardoi RDP- ja NLA-käytännöt GPO:n kautta
• Ota käyttöön tapahtumaloki ja turvallisuuden valvonta
• Eristä RDP turvallisten sisäänkäyntipisteiden taakse

Pidä käyttöjärjestelmät ja RDP-asiakkaat ajan tasalla

Ylläpidä vakiopäivitysrytmiä sekä palvelimille että päätepisteille. Yhdistele tuettuja Windows-versioita ja vältä vanhojen, päivityksistä jääneiden asiakkaiden jättämistä tuotantoon. Johdonmukaiset päivitysperusteet vähentävät CredSSP- ja TLS-yhteensopimattomuuksia, jotka usein rikkovat NLA:ta.

Seuraa verkkotunnuksen ja identiteetin terveyttä

Verkkotunnukseen liitetyissä järjestelmissä käsittele verkkotunnuspalvelimen terveyttä osana RDP-pinoa. Käytä työkaluja, kuten dcdiag , repadmin ja verkkotunnuksen ohjaimen tapahtumalokit havaitsemaan replikaatio- tai DNS-ongelmia varhaisessa vaiheessa. Satunnaiset verkkotunnusongelmat voivat ilmetä RDP- ja NLA-ongelmina pitkään ennen kuin käyttäjät huomaavat muita oireita.

Standardoi RDP- ja NLA-käytännöt GPO:n kautta

Määritä oma RDP salauksen, NLA-valvonta ja CredSSP-käytännöt keskitetysti. Sovella niitä OU:hun tai turvallisuusryhmään laite-roolien mukaan, kuten tuotantopalvelimet vs. testilaboratoriot. Standardointi vähentää konfigurointipoikkeamia ja nopeuttaa vianetsintää, kun ongelmia ilmenee.

Ota käyttöön tapahtumaloki ja turvallisuuden valvonta

Valvo tapahtumien katselijaa RDP-isännillä, erityisesti:

• Windowsin lokit → Tietoturva
• Windowsin lokit → Järjestelmä
• Sovellukset ja palvelut lokit → Microsoft → Windows → TerminalServices

Korreloi toistuvat epäonnistuneet kirjautumiset, TLS-kädenpuristusvirheet tai CredSSP-virheet SIEM-järjestelmääsi, jos mahdollista. Tämä valvonta auttaa erottamaan konfigurointiongelmat ja aktiiviset hyökkäykset.

Eristä RDP turvallisten sisäänkäyntipisteiden taakse

Vaikka NLA on käytössä, RDP:n suora altistaminen internetille on suuri riski. Aseta RDP turvallisen portin, VPN:n tai ZTNA-tyylisen välityspalvelimen taakse. Lisää MFA mahdollisuuksien mukaan. Työkalut, kuten TSplus Advanced Security, voivat rajoittaa entisestään sitä, missä, milloin ja miten käyttäjät yhdistävät, vähentäen NLA:han liittyvien tapausten todennäköisyyttä, että ne saavuttavat palvelimen lainkaan.

Vahvista RDP-turvallisuutta TSplus Advanced Securityn avulla

NLA ratkaisee vain osan RDP-riskiyhtälöstä. TSplus Advanced Security lisää ylimääräisiä puolustuskerroksia Windows-palvelimiesi ja etätyöpöytiesi ympärille ilman täysimittaisten VDI-pinojen monimutkaisuutta. Ominaisuudet, kuten dynaaminen bruteforce-suojaus, IP- ja maakohtaiset rajoitukset, työaikapolitiikat ja sovellustason käyttöoikeussäännöt auttavat pitämään hyökkääjät ulkona samalla kun lailliset käyttäjät pysyvät tuottavina.

RDP:hen tukeutuville organisaatioille, jotka haluavat vahvempia ja yksinkertaisempia turvallisuusohjauksia, NLA:n yhdistäminen TSplus Advanced Security tarjoaa käytännöllisen tavan vahvistaa etäyhteyksiä ja vähentää tapahtumavasteen työkuormaa.

Päätelmä

NLA-virheet RDP:ssä ovat turhauttavia, erityisesti kun ne ilmestyvät ilman ilmeisiä muutoksia ympäristössä. Todellisuudessa ne lähes aina viittaavat tiettyihin ongelmiin käyttöjärjestelmäversioissa, verkkotunnusyhteydessä, CredSSP-päivityksissä, TLS-konfiguraatiossa tai turvallisuuspolitiikoissa. Käymällä läpi rakenteellista tarkistuslistaa voit palauttaa turvallisen pääsyn turvautumatta riskialttiisiin pysyviin kiertoteihin.

Käsittele NLA:ta perustason turvallisuusohjauksena sen sijaan, että se olisi valinnainen ominaisuus. Pidä se käytössä, validoituna ja valvottuna osana kokonaisvaltaista etäyhteysasennettasi. Kun sinun on tarpeen poistaa se käytöstä, rajoita vaikutusaluetta, korjaa taustalla oleva ongelma ja kytke NLA takaisin päälle mahdollisimman pian.