Kvifor ein Protected Users-berbar PC treng VPN før pålogging

Ein berbar PC, ein fungerande konto og eit hotellnettverk gjev til saman ei påloggingsløkke som ingen mengd nye forsøk bryt. Kontoen ligg i Protected Users, noko som hindrar Windows i å lagre verifiseraren det ville trengt for å autentisere brukaren fråkopla. Kvar plan av forma «logg på først, kople til tunnelen etterpå» har omvend rekkjefølgje, og vernet gjer nøyaktig det det lovar. Det følgjande føreset ein tradisjonell Active Directory-konto på ein støtta Windows-vert.

Kva vernet faktisk fjernar

Windows lagrar vanlegvis ein verifiserar i cache slik at ein domenekonto kan logge på medan ein domenekontrollar er utilgjengeleg. Protected Users blokkerer dette for kontoen, noko som fjernar fråkopla domenepålogging som moglegheit i staden for å gjere ho upåliteleg.

Dette er ikkje det vanlege problemet med ein utdatert cache, og dei vanlege midla gjeld ikkje. Gjenteken pålogging på nettet, nok eit passordbyte eller auka grense for cacha påloggingar gjenopprettar ikkje evna, fordi ingen av desse handlingane lagar verifiseraren som retningslinja nektar å lagre. Kontoen oppfører seg som designa, og designet føreset at nettverket er til stades når Windows spør. Å handsame symptomet som ein cachefeil er måten team endar med å byggje opp att ein profil som aldri var øydelagd.

Kvifor tunnelen må finnast før skrivebordet

Eininga må nå domeinautentisering i det augneblunken Windows ber om det, og det er før noka brukarøkt finst. Ein VPN-klient som først startar etter at skrivebordet viser seg, lèt ei ny pålogging vente på ein veg som aldri kjem. Avhengnaden høyrer til maskina, ikkje til ein brukar som enno ikkje har logga på.

Bruk ei støtta ordning for pålogging på førehand, avtalt med eigarane av endepunkt og identitet. Ein Always On VPN-einings tunnel autentisert med eit datamaskinsertifikat kvalifiserer når den styrte eininga oppfyller føresetnadene for den utrullinga. Ein leverandør sin støtta integrasjon på påloggingsskjermen er eit anna alternativ. Ein vanleg brukarprofil med ein automatisk utløysar er ingen av delane, uansett kor likt det ser ut i klientgrensesnittet.

Den vegen treng namneoppslag for domenet, ein tilgjengeleg domenekontrollar og dei autentiseringsprotokollane kontoen kan bruke, og ingen indikator for «tilkopla» gjev noko av dette. Rutene og filtera bør bere identitetstenestene og ingenting anna som ikkje er naudsynt, fordi den prefikslista er flata ei stjålen berbar PC får før nokon loggar på. Avgjerder om delt tunnel tekne for brukartunnelen gjeld ikkje for einingstunnelen, så gå gjennom dei to kvar for seg.

Tilgjenge er ikkje autentiseringskompatibilitet

Ein tunnel kan frakte pakkar perfekt medan domeinautentisering mislukkast, fordi mekanismen som blir prøvd er ein kontoen ikkje kan bruke. I eit domene som handhevar avgrensingane til gruppa, er NTLM utilgjengeleg for medlemene, og Kerberos krev ein AES-kompatibel konto og konfigurasjon. Ein pakkeveg kan ikkje reparere nokon av dei. Difor er ein rein ping til ein domenekontrollar ikkje prov på at pålogginga vil verke.

Det kan også vere to legitimasjonssystem i spel. VPN kan autentisere mot ein identitetsleverandør medan Windows separat treng ei domenepålogging, og aksepten frå den første seier ingenting om den andre. «VPN-en er tilkopla» og «brukaren er logga på» er separate observasjonar, og å rette den eine inneber ikkje den andre.

Les autentiseringsprova

Samle hendingar frå klienten og frå ein domenekontrollar for det same forsøket, ikkje berre frå éi side. Protected Users-loggene ligg under Applications and Services Logs\Microsoft\Windows\Authentication, og ein administrator må kanskje slå på ein logg før han registrerer noko. Korrelér tidstempla med tilkopingsloggen til tunnelen sjølv, fordi ein rekkjefølgjefeil ser ut som ein legitimasjonsfeil frå båe sider.

Den første kommandoen nedanfor listar alle autentiseringsloggar eininga eksponerer, slik at du les den som finst i staden for den eit blogginnlegg namngav. Den andre les nylege oppføringar når du kjenner namnet. Sjå etter autentiseringspakken, kontoen og feilvilkåret, fordi ein manglande nettverksveg og ein avvist mekanisme lèt etter seg ulike prov, og berre éin av dei er eit VPN-problem. Viss tunnelen kom opp etter forsøket, var rekkjefølgja feil uansett kva desse oppføringane seier.

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

Prov grensa frå ein kaldstart

Køyr testen frå ein utlogga eller nettopp starta tilstand med ein avgrensa konto, og hald ein godkjend gjenopprettingsveg open før du endrar noko for privilegerte brukarar. Ein test på eit skrivebord som alt køyrer, utøver ingen del av kodevegen som betyr noko, og det forklarer dei fleste rapportane om ei retting som heldt til neste omstart. Arbeid deg deretter gjennom dei fire trinna i denne rekkjefølgja.

1. Stadfest at eininga kan finne ein domenekontrollar før nokon loggar på, med nltest /dsgetdc:corp.example.com.
2. Forsøk domenepålogginga, og spør deretter om det vart henta ein billett i det heile, med klist.
3. Les autentiseringsloggen eininga registrerer, med dei to kommandoane ovanfor, og noter pakken og feilvilkåret.
4. Stadfest at den godkjende gjenopprettingslegitimasjonen enno verkar frå påloggingsskjermen, fordi det er den einaste vegen tilbake viss grensetesten mislukkast.

Å opne ein filutveksling med medsende legitimasjon lagar heller ikkje ei fråkopla interaktiv pålogging, så det erstattar ikkje noko trinn ovanfor. Viss organisasjonen verkeleg treng pålogging utan samband, er svaret eit kompatibelt design for konto og endepunkt som er valt medvite. Å ta kontoen ut av gruppa, eller å halde éi ubegrensa naudpålogging på kvar berbar PC, er ei identitetspolitisk avgjerd som ei VPN-endring ikkje kan ta for dykk.

Dokumentasjonen for Protected Users skildrar både åtferda til verifiseraren og domenebegrensingane dette designet er avhengig av. Planlegg gjenopprettingsprosessen før nokon reiser, fordi kaldstartstesten er den einaste staden han blir utøvd.