Prečo notebook s Protected Users potrebuje VPN pred prihlásením

Notebook, funkčný účet a hotelová sieť spolu vytvárajú slučku prihlasovania, ktorú nepreruší žiadne opakovanie. Účet je v Protected Users, čo bráni Windows uložiť overovateľ, ktorý by potreboval na overenie používateľa offline. Každý plán typu „najprv sa prihláste, potom pripojte tunel“ má obrátené poradie a ochrana robí presne to, čo sľubuje. Nasledujúce predpokladá tradičný účet Active Directory na podporovanom hostiteľovi Windows.

Čo ochrana v skutočnosti odstraňuje

Windows zvyčajne ukladá overovateľ do vyrovnávacej pamäte, aby sa účet domény mohol prihlásiť, keď je radič domény nedostupný. Protected Users to pre účet blokuje, čím odstraňuje offline prihlásenie do domény ako možnosť namiesto toho, aby ho robilo nespoľahlivým.

Nejde o obvyklý problém so zastaranou vyrovnávacou pamäťou a obvyklé prostriedky tu neplatia. Opakované prihlasovanie online, ďalšia zmena hesla alebo zvýšenie počtu uložených prihlásení schopnosť neobnovia, pretože žiadna z týchto akcií nevytvára overovateľ, ktorý politika odmieta uložiť. Účet sa správa tak, ako bol navrhnutý, a návrh predpokladá, že sieť je k dispozícii, keď sa Windows pýta. Liečiť príznak ako poruchu vyrovnávacej pamäte je cesta, ktorou tímy prepisujú profil, ktorý nikdy nebol pokazený.

Prečo musí tunel existovať pred pracovnou plochou

Zariadenie sa musí dostať k overeniu domény v okamihu, keď o to Windows požiada, a to je pred akoukoľvek používateľskou reláciou. Klient VPN, ktorý sa spustí až po zobrazení pracovnej plochy, necháva nové prihlásenie čakať na cestu, ktorá nikdy nepríde. Závislosť patrí stroju, nie používateľovi, ktorý sa ešte neprihlásil.

Použite podporované usporiadanie prihlásenia pred prihlásením dohodnuté s vlastníkmi koncových bodov a identity. Tunel zariadenia Always On VPN overený certifikátom počítača je vhodný, keď spravované zariadenie spĺňa predpoklady tohto nasadenia. Podporovaná integrácia prihlasovacej obrazovky od dodávateľa je ďalšou možnosťou. Bežný používateľský profil s automatickým spúšťačom nie je ani jedno, nech už v rozhraní klienta vyzerá akokoľvek podobne.

Táto cesta potrebuje preklad názvov pre doménu, dostupný radič domény a protokoly overovania, ktoré účet smie používať, a nič z toho indikátor „pripojené“ neposkytuje. Jej trasy a filtre majú prenášať služby identity a nič ďalšie, čo nie je potrebné, pretože tento zoznam prefixov je plocha, ktorú ukradnutý notebook získa, kým sa niekto prihlási. Rozhodnutia o rozdelenom tuneli prijaté pre používateľský tunel sa na tunel zariadenia neprenášajú, preto ich posudzujte oddelene.

Dostupnosť nie je kompatibilita overovania

Tunel môže dokonale prenášať pakety, kým overenie domény zlyháva, pretože skúšaný mechanizmus je ten, ktorý účet nesmie použiť. V doméne, ktorá vynucuje obmedzenia skupiny, nie je NTLM pre členov dostupné a Kerberos vyžaduje účet a konfiguráciu kompatibilné s AES. Paketová cesta nemôže opraviť ani jedno. Preto čistý ping na radič domény nie je dôkazom, že prihlásenie bude fungovať.

V hre môžu byť aj dva systémy prihlasovacích údajov. VPN sa môže overovať u poskytovateľa identity, kým Windows oddelene potrebuje prihlásenie do domény, a prijatie prvého nehovorí nič o druhom. „VPN sa pripojila“ a „používateľ je prihlásený“ sú oddelené pozorovania a oprava jedného neznamená druhé.

Prečítajte si dôkazy overovania

Zhromažďujte udalosti z klienta aj z radiča domény pre ten istý pokus, nielen z jednej strany. Protokoly Protected Users sú v Applications and Services Logs\Microsoft\Windows\Authentication a správca možno musí protokol zapnúť, kým niečo zaznamená. Spojte časové značky s vlastným protokolom pripojenia tunela, pretože chyba poradia vyzerá z oboch strán ako porucha údajov.

Prvý príkaz nižšie vypíše všetky protokoly overovania, ktoré zariadenie sprístupňuje, takže čítate ten, ktorý existuje, a nie ten, ktorý pomenoval nejaký blogový príspevok. Druhý číta nedávne položky, keď poznáte názov. Hľadajte balík overovania, účet a podmienku zlyhania, pretože chýbajúca sieťová cesta a odmietnutý mechanizmus zanechávajú rôzne dôkazy a len jeden z nich je problém VPN. Ak sa tunel zdvihol až po pokuse, poradie bolo nesprávne, nech tie položky hovoria čokoľvek.

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

Dokážte hranicu zo studeného štartu

Vykonajte test z odhláseného alebo čerstvo naštartovaného stavu s obmedzeným účtom a pred zmenou čohokoľvek pre privilegovaných používateľov majte otvorenú schválenú cestu obnovy. Test na už bežiacej pracovnej ploche neprecvičí žiadnu časť cesty kódu, na ktorej záleží, a to vysvetľuje väčšinu správ o oprave, ktorá vydržala do ďalšieho reštartu. Potom prejdite štyri kroky v tomto poradí.

1. Potvrďte, že zariadenie nájde radič domény skôr, než sa niekto prihlási, pomocou nltest /dsgetdc:corp.example.com.
2. Skúste prihlásenie do domény a potom sa opýtajte, či sa vôbec získal lístok, pomocou klist.
3. Prečítajte protokol overovania, ktorý zariadenie zaznamenáva, dvoma príkazmi vyššie, a poznamenajte balík a podmienku zlyhania.
4. Potvrďte, že schválené záložné prihlasovacie údaje stále fungujú z prihlasovacej obrazovky, pretože to je jediná cesta späť, ak test hranice zlyhá.

Otvorenie zdieľaného priečinka s poskytnutými údajmi tiež nevytvára offline interaktívne prihlásenie, takže nenahrádza žiadny krok vyššie. Ak organizácia skutočne potrebuje prihlásenie bez pripojenia, odpoveďou je kompatibilný návrh účtu a koncového bodu zvolený zámerne. Vyradenie účtu zo skupiny alebo ponechanie jedného neobmedzeného núdzového prihlásenia na každom notebooku je rozhodnutie o politike identity, ktoré za vás zmena VPN nemôže urobiť.

Dokumentácia k Protected Users opisuje ako správanie overovateľa, tak obmedzenia domény, od ktorých tento návrh závisí. Naplánujte proces obnovy skôr, než niekto vycestuje, pretože test studeného štartu je jediné miesto, kde sa precvičuje.