OpenVPN LDAP autentifikasiyası işləyir, amma qrup yoxlaması uğursuz olur: hara baxmalı
Autentifikasiya keçə bilər, halbuki qrup yoxlaması hamını rədd edir. Authorization blokunu, üzvlük atributunu və kataloq son nöqtəsini növbə ilə nəzərdən keçirin.
Kredensiallar keçir, tunel qalxmağa başlayır, sonra sessiya parol haqqında deyil, qrup haqqında mesajla uğursuz olur. Bu birləşmə nasazlığı LDAP plagini işinin ikinci yarısına yerləşdirir: bind və parol yoxlaması uğurlu olub, ardınca gələn üzvlük qərarı isə olmayıb. Hər iki yarı eyni konfiqurasiya bölməsindən oxuyur, buna görə bir yerdəki düzəliş digərini toxunulmamış qoya bilər. Addımı adlandıran log sətrindən başlayın, təsadüfən test etdiyiniz hesabdan deyil.
Rəddi avtorizasiya cavabı kimi qəbul edin
Plagin xidmət bind-i yerinə yetirir, hesabı axtarır, verilmiş parolu yoxlayır və sonra o hesabın icazəli qrupa aid olub-olmadığını soruşur. Bunlar dörd ayrı əməliyyatdır və yalnız sonuncusu qruplarla bağlıdır. Buna görə uğurlu bind-dən sonra gələn rədd parol haqqında heç nə demir, hətta müştəri ümumi autentifikasiya xətası göstərsə də. Konfiqurasiyanı dəyişməzdən əvvəl plaginin log səviyyəsini qaldırmaq dördünü çıxışda ayıran şeydir.
Qrup qiymətləndirməsinin özünə baxın. Ümumiyyətlə heç bir qrup sorğusu görünmürsə, avtorizasiya blokuna çatılmır, bu da adətən direktivin onu saxlayan bölmədən kənarda durması və ya tələb olunan seçimin çatışmaması deməkdir. Sorğu görünüb heç nə qaytarmırsa, son nöqtə və ya filtr sizin nəzərdə tutduğunuzdan başqa suala cavab verir.
Üzvlüyün filtrdə, yoxsa qrup blokunda yaşadığına qərar verin
Dəstəklənən iki forma var və onları qarışdırmaq işlək konfiqurasiyanın işləməsini dayandırmasının yoludur. Birincisi üzvlüyü istifadəçi obyektindəki atributu soruşaraq istifadəçi axtarışına itələyir; ikincisi istifadəçi axtarışını olduğu kimi saxlayır və plagin sonradan qrup obyektini axtarır. Hər yerləşdirmə üçün birini seçin və hansını seçdiyinizi yazın.
<Authorization>
BaseDN "OU=People,DC=example,DC=org"
SearchFilter "(&(sAMAccountName=%u)(memberOf=CN=VPN Access,OU=Groups,DC=example,DC=org))"
RequireGroup false
</Authorization>Bu formada hər şeyi filtr həll edir, ona görə RequireGroup false olmalıdır, əks halda plagin filtrin heç vaxt qeyd etmədiyi qrup obyektini axtarmağa gedir. Filtrdəki atribut istifadəçi obyektində mövcud və dolu olmalıdır ki, bu da qruplar iç-içə olduqdan sonra təmin edilmir.
Digər forma axtarışı sadə saxlayır və ondan sonra qrup axtarışı əlavə edir. Qrup obyekti açıq şəkildə adlandırılır və plagin istifadəçini kataloqun onun üçün qaytardığı üzvlərlə müqayisə edir. İstifadəçi filtrində heç nə dəyişmir, bu da qrupu başqa komanda idarə etdikdə bu formanı audit etməyi asanlaşdırır.
<Authorization>
BaseDN "OU=People,DC=example,DC=org"
SearchFilter "(sAMAccountName=%u)"
RequireGroup true
Group "CN=VPN Access,OU=Groups,DC=example,DC=org"
</Authorization>Kor nöqtə ortaqdır: sadə üzvlük müqayisəsi iç-içə qrupları genişləndirmir, buna görə girişi valideyn qrupu vasitəsilə gələn hesab uğursuz olur, konsol isə hələ də üzvlüyü göstərir. Active Directory qrupda member atributunu açır, başqa sxemlər uniqueMember istifadə edir və yanlış atributa işarə etmək xəta əvəzinə boş nəticə qaytarır.
Qrup obyektini saxlayan son nöqtə seçin
URL plaginin hansı kataloqdan soruşacağını müəyyən edir və 389 portundakı domen nəzarətçisi yalnız öz adlandırma konteksti üçün cavab verir. 3268 portundakı qlobal kataloq bütün meşə üçün cavab verir, yalnız oxuma rejimində və qismən atribut dəsti ilə. Hesablar bir domendə, VPN qrupu isə digərində olduqda, tək domenli sorğu istifadəçini tapa və yenə də üzvlüyü buraxmaya bilər. URL-i kataloq portuna köçürmənin rəddi həll etdiyi hal budur və insanların həddindən artıq ümumiləşdirdiyi hal da budur.
Qismən atribut dəsti həddir: kataloqun saxlamadığı atribut üzrə filtr qurmaq olmaz, buna görə eyni dəyişiklik bir yerləşdirməni işlədə, digərini boş nəticəyə çevirə bilər. Bölməni yenidən yazmazdan əvvəl son nöqtənin real istifadəçi və qrup üçün həqiqətən nə qaytardığını təsdiqləyin. Yönləndirmələr və TLS yenə ayrı məsələlərdir, çünki yönləndirmə izlənməlidir və TLS tələb edən son nöqtə uyğun etimad fayllarını tələb edir.
Hesab vəziyyətini və axtarış əhatəsini öz sahələrində saxlayın
Deaktivasiya bayrağı filtrdə olmalıdır, qrup yoxlamasında deyil. Active Directory-də bu userAccountControl ikinci bitidir və bu şərt olmadan etibarlı parolu olan deaktiv hesab autentifikasiyadan keçir, sonra qrup addımında uğursuz olur ki, bu da avtorizasiya xətası kimi oxunur. Axtarış əhatəsi baza DN-də olmalıdır, çünki domen kökündən başlamaq daha yavaşdır və nəzərdə tutduğunuz təşkilati vahiddən kənar obyektlərə uyğun gələ bilər.
Bind hesabının hüquqlarını da dar saxlayın. Geniş kataloq hüquqları səhv konfiqurasiya olunmuş filtri uğurlu sorğuya çevirir və kimsə hesabı audit edənə qədər nasazlığı gizlədir. Üzvlüyü kataloqun özündə dəyişin, heç vaxt yerli istisna siyahısında deyil, belə ki girişi götürmək üçün hesabın deaktiv edilməsi kifayət etsin. Qrupu başqa komanda idarə edirsə, ona filtr yazmazdan əvvəl doldurduqları atribut barədə razılaşın.
Nəticəni üç hesabla sübut edin
Konfiqurasiyanı üç kimlik üzərində işlədin: icazəli üzv, qrupdan kənar etibarlı hesab və deaktiv edilmiş hesab. Əgər hər üçü rədd olunursa, bind və ya qrup sorğusu sınıqdır; əgər hər üçü qəbul olunursa, heç bir qrup şərti tətbiq edilmir. Qarışıq nəticə konfiqurasiyanın sizin üçün vacib olan halları ayırdığını sübut edən yeganə nəticədir.
Plagini günahlandırmazdan əvvəl eyni üç cavabı birbaşa kataloqdan oxuyun. Birinci sorğu filtrin asılı olduğu qrup atributunu, ikincisi isə hesab nəzarəti dəyərini göstərir. Öz baza DN-inizi, hesabınızı və son nöqtənizi qoyun:
ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=alice)" memberOf
ldapsearch -H ldap://dc01.example.org:3268 -x -D "[email protected]" -W -b "DC=example,DC=org" "(sAMAccountName=bob)" userAccountControlmemberOf boş qayıdan istifadəçi plagin xətası deyil, kataloq faktıdır və deaktiv edildikdən sonra hələ də autentifikasiyadan keçən hesab filtrin hesab nəzarəti şərtini buraxdığını bildirir. Əvvəlcə həmin sübutu düzəldin, sonra üç hesablı testi yenidən işlədin. Uğursuz addımı adlandıran log sətrini konfiqurasiya dəyişikliyinin yanında saxlayın ki, növbəti şəxs axtarışı təkrarlamadan avtorizasiyanı autentifikasiyadan ayıra bilsin.