Ověřování OpenVPN přes LDAP funguje, ale kontrola skupiny selhává: kam se dívat

Přihlašovací údaje projdou, tunel se začne zvedat a relace pak selže se zprávou o skupině, nikoli o heslu. Tato kombinace umisťuje závadu do druhé poloviny práce zásuvného modulu LDAP: připojení i kontrola hesla uspěly, ale rozhodnutí o členství, které následuje, ne. Obě poloviny čtou ze stejného konfiguračního bloku, a proto může oprava na jednom místě nechat druhou nedotčenou. Začněte u řádku v logu, který pojmenovává krok, ne u účtu, se kterým zrovna testujete.

Berte odmítnutí jako odpověď o autorizaci

Zásuvný modul provede servisní připojení, vyhledá účet, ověří zadané heslo a potom se zeptá, zda tento účet patří do povolené skupiny. To jsou čtyři odlišné operace a jen poslední se týká skupin. Odmítnutí, které přijde po úspěšném připojení, tedy o heslu nic neříká, i když klient zobrazí obecnou chybu ověřování. Zvýšení úrovně logu modulu před změnou konfigurace je to, co ty čtyři ve výstupu oddělí.

Hledejte samotné vyhodnocení skupiny. Když se neobjeví vůbec žádný dotaz na skupinu, blok autorizace se neprovádí, což obvykle znamená, že direktiva stojí mimo blok, který ji vlastní, nebo chybí povinná volba. Když se dotaz objeví a nic nevrátí, koncový bod nebo filtr odpovídá na jinou otázku, než jste mysleli.

Rozhodněte, zda členství žije ve filtru, nebo v bloku skupiny

Existují dvě podporované podoby a jejich míchání je způsob, jakým funkční konfigurace přestane fungovat. První tlačí členství do hledání uživatelů tím, že žádá atribut na objektu uživatele; druhá nechá hledání uživatelů být a nechá modul potom vyhledat objekt skupiny. Vyberte jednu pro každé nasazení a zapište, kterou jste vybrali.

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

V této podobě rozhoduje filtr o všem, takže RequireGroup musí být false, jinak modul půjde hledat objekt skupiny, který filtr nikdy nezmínil. Atribut ve filtru musí existovat na objektu uživatele a být naplněný, což není zaručeno, jakmile jsou skupiny vnořené.

Druhá podoba udržuje hledání jednoduché a přidává po něm vyhledání skupiny. Objekt skupiny je pojmenován výslovně a modul porovná uživatele s členy, které pro něj adresář vrací. Na filtru uživatele se nic nemění, což tuto podobu činí snáze auditovatelnou, když skupinu spravuje jiný tým.

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

Slepé místo je společné: prosté porovnání členství nerozvíjí vnořené skupiny, takže účet, jehož přístup přichází přes nadřazenou skupinu, selže, zatímco konzole stále zobrazuje členství. Active Directory vystavuje member na skupině, jiná schémata používají uniqueMember a ukázání na špatný atribut vrací prázdný výsledek místo chyby.

Vyberte koncový bod, který obsahuje objekt skupiny

URL rozhoduje, který adresář modul osloví, a řadič domény na portu 389 odpovídá jen za svůj vlastní kontext názvů. Globální katalog na portu 3268 odpovídá za celý les, jen pro čtení a s částečnou sadou atributů. Když účty jsou v jedné domény a skupina VPN v jiné, dotaz na jednu doménu může uživatele najít a přesto členství minout. To je případ, kdy přesunutí URL na port katalogu odmítnutí vyřeší, a také případ, kdy lidé zobecňují příliš daleko.

Částečná sada atributů je limit: atribut, který katalog neobsahuje, nelze filtrovat, takže stejná změna může jedno nasazení rozchodit a jiné vrátit prázdno. Než blok přepíšete, ověřte, co koncový bod skutečně vrací pro skutečného uživatele a skupinu. Odkazy a TLS jsou zase samostatné otázky, protože odkaz je třeba následovat a koncový bod vyžadující TLS potřebuje odpovídající soubory důvěry.

Držte stav účtu a rozsah hledání ve vlastních polích

Příznak deaktivace patří do filtru, ne do kontroly skupiny. V Active Directory je to druhý bit userAccountControl a bez této podmínky se deaktivovaný účet s platným heslem ověří a pak selže u kroku skupiny, což vypadá jako chyba autorizace. Rozsah hledání patří do základního DN, protože začátek v kořeni domény je pomalejší a může zasáhnout objekty mimo organizační jednotku, kterou jste chtěli pokrýt.

Držte také práva účtu pro připojení úzká. Široká práva v adresáři promění špatně nastavený filtr v úspěšný dotaz a skryjí chybu, dokud někdo účet neaudituje. Měňte členství v adresáři samotném, nikdy v místním seznamu výjimek, aby deaktivace účtu stačila k odebrání přístupu. Pokud skupinu spravuje jiný tým, domluvte se na atributu, který plní, než proti němu napíšete filtr.

Dokažte výsledek třemi účty

Spusťte konfiguraci proti třem identitám: povolený člen, platný účet mimo skupinu a účet, který byl deaktivován. Pokud jsou všechny tři odmítnuty, připojení nebo dotaz na skupinu je rozbité; pokud jsou všechny tři přijaty, neaplikuje se vůbec žádná podmínka skupiny. Smíšený výsledek je jediný, který dokazuje, že konfigurace rozlišuje případy, na kterých vám záleží.

Přečtěte si stejné tři odpovědi přímo z adresáře, než obviníte modul. První dotaz ukazuje atribut skupiny, na kterém filtr závisí, a druhý ukazuje hodnotu řízení účtu. Nahraďte svým základním DN, účtem a koncovým bodem:

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živatel, jehož memberOf se vrací prázdný, je fakt adresáře, ne chyba modulu, a účet, který se po deaktivaci stále ověřuje, znamená, že filtru chybí podmínka řízení účtu. Opravte nejprve tento důkaz a potom znovu spusťte test se třemi účty. Nechte řádek logu, který pojmenoval selhaný krok, vedle změny konfigurace, aby další člověk mohl oddělit autorizaci od ověřování, aniž by hledání opakoval.