Uwierzytelnianie LDAP w OpenVPN działa, ale sprawdzenie grupy zawodzi: gdzie szukać

Uwierzytelnianie może przejść, a sprawdzenie grupy odrzuca wszystkich. Przejrzyj po kolei blok Authorization, atrybut członkostwa i punkt końcowy katalogu.

Poświadczenia przechodzą, tunel zaczyna się podnosić, a potem sesja zawodzi z komunikatem o grupie, a nie o haśle. Ta kombinacja umieszcza błąd w drugiej połowie pracy wtyczki LDAP: powiązanie i sprawdzenie hasła powiodły się, a następująca decyzja o członkostwie nie. Obie połowy czytają z tego samego bloku konfiguracji, dlatego poprawka w jednym miejscu może pozostawić drugą nietkniętą. Zacznij od linii dziennika, która nazywa krok, a nie od konta, którym przypadkiem testujesz.

Traktuj odrzucenie jako odpowiedź autoryzacji

Wtyczka wykonuje powiązanie usługi, szuka konta, weryfikuje podane hasło, a następnie pyta, czy to konto należy do dozwolonej grupy. To cztery odrębne operacje, i tylko ostatnia dotyczy grup. Odrzucenie, które przychodzi po udanym powiązaniu, nic więc nie mówi o haśle, nawet gdy klient pokazuje ogólny błąd uwierzytelniania. Podniesienie poziomu dziennika wtyczki przed zmianą konfiguracji jest tym, co rozdziela te cztery w danych wyjściowych.

Szukaj samej oceny grupy. Gdy nie pojawia się żadne zapytanie o grupę, blok autoryzacji nie jest osiągany, co zwykle oznacza, że dyrektywa stoi poza blokiem, który nią zarządza, albo brakuje wymaganej opcji. Gdy zapytanie się pojawia i nic nie zwraca, punkt końcowy lub filtr odpowiada na inne pytanie niż to, które miałeś na myśli.

Zdecyduj, czy członkostwo mieszka w filtrze, czy w bloku grupy

Są dwa obsługiwane kształty, a ich mieszanie to sposób, w jaki działająca konfiguracja przestaje działać. Pierwszy wpycha członkostwo do wyszukiwania użytkowników, prosząc o atrybut na obiekcie użytkownika; drugi zostawia wyszukiwanie użytkowników w spokoju i pozwala wtyczce później odszukać obiekt grupy. Wybierz jeden na wdrożenie i zapisz, który wybrałeś.

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(&(sAMAccountName=%u)(memberOf=CN=VPN Access,OU=Groups,DC=example,DC=org))"
    RequireGroup false
</Authorization>

W tym kształcie filtr decyduje o wszystkim, więc RequireGroup musi mieć wartość false, inaczej wtyczka pójdzie szukać obiektu grupy, którego filtr nigdy nie wspomniał. Atrybut w filtrze musi istnieć na obiekcie użytkownika i być wypełniony, co nie jest gwarantowane, gdy grupy są zagnieżdżone.

Drugi kształt utrzymuje wyszukiwanie w prostocie i dodaje po nim wyszukiwanie grupy. Obiekt grupy jest nazwany wprost, a wtyczka porównuje użytkownika z członkami, których katalog dla niego zwraca. Nic w filtrze użytkownika się nie zmienia, co czyni ten kształt łatwiejszym do audytu, gdy grupą zarządza inny zespół.

<Authorization>
    BaseDN       "OU=People,DC=example,DC=org"
    SearchFilter "(sAMAccountName=%u)"
    RequireGroup true
    Group        "CN=VPN Access,OU=Groups,DC=example,DC=org"
</Authorization>

Martwy punkt jest wspólny: proste porównanie członkostwa nie rozwija zagnieżdżonych grup, więc konto, którego dostęp przychodzi przez grupę nadrzędną, zawodzi, podczas gdy konsola nadal pokazuje członkostwo. Active Directory udostępnia member na grupie, inne schematy używają uniqueMember, a wskazanie złego atrybutu zwraca pusty wynik zamiast błędu.

