Kial Protected Users-komputilo bezonas la VPN antaŭ saluto

Tekkomputilo, funkcianta konto kaj hotelreto kune kreas salutbuklon, kiun nenia ripetado rompas. La konto troviĝas en Protected Users, kio malhelpas al Windows konservi la kontrolilon, kiun ĝi bezonus por aŭtentigi la uzanton senrete. Ĉiu plano laŭ la formo «unu salutu, poste konektu la tunelon» havas la malan ordon, kaj la protekto faras ĝuste tion, kion ĝi promesas. La sekva teksto supozas tradician Active Directory-konton sur subtenata Windows-gastigo.

Kion la protekto efektive forigas

Windows kutime kaŝmemorigas kontrolilon, por ke domajna konto povu saluti dum domajna regilo neatingeblas. Protected Users blokas tion por la konto, kio forigas senretan domajnan saluton kiel eblecon anstataŭ igi ĝin nefidinda.

Tio ne estas la ordinara problemo de kaduka kaŝmemoro, kaj la ordinaraj rimedoj ne aplikiĝas. Ripeta enreta saluto, plia pasvorta ŝanĝo aŭ pli alta limo de kaŝmemoritaj salutoj ne restarigos la kapablon, ĉar neniu el tiuj agoj kreas la kontrolilon, kiun la politiko rifuzas konservi. La konto kondutas laŭ la dezajno, kaj la dezajno supozas, ke la reto ĉeestas kiam Windows demandas. Trakti la simptomon kiel kaŝmemoran misfunkcion estas la maniero, laŭ kiu teamoj rekonstruas profilon, kiu neniam estis difektita.

Kial la tunelo devas ekzisti antaŭ la labortablo

La aparato devas atingi domajnan aŭtentigon en la momento, kiam Windows tion postulas, kaj tio estas antaŭ ol ekzistas iu ajn uzanta seanco. VPN-kliento, kiu ekfunkcias nur post kiam la labortablo aperas, lasas freŝan saluton atendi vojon, kiu neniam alvenas. La dependeco apartenas al la maŝino, ne al uzanto, kiu ankoraŭ ne salutis.

Uzu subtenatan antaŭsalutan aranĝon interkonsentitan kun la posedantoj de finpunktoj kaj identeco. Always On VPN-aparata tunelo aŭtentigita per komputila atestilo taŭgas, kiam la administrata aparato plenumas la antaŭkondiĉojn de tiu deplojo. Subtenata salutekrana integriĝo de vendisto estas alia. Ordinara uzanta profilo kun aŭtomata ekigilo estas nek unu nek la alia, kiom ajn simila ĝi aspektas en la klienta fasado.

Tiu vojo bezonas nomrezolucion por la domajno, atingeblan domajnan regilon kaj la aŭtentigajn protokolojn, kiujn la konto rajtas uzi, kaj neniun el tiuj provizas indikilo «konektita». Ĝiaj itineroj kaj filtriloj portu la identecservojn kaj nenion alian nebezonatan, ĉar tiu prefiksa listo estas la surfaco, kiun ŝtelita tekkomputilo ricevas antaŭ ol iu salutas. Decidoj pri dividita tunelo faritaj por la uzanta tunelo ne transiĝas al la aparata tunelo, do revizu la du aparte.

Atingebleco ne estas aŭtentiga kongrueco

Tunelo povas perfekte transporti pakojn dum domajna aŭtentigo malsukcesas, ĉar la provata mekanismo estas unu, kiun la konto ne rajtas uzi. En domajno, kiu plenumas la limojn de la grupo, NTLM ne disponeblas al membroj kaj Kerberos bezonas AES-kongruan konton kaj agordon. Paka vojo povas ripari neniun el tiuj. Tial pura ping al domajna regilo ne estas pruvo, ke la saluto funkcios.

Povas ankaŭ esti du akreditaĵaj sistemoj en ludo. La VPN povas aŭtentigi ĉe identecprovizanto dum Windows aparte bezonas domajnan saluton, kaj akcepto fare de la unua diras nenion pri la dua. «La VPN konektiĝis» kaj «la uzanto salutis» estas apartaj observoj, kaj ripari unu ne implicas la alian.

Legu la aŭtentigajn pruvojn

Kolektu eventojn de la kliento kaj de domajna regilo por la sama provo, ne nur de unu flanko. La protokoloj de Protected Users troviĝas sub Applications and Services Logs\Microsoft\Windows\Authentication, kaj administranto eble devas ŝalti protokolon antaŭ ol ĝi registras ion. Koreligu la tempomarkojn kun la propra konekta protokolo de la tunelo, ĉar eraro pri ordo aspektas kiel akreditaĵa misfunkcio de ambaŭ flankoj.

La unua komando sube listigas ĉiun aŭtentigan protokolon, kiun la aparato elmetas, do vi legas tiun, kiu ekzistas, anstataŭ tiun, kiun nomis blogaĵo. La dua legas lastatempajn enskribojn post kiam vi scias la nomon. Serĉu la aŭtentigan pakaĵon, la konton kaj la malsukcesan kondiĉon, ĉar mankanta reta vojo kaj rifuzita mekanismo lasas malsamajn pruvojn kaj nur unu el ili estas VPN-problemo. Se la tunelo leviĝis post la provo, la ordo estis malĝusta, kion ajn tiuj enskriboj diras.

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

Pruvu la limon el malvarma starto

Rulu la teston el elsalutita aŭ ĵus startigita stato kun limigita konto, kaj tenu aprobitan rekuperan vojon malferma antaŭ ol ŝanĝi ion por privilegiitaj uzantoj. Testo sur jam kuranta labortablo ekzercas neniun parton de la grava koda vojo, kaj tio klarigas la plej multajn raportojn pri korekto, kiu teniĝis ĝis la sekva restarto. Poste trairu la kvar paŝojn laŭ ĉi tiu ordo.

1. Konfirmu, ke la aparato povas trovi domajnan regilon antaŭ ol iu salutas, per nltest /dsgetdc:corp.example.com.
2. Provu la domajnan saluton, poste demandu, ĉu bileto entute akiriĝis, per klist.
3. Legu la aŭtentigan protokolon, kiun la aparato registras, per la du komandoj supre, kaj notu la pakaĵon kaj la malsukcesan kondiĉon.
4. Konfirmu, ke la aprobita rezerva akreditaĵo ankoraŭ funkcias el la saluta ekrano, ĉar tio estas la sola vojo reen, se la lima testo malsukcesas.

Malfermi dosierkomunaĵon per donitaj akreditaĵoj ankaŭ ne kreas senretan interagan saluton, do ĝi ne anstataŭas iun ajn paŝon supre. Se la organizo vere bezonas senkonektan saluton, la respondo estas kongrua konto- kaj finpunkta dezajno elektita konscie. Forigi la konton el la grupo, aŭ teni unu senliman krizan saluton sur ĉiu tekkomputilo, estas decido pri identeca politiko, kiun VPN-ŝanĝo ne povas fari por vi.

La dokumentaro pri Protected Users priskribas kaj la konduton de la kontrolilo kaj la domajnajn limojn, de kiuj ĉi tiu dezajno dependas. Planu la rekuperan procezon antaŭ ol iu vojaĝas, ĉar la malvarma starta testo estas la sola loko, kie ĝi ekzerciĝas.