Zašto prijenosniku s Protected Users treba VPN prije prijave

Prijenosnik, radni račun i hotelska mreža zajedno daju petlju prijave koju nijedno ponovno pokušavanje ne prekida. Račun je u Protected Users, što sprečava Windows da sačuva verifikator koji bi mu trebao za provjeru korisnika bez veze. Svaki plan oblika „prvo se prijavite, pa zatim povežite tunel“ ima obrnut redoslijed, a zaštita radi upravo ono što obećava. Ono što slijedi pretpostavlja tradicionalni Active Directory račun na podržanom Windows hostu.

Šta zaštita zapravo uklanja

Windows obično kešira verifikator kako bi se račun domene mogao prijaviti dok je kontroler domene nedostupan. Protected Users to blokira za račun, čime uklanja prijavu u domenu bez veze kao mogućnost, umjesto da je čini nepouzdanom.

Ovo nije uobičajeni problem sa zastarjelim kešom i uobičajeni lijekovi se ne primjenjuju. Ponovna mrežna prijava, još jedna promjena lozinke ili povećanje broja keširanih prijava neće vratiti sposobnost, jer nijedna od tih radnji ne stvara verifikator koji politika odbija sačuvati. Račun se ponaša kako je dizajniran, a dizajn pretpostavlja da je mreža prisutna kad Windows pita. Tretiranje simptoma kao kvara keša je način na koji timovi obnavljaju profil koji nikada nije bio pokvaren.

Zašto tunel mora postojati prije radne površine

Uređaj mora doći do autentifikacije domene u trenutku kad Windows to zatraži, a to je prije nego što postoji ikakva korisnička sesija. VPN klijent koji se pokreće tek nakon što se pojavi radna površina ostavlja novu prijavu da čeka put koji nikada ne dolazi. Zavisnost pripada mašini, ne korisniku koji se još nije prijavio.

Koristite podržani aranžman prijave prije prijave dogovoren s vlasnicima krajnjih tačaka i identiteta. Tunel uređaja Always On VPN autentifikovan certifikatom računara zadovoljava uslov kada upravljani uređaj ispunjava preduvjete tog raspoređivanja. Podržana integracija dobavljača sa ekranom za prijavu je druga opcija. Običan korisnički profil s automatskim okidačem nije ni jedno ni drugo, koliko god slično izgledalo u sučelju klijenta.

Tom putu treba razrješavanje imena za domenu, dostupan kontroler domene i protokoli autentifikacije koje račun smije koristiti, a ništa od toga ne pruža indikator „povezano“. Njegove rute i filtri trebaju nositi usluge identiteta i ništa drugo što nije potrebno, jer je ta lista prefiksa površina koju ukradeni prijenosnik dobija prije nego se iko prijavi. Odluke o podijeljenom tunelu donesene za korisnički tunel ne prenose se na tunel uređaja, pa ih pregledajte odvojeno.

Dostupnost nije kompatibilnost autentifikacije

Tunel može savršeno prenositi pakete dok autentifikacija domene ne uspijeva, jer je mehanizam koji se pokušava onaj koji račun ne smije koristiti. U domeni koja provodi ograničenja grupe, NTLM nije dostupan članovima, a Kerberos zahtijeva račun i konfiguraciju kompatibilne s AES-om. Put paketa ne može popraviti ni jedno od toga. Zato čist ping do kontrolera domene nije dokaz da će prijava raditi.

Mogu biti u igri i dva sistema akreditiva. VPN se može autentifikovati kod pružaoca identiteta dok Windows odvojeno treba prijavu u domenu, a prihvatanje prvog ne govori ništa o drugom. „VPN se povezao“ i „korisnik je prijavljen“ su odvojena zapažanja, i popravka jednog ne podrazumijeva drugo.

Pročitajte dokaze autentifikacije

Prikupljajte događaje s klijenta i s kontrolera domene za isti pokušaj, a ne samo s jedne strane. Zapisi Protected Users nalaze se pod Applications and Services Logs\Microsoft\Windows\Authentication, a administrator možda mora uključiti zapis prije nego što išta zabilježi. Povežite vremenske oznake s vlastitim zapisom veze tunela, jer greška u redoslijedu izgleda kao kvar akreditiva s obje strane.

Prva naredba ispod navodi svaki zapis autentifikacije koji uređaj izlaže, pa čitate onaj koji postoji, a ne onaj koji je naveo neki blog post. Druga čita nedavne unose kad znate ime. Tražite paket autentifikacije, račun i uslov neuspjeha, jer nedostajući mrežni put i odbijeni mehanizam ostavljaju različite dokaze i samo je jedan od njih VPN problem. Ako se tunel podigao nakon pokušaja, redoslijed je bio pogrešan ma šta ti unosi govorili.

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

Dokažite granicu iz hladnog podizanja

Izvedite test iz odjavljenog ili tek podignutog stanja s ograničenim računom, i držite odobren put oporavka otvorenim prije nego što išta promijenite za privilegovane korisnike. Test na radnoj površini koja već radi ne vježba nijedan dio važne putanje koda, i to objašnjava većinu izvještaja o ispravci koja je držala do sljedećeg restarta. Zatim prođite kroz četiri koraka ovim redom.

1. Potvrdite da uređaj može naći kontroler domene prije nego se iko prijavi, pomoću nltest /dsgetdc:corp.example.com.
2. Pokušajte prijavu u domenu, pa pitajte je li uopšte dobijena karta, pomoću klist.
3. Pročitajte zapis autentifikacije koji uređaj bilježi, dvjema naredbama iznad, i zabilježite paket i uslov neuspjeha.
4. Potvrdite da odobreni rezervni akreditiv još radi s ekrana za prijavu, jer je to jedini put natrag ako test granice ne uspije.

Otvaranje mrežnog udjela s dostavljenim akreditivima također ne stvara interaktivnu prijavu bez veze, pa ne zamjenjuje nijedan korak iznad. Ako organizaciji zaista treba prijava bez veze, odgovor je kompatibilan dizajn računa i krajnje tačke odabran namjerno. Uklanjanje računa iz grupe ili držanje jedne neograničene hitne prijave na svakom prijenosniku odluka je politike identiteta koju promjena VPN-a ne može donijeti umjesto vas.

Dokumentacija za Protected Users opisuje i ponašanje verifikatora i ograničenja domene o kojima ovaj dizajn zavisi. Planirajte proces oporavka prije nego se iko zaputi, jer se test hladnog podizanja vježba samo tamo.