Kāpēc Protected Users klēpjdatoram pirms pieteikšanās vajadzīgs VPN

Klēpjdators, strādājošs konts un viesnīcas tīkls kopā veido pieteikšanās cilpu, ko nesalauž neviens atkārtots mēģinājums. Konts atrodas Protected Users, kas neļauj Windows saglabāt pārbaudītāju, kas būtu vajadzīgs lietotāja autentifikācijai bezsaistē. Jebkurš plāns formā «vispirms pieteikties, pēc tam pievienot tuneli» ir ar apgrieztu secību, un aizsardzība dara tieši to, ko sola. Turpmākais pieņem tradicionālu Active Directory kontu atbalstītā Windows resursdatorā.

Ko aizsardzība patiešām noņem

Parasti Windows kešatmiņā glabā pārbaudītāju, lai domēna konts varētu pieteikties, kamēr domēna kontrolieris nav sasniedzams. Protected Users to bloķē kontam, kas noņem bezsaistes domēna pieteikšanos kā iespēju, tā vietā lai padarītu to neuzticamu.

Šī nav ierastā novecojušas kešatmiņas problēma, un ierastie līdzekļi šeit neattiecas. Atkārtota pieteikšanās tiešsaistē, vēl viena paroles maiņa vai kešatmiņā saglabāto pieteikšanos skaita palielināšana neatjaunos spēju, jo neviens no šiem darbiem neveido pārbaudītāju, kuru politika atsakās glabāt. Konts darbojas tā, kā projektēts, un projekts pieņem, ka tīkls ir klāt, kad Windows to jautā. Simptoma uztveršana kā kešatmiņas kļūdas ir ceļš, kā komandas pārbūvē profilu, kas nekad nav bijis bojāts.

Kāpēc tunelim jāpastāv pirms darbvirsmas

Ierīcei jāsasniedz domēna autentifikācija tajā brīdī, kad Windows to pieprasa, un tas ir pirms jebkuras lietotāja sesijas. VPN klients, kas startē tikai pēc darbvirsmas parādīšanās, atstāj jaunu pieteikšanos gaidām ceļu, kas nekad nepienāk. Atkarība pieder mašīnai, nevis lietotājam, kurš vēl nav pieteicies.

Izmantojiet atbalstītu pirmspieteikšanās risinājumu, kas saskaņots ar galapunktu un identitātes īpašniekiem. Always On VPN ierīces tunelis, kas autentificēts ar datora sertifikātu, ir piemērots, ja pārvaldītā ierīce atbilst šīs izvietošanas priekšnosacījumiem. Piegādātāja atbalstītā pieteikšanās ekrāna integrācija ir vēl viena iespēja. Parasts lietotāja profils ar automātisku palaidēju nav ne viens, ne otrs, lai cik līdzīgs tas izskatītos klienta saskarnē.

Šim ceļam vajadzīga nosaukumu izšķiršana domēnam, sasniedzams domēna kontrolieris un tie autentifikācijas protokoli, ko konts drīkst izmantot, un neviens indikators «savienots» to nenodrošina. Tā maršrutiem un filtriem jāpārvadā identitātes pakalpojumi un nekas cits, kas nav nepieciešams, jo šis prefiksu saraksts ir virsma, ko nozagts klēpjdators iegūst pirms kāds piesakās. Lietotāja tunelim pieņemtie sadalītā tuneļa lēmumi neattiecas uz ierīces tuneli, tāpēc izskatiet abus atsevišķi.

Sasniedzamība nav autentifikācijas saderība

Tunelis var nevainojami pārvadāt paketes, kamēr domēna autentifikācija neizdodas, jo mēģinātais mehānisms ir tāds, ko konts nevar izmantot. Domēnā, kas piemēro grupas ierobežojumus, NTLM dalībniekiem nav pieejams, un Kerberos nepieciešams AES saderīgs konts un konfigurācija. Pakešu ceļš nevar salabot ne vienu, ne otru. Tāpēc tīrs ping uz domēna kontrolieri nav pierādījums, ka pieteikšanās darbosies.

