Miks vajab Protected Usersiga sülearvuti VPN-i enne sisselogimist

Sülearvuti, töötav konto ja hotellivõrk annavad kokku sisselogimistsükli, mida ükski korduskatse ei murra. Konto asub jaotises Protected Users, mis takistab Windowsil salvestada kontrollijat, mida oleks vaja kasutaja autentimiseks võrguühenduseta. Iga plaan kujul „kõigepealt logi sisse, seejärel ühenda tunnel“ on vastupidises järjekorras ja kaitse teeb täpselt seda, mida lubab. Järgnev eeldab traditsioonilist Active Directory kontot toetatud Windowsi hostis.

Mida kaitse tegelikult eemaldab

Tavaliselt hoiab Windows kontrollijat vahemälus, et domeenikonto saaks sisse logida ka siis, kui domeenikontroller pole kättesaadav. Protected Users blokeerib selle konto jaoks, mis eemaldab võrguühenduseta domeeni sisselogimise võimalusena, selle asemel et muuta see ebausaldusväärseks.

See ei ole tavaline aegunud vahemälu probleem ja tavalised abinõud ei kehti. Korduv võrguühendusega sisselogimine, veel üks parooli vahetamine või vahemällu salvestatud sisselogimiste arvu suurendamine ei taasta võimet, sest ükski neist toimingutest ei loo kontrollijat, mille salvestamisest poliitika keeldub. Konto käitub nii, nagu on projekteeritud, ja projekt eeldab, et võrk on olemas siis, kui Windows seda küsib. Sümptomi käsitlemine vahemälu rikkena on viis, kuidas meeskonnad ehitavad uuesti üles profiili, mis ei olnud kunagi katki.

Miks peab tunnel eksisteerima enne töölauda

Seade peab jõudma domeeni autentimiseni hetkel, mil Windows seda nõuab, ja see on enne mis tahes kasutajaseansi olemasolu. VPN-klient, mis käivitub alles pärast töölaua ilmumist, jätab värske sisselogimise ootama teed, mis kunagi ei saabu. Sõltuvus kuulub masinale, mitte kasutajale, kes pole veel sisse loginud.

Kasutage toetatud sisselogimiseelset lahendust, mis on kokku lepitud lõpp-punktide ja identiteedi omanikega. Arvuti sertifikaadiga autenditud Always On VPN seadme tunnel sobib, kui hallatav seade vastab selle juurutuse eeldustele. Tootja toetatud sisselogimisekraani integratsioon on teine võimalus. Automaatse käivitiga tavaline kasutajaprofiil ei ole kumbki, ükskõik kui sarnane see kliendi liideses välja näeb.

See tee vajab domeeni jaoks nimelahendust, kättesaadavat domeenikontrollerit ja autentimisprotokolle, mida konto tohib kasutada, ning ühtki neist ei anna märge „ühendatud“. Selle marsruudid ja filtrid peaksid kandma identiteediteenuseid ja mitte midagi muud mittevajalikku, sest see eesliidete loend on pind, mille varastatud sülearvuti saab enne, kui keegi sisse logib. Kasutaja tunneli jaoks tehtud split-tunneli otsused ei kandu üle seadme tunnelile, seega vaadake mõlemat eraldi.

Kättesaadavus ei ole autentimise ühilduvus

Tunnel võib pakette laitmatult kanda, samal ajal kui domeeni autentimine ebaõnnestub, sest proovitav mehhanism on selline, mida konto ei tohi kasutada. Domeenis, mis rakendab grupi piiranguid, ei ole NTLM liikmetele saadaval ja Kerberos vajab AES-iga ühilduvat kontot ja seadistust. Paketitee ei saa kumbagi parandada. Seetõttu ei ole puhas ping domeenikontrollerile tõestus, et sisselogimine hakkab tööle.

Mängus võib olla ka kaks volituste süsteemi. VPN võib autentida identiteedipakkuja vastu, samal ajal kui Windows vajab eraldi domeeni sisselogimist, ja esimese aktsepteerimine ei ütle teise kohta midagi. „VPN ühendus“ ja „kasutaja on sisse loginud“ on eraldi tähelepanekud ning ühe parandamine ei tähenda teist.

Lugege autentimise tõendeid

Koguge sündmusi kliendist ja domeenikontrollerist sama katse kohta, mitte ainult ühelt poolelt. Protected Usersi logid asuvad jaotises Applications and Services Logs\Microsoft\Windows\Authentication ja administraatoril võib tulla logi enne sisse lülitada, kui see midagi salvestab. Korreleerige ajatemplid tunneli enda ühenduslogiga, sest järjekorra viga näeb mõlemalt poolt välja nagu volituste rike.

Esimene käsk allpool loetleb kõik autentimislogid, mida seade pakub, nii et loete seda, mis on olemas, mitte seda, mille nimetas mõni blogipostitus. Teine loeb hiljutisi kirjeid, kui nimi on teada. Otsige autentimispaketti, kontot ja ebaõnnestumise tingimust, sest puuduv võrgutee ja tagasilükatud mehhanism jätavad erinevad tõendid ning ainult üks neist on VPN-i probleem. Kui tunnel tõusis alles pärast katset, oli järjekord vale, ükskõik mida need kirjed ütlevad.

Get-WinEvent -ListLog *Authentication*
Get-WinEvent -LogName Microsoft-Windows-Authentication/Operational -MaxEvents 20

Tõestage piir külmkäivitusest

Tehke katse väljalogitud või värskelt käivitatud olekust piiratud kontoga ja hoidke kinnitatud taastetee avatuna, enne kui muudate privilegeeritud kasutajate jaoks midagi. Juba töötaval töölaual tehtud katse ei harjuta ühtki olulise kooditee osa ja see seletab enamikku teateid paranduse kohta, mis pidas vastu järgmise taaskäivituseni. Seejärel läbige neli sammu selles järjekorras.

1. Kinnitage, et seade leiab domeenikontrolleri enne, kui keegi sisse logib, käsuga nltest /dsgetdc:corp.example.com.
2. Proovige domeeni sisselogimist ja küsige seejärel, kas pilet üldse saadi, käsuga klist.
3. Lugege autentimislogi, mida seade salvestab, kahe ülaltoodud käsuga, ning märkige pakett ja ebaõnnestumise tingimus.
4. Kinnitage, et kinnitatud taastamisvolitus töötab endiselt sisselogimisekraanilt, sest see on ainus tee tagasi, kui piirikatse ebaõnnestub.

Failijagamise avamine antud volitustega ei loo samuti võrguühenduseta interaktiivset sisselogimist, seega ei asenda see ühtki ülaltoodud sammu. Kui organisatsioon vajab tõesti ühenduseta sisselogimist, on vastuseks ühilduv konto- ja lõpp-punkti disain, mis on valitud teadlikult. Konto grupist väljavõtmine või ühe piiramatu hädasisselogimise hoidmine igas sülearvutis on identiteedipoliitika otsus, mida VPN-i muudatus teie eest teha ei saa.

Protected Usersi dokumentatsioon kirjeldab nii kontrollija käitumist kui ka domeenipiiranguid, millest see disain sõltub. Planeerige taasteprotsess enne, kui keegi reisib, sest külmkäivituse katse on ainus koht, kus seda harjutatakse.