Wybierz punkt końcowy, który zawiera obiekt grupy

URL decyduje, który katalog wtyczka pyta, a kontroler domeny na porcie 389 odpowiada tylko za własny kontekst nazw. Katalog globalny na porcie 3268 odpowiada za cały las, tylko do odczytu i z częściowym zestawem atrybutów. Gdy konta są w jednej domenie, a grupa VPN w innej, zapytanie do jednej domeny może znaleźć użytkownika i wciąż pominąć członkostwo. To jest przypadek, w którym przeniesienie URL na port katalogu rozwiązuje odrzucenie, i to jest też przypadek, w którym ludzie uogólniają zbyt daleko.

Częściowy zestaw atrybutów jest granicą: atrybutu, którego katalog nie zawiera, nie można filtrować, więc ta sama zmiana może sprawić, że jedno wdrożenie zadziała, a inne zwróci nic. Zanim przepiszesz blok, potwierdź, co punkt końcowy naprawdę zwraca dla rzeczywistego użytkownika i grupy. Odsyłacze i TLS to znów osobne sprawy, bo odsyłacz trzeba śledzić, a punkt końcowy wymagający TLS potrzebuje pasujących plików zaufania.

Trzymaj stan konta i zakres wyszukiwania w ich własnych polach

Flaga wyłączenia należy do filtra, a nie do sprawdzenia grupy. W Active Directory to drugi bit userAccountControl, a bez tego warunku wyłączone konto z ważnym hasłem uwierzytelnia się, a potem zawodzi na kroku grupy, co wygląda jak błąd autoryzacji. Zakres wyszukiwania należy do bazowego DN, ponieważ start od katalogu głównego domeny jest wolniejszy i może trafić obiekty spoza jednostki organizacyjnej, którą chciałeś objąć.

Trzymaj też uprawnienia konta powiązania wąskie. Szerokie uprawnienia katalogu zamieniają źle skonfigurowany filtr w udane zapytanie i ukrywają błąd, dopóki ktoś nie zaudytuje konta. Zmieniaj członkostwo w samym katalogu, nigdy w lokalnej liście wyjątków, aby wyłączenie konta wystarczyło do odebrania dostępu. Jeśli grupą zarządza inny zespół, uzgodnij atrybut, który oni wypełniają, zanim napiszesz na nim filtr.

Udowodnij wynik trzema kontami

Uruchom konfigurację wobec trzech tożsamości: dozwolonego członka, ważnego konta spoza grupy i konta, które zostało wyłączone. Jeśli wszystkie trzy są odrzucane, powiązanie lub zapytanie o grupę jest zepsute; jeśli wszystkie trzy są akceptowane, żaden warunek grupy nie jest stosowany. Wynik mieszany jest jedynym, który dowodzi, że konfiguracja rozróżnia przypadki, na których ci zależy.

Przeczytaj te same trzy odpowiedzi bezpośrednio z katalogu, zanim obwinisz wtyczkę. Pierwsze zapytanie pokazuje atrybut grupy, od którego zależy filtr, a drugie pokazuje wartość kontroli konta. Podstaw własny bazowy DN, konto i punkt końcowy:

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)" userAccountControl

Użytkownik, którego memberOf wraca pusty, jest faktem katalogu, a nie błędem wtyczki, a konto, które po wyłączeniu nadal się uwierzytelnia, oznacza, że filtrowi brakuje warunku kontroli konta. Najpierw popraw ten dowód, a potem uruchom ponownie test z trzema kontami. Trzymaj linię dziennika, która nazwała nieudany krok, obok zmiany konfiguracji, aby następna osoba mogła oddzielić autoryzację od uwierzytelniania bez powtarzania wyszukiwania.

Powiązane artykuły