Var būt iesaistītas arī divas akreditācijas datu sistēmas. VPN var autentificēties pie identitātes nodrošinātāja, kamēr Windows atsevišķi nepieciešama domēna pieteikšanās, un pirmā pieņemšana neko nepasaka par otro. «VPN savienojās» un «lietotājs ir pieteicies» ir atsevišķi novērojumi, un viena salabošana nenozīmē otru.

Izlasiet autentifikācijas pierādījumus

Apkopojiet notikumus no klienta un no domēna kontroliera vienam un tam pašam mēģinājumam, ne tikai no vienas puses. Protected Users žurnāli atrodas zem Applications and Services Logs\Microsoft\Windows\Authentication, un administratoram var nākties ieslēgt žurnālu, pirms tas kaut ko ieraksta. Korelējiet laika zīmogus ar paša tuneļa savienojuma žurnālu, jo secības kļūda no abām pusēm izskatās kā akreditācijas datu kļūda.

Pirmā komanda zemāk uzskaita katru autentifikācijas žurnālu, ko ierīce atklāj, tāpēc jūs lasāt to, kas pastāv, nevis to, ko nosauca kāds emuāra ieraksts. Otrā nolasa jaunākos ierakstus, kad zināt nosaukumu. Meklējiet autentifikācijas pakotni, kontu un kļūmes nosacījumu, jo trūkstošs tīkla ceļš un noraidīts mehānisms atstāj atšķirīgus pierādījumus, un tikai viens no tiem ir VPN problēma. Ja tunelis pacēlās pēc mēģinājuma, secība bija nepareiza, lai ko šie ieraksti teiktu.

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

Pierādiet robežu no aukstās palaišanas

Veiciet testu no izrakstītā vai tikko palaistā stāvokļa ar ierobežotu kontu un turiet atvērtu apstiprinātu atkopšanas ceļu, pirms kaut ko maināt privileģētajiem lietotājiem. Tests jau darbojošā darbvirsmā nevingrina nevienu svarīgā koda ceļa daļu, un tas izskaidro lielāko daļu ziņojumu par labojumu, kas turējās līdz nākamajai pārstartēšanai. Pēc tam izpildiet četrus soļus šajā secībā.

1. Apstipriniet, ka ierīce var atrast domēna kontrolieri, pirms kāds piesakās, ar nltest /dsgetdc:corp.example.com.
2. Mēģiniet pieteikties domēnā un pēc tam pajautājiet, vai biļete vispār tika iegūta, ar klist.
3. Izlasiet autentifikācijas žurnālu, ko ierīce ieraksta, ar divām iepriekš minētajām komandām, un atzīmējiet pakotni un kļūmes nosacījumu.
4. Apstipriniet, ka apstiprinātie rezerves akreditācijas dati joprojām darbojas pieteikšanās ekrānā, jo tas ir vienīgais ceļš atpakaļ, ja robežas tests neizdodas.

Failu koplietojuma atvēršana ar nodotiem akreditācijas datiem arī neveido bezsaistes interaktīvu pieteikšanos, tāpēc tā neaizstāj nevienu iepriekš minēto soli. Ja organizācijai patiešām vajadzīga pieteikšanās bez savienojuma, atbilde ir apzināti izvēlēts saderīgs konta un galapunkta projekts. Konta izņemšana no grupas vai vienas neierobežotas avārijas pieteikšanās saglabāšana katrā klēpjdatorā ir identitātes politikas lēmums, ko VPN izmaiņas nevar pieņemt jūsu vietā.

Protected Users dokumentācija apraksta gan pārbaudītāja uzvedību, gan domēna ierobežojumus, no kuriem šis projekts ir atkarīgs. Izplānojiet atkopšanas procesu, pirms kāds dodas ceļojumā, jo aukstās palaišanas tests ir vienīgā vieta, kur tas tiek praktizēts.