Bakit kailangan ng laptop na Protected Users ang VPN bago mag-sign in

Ang laptop, gumaganang account at network ng hotel ay sama-samang bumubuo ng paikot na pag-sign in na walang paulit-ulit na pagtatangka ang makakasira. Ang account ay nasa Protected Users, na pumipigil sa Windows na iimbak ang beripikador na kakailanganin nito upang ma-authenticate ang gumagamit nang offline. Anumang plano na may anyong «mag-sign in muna, pagkatapos ikonekta ang tunnel» ay baligtad ang pagkakasunod-sunod, at ginagawa ng proteksyon ang eksaktong ipinangako nito. Ipinapalagay ng sumusunod ang tradisyonal na account ng Active Directory sa sinusuportahang host ng Windows.

Ano ang talagang inaalis ng proteksyon

Karaniwang nagsi-cache ang Windows ng beripikador upang makapag-sign in ang account ng domain habang hindi maabot ang controller ng domain. Hinaharangan ito ng Protected Users para sa account, na nag-aalis ng offline na pag-sign in sa domain bilang posibilidad sa halip na gawin itong hindi mapagkakatiwalaan.

Hindi ito ang karaniwang problema ng lumang cache, at hindi naaangkop ang karaniwang lunas. Ang paulit-ulit na pag-sign in online, isa pang pagpapalit ng password o pagtataas ng bilang ng mga naka-cache na pag-sign in ay hindi magbabalik ng kakayahan, dahil wala sa mga aksiyong iyon ang lumilikha ng beripikador na tinatanggihan ng patakaran na iimbak. Kumikilos ang account ayon sa disenyo, at ipinapalagay ng disenyo na naroon ang network kapag hiniling ito ng Windows. Ang pagtrato sa sintomas bilang sira ng cache ang paraan kung paano nagtatapos ang mga koponan sa muling pagtatayo ng profile na hindi naman nasira.

Bakit dapat mayroon nang tunnel bago ang desktop

Dapat maabot ng device ang pagpapatunay ng domain sa sandaling hiniling ito ng Windows, at iyon ay bago pa umiral ang anumang sesyon ng gumagamit. Ang kliyenteng VPN na nagsisimula lamang pagkatapos lumitaw ang desktop ay nag-iiwan ng bagong pag-sign in na naghihintay sa landas na hindi dumarating. Ang pag-asa ay pag-aari ng makina, hindi ng gumagamit na hindi pa nakapag-sign in.

Gumamit ng sinusuportahang kaayusan bago mag-sign in na napagkasunduan sa mga may-ari ng endpoint at identidad. Ang tunnel ng device na Always On VPN na na-authenticate sa sertipiko ng computer ay karapat-dapat kapag natutugunan ng pinamamahalaang device ang mga paunang kondisyon ng deployment na iyon. Ang sinusuportahang integrasyon ng screen ng pag-sign in mula sa vendor ay isa pang pagpipilian. Ang ordinaryong profile ng gumagamit na may awtomatikong trigger ay wala sa dalawa, gaano man ito magkamukha sa interface ng kliyente.

Kailangan ng landas na iyon ng resolusyon ng pangalan para sa domain, maabot na controller ng domain at mga protocol ng pagpapatunay na maaaring gamitin ng account, at wala sa mga ito ang ibinibigay ng tagapagpahiwatig na «konektado». Dapat dalhin ng mga ruta at filter nito ang mga serbisyo ng identidad at wala nang iba pang hindi kailangan, dahil ang listahan ng prefix na iyon ang ibabaw na nakukuha ng ninakaw na laptop bago mag-sign in ang sinuman. Ang mga desisyon sa split tunnel na ginawa para sa tunnel ng gumagamit ay hindi naaangkop sa tunnel ng device, kaya suriin ang dalawa nang hiwalay.

Ang maabot ay hindi pagiging tugma ng pagpapatunay

Maaaring perpektong magdala ng mga packet ang tunnel habang nabibigo ang pagpapatunay ng domain, dahil ang mekanismong sinusubukan ay isa na hindi maaaring gamitin ng account. Sa domain na nagpapatupad ng mga paghihigpit ng grupo, hindi available ang NTLM sa mga miyembro at nangangailangan ang Kerberos ng account at configuration na tugma sa AES. Hindi kayang ayusin ng landas ng packet ang alinman sa dalawa. Iyon ang dahilan kung bakit ang malinis na ping sa controller ng domain ay hindi patunay na gagana ang pag-sign in.

