Overovanie LDAP v OpenVPN funguje, ale kontrola skupiny zlyháva: kam sa pozerať
Overenie môže prejsť, kým kontrola skupiny odmietne všetkých. Prejdite postupne blok Authorization, atribút členstva a koncový bod adresára.
Prihlasovacie údaje prejdú, tunel sa začína dvíhať a relácia potom zlyhá so správou o skupine, nie o hesle. Táto kombinácia umiestňuje poruchu do druhej polovice práce doplnku LDAP: pripojenie aj kontrola hesla uspeli, ale rozhodnutie o členstve, ktoré nasleduje, nie. Obe polovice čítajú z rovnakého konfiguračného bloku, a preto môže oprava na jednom mieste nechať druhú nedotknutú. Začnite pri riadku v logu, ktorý pomenúva krok, nie pri účte, s ktorým práve testujete.
Berte odmietnutie ako odpoveď o autorizácii
Doplnok vykoná servisné pripojenie, vyhľadá účet, overí zadané heslo a potom sa spýta, či ten účet patrí do povolenej skupiny. To sú štyri odlišné operácie a iba posledná sa týka skupín. Odmietnutie, ktoré príde po úspešnom pripojení, teda o hesle nič nehovorí, aj keď klient zobrazí všeobecnú chybu overenia. Zvýšenie úrovne logu doplnku pred zmenou konfigurácie je to, čo tie štyri vo výstupe oddelí.
Hľadajte samotné vyhodnotenie skupiny. Keď sa neobjaví vôbec žiadna požiadavka na skupinu, blok autorizácie sa nevykoná, čo zvyčajne znamená, že direktíva stojí mimo bloku, ktorý ju vlastní, alebo chýba povinná voľba. Keď sa požiadavka objaví a nič nevráti, koncový bod alebo filter odpovedá na inú otázku, než ste mali na mysli.
Rozhodnite, či členstvo žije vo filtri alebo v bloku skupiny
Existujú dve podporované podoby a ich miešanie je spôsob, akým funkčná konfigurácia prestane fungovať. Prvá tlačí členstvo do vyhľadávania používateľov tým, že žiada atribút na objekte používateľa; druhá nechá vyhľadávanie používateľov na pokoji a nechá doplnok potom vyhľadať objekt skupiny. Vyberte jednu pre každé nasadenie a zapíšte, ktorú ste 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 tejto podobe rozhoduje filter o všetkom, takže RequireGroup musí byť false, inak doplnok pôjde hľadať objekt skupiny, ktorý filter nikdy nespomenul. Atribút vo filtri musí existovať na objekte používateľa a byť naplnený, čo nie je zaručené, keď sú skupiny vnorené.
Druhá podoba udržiava vyhľadávanie jednoduché a pridáva po ňom vyhľadanie skupiny. Objekt skupiny je pomenovaný výslovne a doplnok porovnáva používateľa s členmi, ktorých preň adresár vracia. Na filtri používateľa sa nič nemení, čo robí túto podobu ľahšie auditovateľnou, keď skupinu spravuje iný 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é miesto je spoločné: prosté porovnanie členstva nerozbaľuje vnorené skupiny, takže účet, ktorého prístup prichádza cez nadradenú skupinu, zlyhá, kým konzola stále zobrazuje členstvo. Active Directory vystavuje member na skupine, iné schémy používajú uniqueMember a ukázanie na nesprávny atribút vráti prázdny výsledok namiesto chyby.
Vyberte koncový bod, ktorý obsahuje objekt skupiny
URL rozhoduje, ktorý adresár doplnok osloví, a radič domény na porte 389 odpovedá len za svoj vlastný kontext názvov. Globálny katalóg na porte 3268 odpovedá za celý les, iba na čítanie a s čiastočnou sadou atribútov. Keď sú účty v jednej doméne a skupina VPN v inej, požiadavka na jednu doménu môže nájsť používateľa a napriek tomu minúť členstvo. To je prípad, keď presun URL na port katalógu vyrieši odmietnutie, a je to aj prípad, keď ľudia zovšeobecňujú príliš ďaleko.
Čiastočná sada atribútov je hranica: atribút, ktorý katalóg neobsahuje, nemožno filtrovať, takže tá istá zmena môže jedno nasadenie rozbehnúť a iné vrátiť prázdno. Pred prepísaním bloku potvrďte, čo koncový bod skutočne vracia pre skutočného používateľa a skupinu. Odkazy a TLS sú zasa samostatné otázky, keďže odkaz treba nasledovať a koncový bod vyžadujúci TLS potrebuje zodpovedajúce súbory dôvery.
Držte stav účtu a rozsah vyhľadávania vo vlastných poliach
Príznak deaktivácie patrí do filtra, nie do kontroly skupiny. V Active Directory je to druhý bit userAccountControl a bez tejto podmienky sa deaktivovaný účet s platným heslom overí a potom zlyhá pri kroku skupiny, čo vyzerá ako chyba autorizácie. Rozsah vyhľadávania patrí do základného DN, pretože začiatok v koreni domény je pomalší a môže zasiahnuť objekty mimo organizačnej jednotky, ktorú ste chceli pokryť.
Držte tiež práva účtu pripojenia úzke. Široké práva v adresári premenia nesprávne nastavený filter na úspešnú požiadavku a skryjú chybu, kým niekto účet neaudituje. Meňte členstvo v samotnom adresári, nikdy v miestnom zozname výnimiek, aby deaktivácia účtu stačila na odobratie prístupu. Ak skupinu spravuje iný tím, dohodnite sa na atribute, ktorý vypĺňajú, skôr než naň napíšete filter.
Dokážte výsledok tromi účtami
Spustite konfiguráciu proti trom identitám: povolený člen, platný účet mimo skupiny a účet, ktorý bol deaktivovaný. Ak sú všetky tri odmietnuté, pripojenie alebo požiadavka na skupinu sú pokazené; ak sú všetky tri prijaté, neaplikuje sa vôbec žiadna podmienka skupiny. Zmiešaný výsledok je jediný, ktorý dokazuje, že konfigurácia rozlišuje prípady, na ktorých vám záleží.
Prečítajte si tie isté tri odpovede priamo z adresára, skôr než obviníte doplnok. Prvá požiadavka ukazuje atribút skupiny, od ktorého závisí filter, a druhá ukazuje hodnotu riadenia účtu. Nahraďte vlastným základným DN, účtom a koncovým bodom:
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)" userAccountControlPoužívateľ, ktorého memberOf sa vracia prázdny, je fakt adresára, nie chyba doplnku, a účet, ktorý sa po deaktivácii stále overuje, znamená, že filtru chýba podmienka riadenia účtu. Najprv opravte tento dôkaz a potom znova spustite test s tromi účtami. Nechajte riadok logu, ktorý pomenoval zlyhaný krok, vedľa zmeny konfigurácie, aby ďalšia osoba mohla oddeliť autorizáciu od overovania bez opakovania vyhľadávania.