Niyə Protected Users noutbuku girişdən əvvəl VPN-ə ehtiyac duyur

Noutbuk, işlək hesab və otel şəbəkəsi birlikdə elə bir giriş dövrəsi yaradır ki, onu heç bir təkrar cəhd poza bilmir. Hesab Protected Users qrupundadır və bu, Windows-un istifadəçini oflayn autentifikasiya etmək üçün lazım olan təsdiqləyicini saxlamağına mane olur. «Əvvəl daxil ol, sonra tuneli qoş» şəklində olan hər hansı plan sıranı tərsinə çevirir və müdafiə vəd etdiyini tam yerinə yetirir. Aşağıdakılar dəstəklənən Windows hostunda ənənəvi Active Directory hesabını nəzərdə tutur.

Müdafiə əslində nəyi aradan qaldırır

Windows adətən təsdiqləyicini keşləyir ki, domen hesabı domen kontrolleri əlçatmaz olduqda daxil ola bilsin. Protected Users bunu hesab üçün bloklayır və bununla oflayn domen girişini etibarsız etmək əvəzinə mümkünsüzlük kimi aradan qaldırır.

Bu adi köhnəlmiş keş problemi deyil və adi çarələr burada işləmir. Dəfələrlə onlayn daxil olmaq, parolu yenidən dəyişmək və ya keşlənmiş giriş sayını artırmaq qabiliyyəti bərpa etməyəcək, çünki bu əməliyyatların heç biri siyasətin saxlamaqdan imtina etdiyi təsdiqləyicini yaratmır. Hesab dizayn edildiyi kimi davranır və dizayn Windows soruşduqda şəbəkənin mövcud olduğunu fərz edir. Simptomu keş nasazlığı kimi qəbul etmək komandaların heç vaxt xarab olmamış profili yenidən qurması ilə nəticələnir.

Niyə tunel masaüstündən əvvəl mövcud olmalıdır

Cihaz domen autentifikasiyasına Windows onu tələb etdiyi anda çatmalıdır və bu, hər hansı istifadəçi sessiyası yaranmadan öncədir. Yalnız masaüstü göründükdən sonra başlayan VPN klienti yeni girişi heç vaxt gəlməyən yol gözləyən vəziyyətdə qoyur. Asılılıq maşına aiddir, hələ daxil olmamış istifadəçiyə deyil.

Endpoint və kimlik sahibləri ilə razılaşdırılmış dəstəklənən girişdən-əvvəl quruluşundan istifadə edin. Kompüter sertifikatı ilə autentifikasiya olunan Always On VPN cihaz tuneli, idarə olunan cihaz həmin yerləşdirmənin ilkin şərtlərini ödədikdə uyğundur. İstehsalçının dəstəklənən giriş ekranı inteqrasiyası başqa bir variantdır. Avtomatik tetikleyicisi olan adi istifadəçi profili heç biri deyil, müştəri interfeysində nə qədər oxşar görünsə də.

Bu yolun ehtiyacı domen üçün ad həlledilməsi, əlçatan domen kontrolleri və hesabın istifadə edə biləcəyi autentifikasiya protokollarıdır və bunların heç birini «qoşulub» göstəricisi təmin etmir. Onun marşrutları və filtrləri kimlik xidmətlərini daşımalı, lazım olmayan başqa heç nə daşımamalıdır, çünki o prefiks siyahısı oğurlanmış noutbukun hər kəs daxil olmadan əldə etdiyi səthdir. İstifadəçi tuneli üçün verilən split-tunnel qərarları cihaz tunelinə keçmir, ona görə ikisini ayrı-ayrılıqda nəzərdən keçirin.

Əlçatanlıq autentifikasiya uyğunluğu deyil

Tunel paketləri mükəmməl daşıya bilər, halbuki domen autentifikasiyası uğursuz olur, çünki cəhd edilən mexanizm hesabın istifadə edə bilmədiyi mexanizmdir. Qrupun məhdudiyyətlərini tətbiq edən domendə NTLM üzvlər üçün mövcud deyil və Kerberos AES-uyğun hesab və konfiqurasiya tələb edir. Paket yolu bunların heç birini düzəldə bilməz. Buna görə domen kontrollerinə təmiz ping girişin işləyəcəyinə sübut deyil.