Maaaring may dalawang sistema ng kredensyal na gumagana. Maaaring mag-authenticate ang VPN sa isang provider ng identidad habang ang Windows ay hiwalay na nangangailangan ng logon sa domain, at ang pagtanggap ng una ay walang sinasabi tungkol sa pangalawa. Ang «konektado ang VPN» at «naka-sign in ang gumagamit» ay magkahiwalay na obserbasyon, at ang pag-aayos ng isa ay hindi nangangahulugan ng isa pa.

Basahin ang ebidensiya ng pagpapatunay

Kolektahin ang mga pangyayari mula sa kliyente at mula sa controller ng domain para sa parehong pagtatangka, hindi lamang sa isang panig. Ang mga log ng Protected Users ay nasa ilalim ng Applications and Services Logs\Microsoft\Windows\Authentication, at maaaring kailanganin ng administrator na buksan ang isang log bago ito magtala ng anuman. Iugnay ang mga timestamp sa log ng koneksyon ng tunnel mismo, dahil ang pagkakamali sa pagkakasunod-sunod ay mukhang sira ng kredensyal mula sa magkabilang panig.

Ang unang utos sa ibaba ay naglilista ng bawat log ng pagpapatunay na inilalantad ng device, kaya binabasa mo ang umiiral at hindi ang pinangalanan ng isang post sa blog. Ang pangalawa ay nagbabasa ng mga kamakailang entry kapag alam mo na ang pangalan. Hanapin ang pakete ng pagpapatunay, ang account at ang kundisyon ng pagkabigo, dahil ang nawawalang landas ng network at tinanggihang mekanismo ay nag-iiwan ng magkaibang ebidensiya at isa lamang sa kanila ang problema sa VPN. Kung umakyat ang tunnel pagkatapos ng pagtatangka, mali ang pagkakasunod-sunod anuman ang sabihin ng mga entry na iyon.

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

Patunayan ang hangganan mula sa malamig na boot

Patakbuhin ang pagsubok mula sa naka-sign out o bagong boot na estado na may limitadong account, at panatilihing bukas ang inaprubahang landas ng pagbawi bago baguhin ang anuman para sa mga pribilehiyadong gumagamit. Ang pagsubok sa desktop na tumatakbo na ay hindi nagsasanay ng anumang bahagi ng landas ng code na mahalaga, at iyon ang nagpapaliwanag sa karamihan ng mga ulat tungkol sa pagwawasto na tumagal hanggang sa susunod na reboot. Pagkatapos ay dumaan sa apat na hakbang sa ayos na ito.

1. Kumpirmahin na makakahanap ang device ng controller ng domain bago mag-sign in ang sinuman, gamit ang nltest /dsgetdc:corp.example.com.
2. Subukan ang logon sa domain, pagkatapos ay itanong kung may nakuha mang ticket, gamit ang klist.
3. Basahin ang log ng pagpapatunay na itinatala ng device, gamit ang dalawang utos sa itaas, at itala ang pakete at kundisyon ng pagkabigo.
4. Kumpirmahin na gumagana pa rin ang inaprubahang kredensyal sa pagbawi mula sa screen ng pag-sign in, dahil iyon lamang ang daan pabalik kung mabibigo ang pagsubok sa hangganan.

Ang pagbukas ng file share gamit ang ibinigay na kredensyal ay hindi rin lumilikha ng offline na interactive na logon, kaya hindi ito kapalit ng alinman sa mga hakbang sa itaas. Kung talagang kailangan ng organisasyon ang pag-sign in na walang koneksyon, ang sagot ay isang tugmang disenyo ng account at endpoint na sadyang pinili. Ang pag-alis ng account sa grupo, o pagpapanatili ng isang walang limitasyong emergency na login sa bawat laptop, ay desisyon sa patakaran ng identidad na hindi kayang kunin ng pagbabago sa VPN para sa iyo.

Ang dokumentasyon ng Protected Users ay naglalarawan ng pag-uugali ng beripikador at ng mga paghihigpit ng domain na pinagbabatayan ng disenyong ito. Planuhin ang proseso ng pagbawi bago maglakbay ang sinuman, dahil ang pagsubok sa malamig na boot ang tanging lugar kung saan ito sinasanay.