Proč notebook s Protected Users potřebuje VPN ještě před přihlášením

Notebook, funkční účet a hotelová síť dohromady vytvářejí smyčku přihlašování, kterou žádné opakování nepřeruší. Účet je v Protected Users, což brání Windows uložit ověřovatel, který by potřeboval k ověření uživatele offline. Každý plán typu „nejdřív se přihlaste, potom připojte tunel“ má obrácené pořadí a ochrana dělá přesně to, co slibuje. Následující text předpokládá tradiční účet Active Directory na podporovaném hostiteli Windows.

Co ochrana ve skutečnosti odstraňuje

Windows obvykle ukládá ověřovatel do mezipaměti, aby se účet domény mohl přihlásit, i když je řadič domény nedostupný. Protected Users to pro účet blokuje, čímž odstraňuje offline přihlášení do domény jako možnost, místo aby ho činilo nespolehlivým.

Nejde o obvyklý problém se zastaralou mezipamětí a obvyklé prostředky tu neplatí. Opakované přihlašování online, další změna hesla nebo zvýšení počtu uložených přihlášení schopnost neobnoví, protože žádná z těchto akcí nevytváří ověřovatel, který politika odmítá uložit. Účet se chová tak, jak byl navržen, a návrh předpokládá, že síť je k dispozici, když se Windows zeptá. Léčit příznak jako závadu mezipaměti je cesta, kterou týmy přestavují profil, který nikdy nebyl poškozen.

Proč musí tunel existovat před plochou

Zařízení se musí dostat k ověření domény v okamžiku, kdy o ně Windows požádají, což je dřív, než existuje jakákoli uživatelská relace. Klient VPN, který se spouští až po objevení plochy, nechává nové přihlášení čekat na cestu, která nikdy nepřijde. Závislost patří stroji, ne uživateli, který se ještě nepřihlásil.

Použijte podporované uspořádání přihlášení před přihlášením dohodnuté s vlastníky koncových bodů a identit. Tunel zařízení Always On VPN ověřený certifikátem počítače vyhovuje, pokud spravované zařízení splňuje předpoklady tohoto nasazení. Podporovaná integrace dodavatele s přihlašovací obrazovkou je další možností. Běžný uživatelský profil s automatickým spouštěčem není ani jedno, ať už v rozhraní klienta vypadá jakkoli podobně.

Této cestě je potřeba překlad názvů pro doménu, dostupný řadič domény a protokoly ověřování, které účet smí používat, a nic z toho indikátor „připojeno“ neposkytuje. Její trasy a filtry mají přenášet služby identity a nic dalšího, co není nutné, protože tento seznam prefixů je plocha, kterou ukradený notebook získá, než se kdokoli přihlásí. Rozhodnutí o rozděleném tunelu přijatá pro uživatelský tunel se na tunel zařízení nepřenášejí, proto je posuzujte odděleně.

Dostupnost není kompatibilita ověřování

Tunel může dokonale přenášet pakety, zatímco ověření domény selhává, protože zkoušený mechanismus je ten, který účet nesmí použít. V doméně, která vynucuje omezení skupiny, není NTLM pro členy dostupné a Kerberos vyžaduje účet a konfiguraci kompatibilní s AES. Paketová cesta nemůže opravit ani jedno. Proto čistý ping na řadič domény není důkazem, že přihlášení bude fungovat.

Ve hře mohou být i dva systémy přihlašovacích údajů. VPN se může ověřovat u poskytovatele identity, zatímco Windows odděleně potřebuje přihlášení do domény, a přijetí prvního nic neříká o druhém. „VPN se připojila“ a „uživatel je přihlášen“ jsou oddělená pozorování a oprava jednoho neznamená druhé.

Přečtěte si důkazy ověřování

Sbírejte události z klienta i z řadiče domény pro tentýž pokus, ne jen z jedné strany. Protokoly Protected Users jsou v Applications and Services Logs\Microsoft\Windows\Authentication a správce možná musí protokol zapnout, než něco zaznamená. Spojte časová razítka s vlastním protokolem připojení tunelu, protože chyba pořadí vypadá z obou stran jako závada údajů.

První příkaz níže vypíše všechny protokoly ověřování, které zařízení zpřístupňuje, takže čtete ten, který existuje, a ne ten, který pojmenoval nějaký blogový příspěvek. Druhý čte nedávné položky, jakmile znáte název. Hledejte balíček ověřování, účet a podmínku selhání, protože chybějící síťová cesta a odmítnutý mechanismus zanechávají různé důkazy a jen jeden z nich je problém VPN. Pokud se tunel zvedl až po pokusu, pořadí bylo špatné, ať ty položky říkají cokoli.

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

Dokažte hranici ze studeného startu

Proveďte test z odhlášeného nebo čerstvě nastartovaného stavu s omezeným účtem a před změnou čehokoli pro privilegované uživatele mějte otevřenou schválenou cestu obnovy. Test na již běžící ploše neprocvičí žádnou část cesty kódu, na které záleží, a to vysvětluje většinu hlášení o opravě, která vydržela do dalšího restartu. Potom projděte čtyři kroky v tomto pořadí.

1. Potvrďte, že zařízení najde řadič domény, než se kdokoli přihlásí, pomocí nltest /dsgetdc:corp.example.com.
2. Zkuste přihlášení do domény a pak se zeptejte, zda byl vůbec získán tiket, pomocí klist.
3. Přečtěte protokol ověřování, který zařízení zaznamenává, dvěma příkazy výše, a poznamenejte balíček a podmínku selhání.
4. Potvrďte, že schválený záložní údaj stále funguje z přihlašovací obrazovky, protože to je jediná cesta zpět, pokud test hranice selže.

Otevření sdílené složky s dodanými údaji také nevytváří offline interaktivní přihlášení, takže nenahrazuje žádný krok výše. Pokud organizace skutečně potřebuje přihlášení bez připojení, odpovědí je kompatibilní návrh účtu a koncových bodů zvolený záměrně. Vyřazení účtu ze skupiny nebo ponechání jednoho neomezeného nouzového přihlášení na každém notebooku je rozhodnutí o politice identity, které za vás změna VPN nemůže udělat.

Dokumentace k Protected Users popisuje jak chování ověřovatele, tak omezení domény, na nichž tento návrh závisí. Naplánujte proces obnovy dřív, než někdo vycestuje, protože test studeného startu je jediné místo, kde se procvičuje.