İki etimad sistemi də işdə ola bilər. VPN kimlik provayderinə qarşı autentifikasiya edə bilər, halbuki Windows ayrıca domen girişinə ehtiyac duyur və birincinin qəbulu ikinci barədə heç nə demir. «VPN qoşuldu» və «istifadəçi daxil oldu» ayrı müşahidələrdir və birinin düzəldilməsi digərini nəzərdə tutmur.

Autentifikasiya sübutlarını oxuyun

Eyni cəhd üçün hadisələri həm klientdən, həm də domen kontrollerindən toplayın, yalnız bir tərəfdən deyil. Protected Users qeydləri Applications and Services Logs\Microsoft\Windows\Authentication altındadır və administratorun qeyd heç nə yazmazdan əvvəl onu işə salması lazım ola bilər. Vaxt damğalarını tunelin öz bağlantı qeydi ilə əlaqələndirin, çünki sıra səhvi hər iki tərəfdən etimad nasazlığı kimi görünür.

Aşağıdakı birinci əmr cihazın təqdim etdiyi hər autentifikasiya qeydini sadalayır, beləliklə bloq yazısının adlandırdığını deyil, mövcud olanı oxuyursunuz. İkincisi adı bildikdən sonra son girişləri oxuyur. Autentifikasiya paketini, hesabı və uğursuzluq şərtini axtarın, çünki itkin şəbəkə yolu və rədd edilmiş mexanizm fərqli sübutlar qoyur və yalnız biri VPN problemidir. Əgər tunel cəhddən sonra qalxıbsa, o girişlər nə deyirsə desin, sıra səhv idi.

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

Sərhədi soyuq yükləmədən sübut edin

Testi çıxış edilmiş və ya yeni yüklənmiş vəziyyətdən məhdud hesabla aparın və imtiyazlı istifadəçilər üçün hər hansı dəyişiklik etməzdən əvvəl təsdiqlənmiş bərpa yolunu açıq saxlayın. Artıq işləyən masaüstündə test vacib kod yolunun heç bir hissəsini işə salmır və bu, növbəti yenidən başlatmaya qədər davam edən düzəliş hesabatlarının çoxunu izah edir. Sonra dörd addımı bu sıra ilə keçin.

1. Heç kim daxil olmadan cihazın domen kontrollerini tapa bildiyini nltest /dsgetdc:corp.example.com ilə təsdiqləyin.
2. Domen girişini cəhd edin, sonra klist ilə ümumiyyətlə bilet alınıb-alınmadığını soruşun.
3. Cihazın qeyd etdiyi autentifikasiya qeydini yuxarıdakı iki əmrlə oxuyun və paketi və uğursuzluq şərtini qeyd edin.
4. Təsdiqlənmiş bərpa etimadının hələ də giriş ekranından işlədiyini təsdiqləyin, çünki sərhəd testi uğursuz olarsa geri qayıtmağın yeganə yolu budur.

Fayl paylaşımını verilmiş etimadlarla açmaq da oflayn interaktiv giriş yaratmır, ona görə yuxarıdakı heç bir addımın əvəzi deyil. Əgər təşkilat həqiqətən əlaqəsiz girişə ehtiyac duyursa, cavab qəsdən seçilmiş uyğun hesab və endpoint dizaynıdır. Hesabı qrupdan çıxarmaq və ya hər noutbukda bir məhdudiyyətsiz təcili giriş saxlamaq, VPN dəyişikliyinin sizin üçün verə bilməyəcəyi kimlik siyasəti qərarıdır.

Protected Users sənədləşməsi həm təsdiqləyicinin davranışını, həm də bu dizaynın asılı olduğu domen məhdudiyyətlərini təsvir edir. Bərpa prosesini hər kəs səfərə çıxmadan əvvəl planlaşdırın, çünki soyuq yükləmə testi onun yoxlanıldığı yeganə yerdir.