Az OpenVPN LDAP-hitelesítése működik, de a csoportellenőrzés elbukik: hol keressük a hibát

A hitelesítés átmehet, miközben a csoportellenőrzés mindenkit elutasít. Vizsgálja meg sorra az Authorization blokkot, a tagsági attribútumot és a könyvtár végpontját.

A hitelesítő adatok átmennek, az alagút elkezd feljönni, majd a munkamenet a csoportra, nem pedig a jelszóra vonatkozó üzenettel elbukik. Ez a kombináció a hibát az LDAP beépülő munka második felébe helyezi: a kötés és a jelszóellenőrzés sikerült, a rákövetkező tagsági döntés pedig nem. Mindkét fél ugyanabból a konfigurációs blokkból olvas, ezért az egyik helyen végzett javítás érintetlenül hagyhatja a másikat. A lépést megnevező naplósorral kezdje, ne azzal a fiókkal, amellyel éppen véletlenül tesztel.

Tekintse az elutasítást engedélyezési válasznak

A beépülő szolgáltatáskötést végez, megkeresi a fiókot, ellenőrzi a megadott jelszót, majd megkérdezi, hogy ez a fiók egy engedélyezett csoporthoz tartozik-e. Ez négy különálló művelet, és csak az utolsó szól csoportokról. Ezért a sikeres kötés után érkező elutasítás semmit sem mond a jelszóról, még akkor sem, ha az ügyfél általános hitelesítési hibát jelez. A beépülő naplószintjének emelése a konfiguráció módosítása előtt az, ami a négyet a kimenetben szétválasztja.

Magát a csoportértékelést keresse. Ha egyáltalán nem jelenik meg csoportlekérdezés, az engedélyezési blokk nem érhető el, ami általában azt jelenti, hogy egy direktíva az őt birtokló blokkon kívül áll, vagy hiányzik egy kötelező beállítás. Ha a lekérdezés megjelenik és nem ad vissza semmit, a végpont vagy a szűrő más kérdésre válaszol, mint amelyet ön szándékolt.

Döntse el, a szűrőben vagy egy csoportblokkban él-e a tagság

Két támogatott forma van, és ezek keverése az, ahogyan egy működő konfiguráció abbahagyja a működést. Az első a felhasználói objektum attribútumát kérve tolja a tagságot a felhasználókeresésbe; a második békén hagyja a felhasználókeresést, és a beépülővel utóbb megkeresteti a csoportobjektumot. Válasszon egyet üzembe helyezésenként, és írja le, melyiket választotta.

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

Ennél a formánál a szűrő dönt mindenről, ezért a RequireGroup értékének false-nak kell lennie, különben a beépülő olyan csoportobjektumot keres, amelyet a szűrő soha nem említett. A szűrőben szereplő attribútumnak léteznie kell a felhasználói objektumon és ki kell lennie töltve, ami nem garantált, ha a csoportok beágyazottak.

A másik forma egyszerűen tartja a keresést, és utána hozzáad egy csoportkeresést. A csoportobjektumot kifejezetten megnevezi, és a beépülő összehasonlítja a felhasználót azokkal a tagokkal, akiket a könyvtár számára visszaad. A felhasználói szűrőben semmi sem változik, ami ezt a formát könnyebben auditálhatóvá teszi, ha a csoportot másik csapat kezeli.

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

A vakfolt közös: az egyszerű tagsági összehasonlítás nem bontja ki a beágyazott csoportokat, ezért egy fiók, amelynek hozzáférése szülőcsoporton keresztül érkezik, elbukik, miközben a konzol továbbra is mutatja a tagságot. Az Active Directory a csoporton teszi elérhetővé a member attribútumot, más sémák a uniqueMember attribútumot használják, és a rossz attribútumra mutatás hiba helyett üres eredményt ad.

Olyan végpontot válasszon, amely tartalmazza a csoportobjektumot

Az URL dönti el, melyik könyvtárat kérdezi a beépülő, és a 389 porton lévő tartományvezérlő csak a saját névteréért válaszol. A 3268 porton lévő globális katalógus az egész erdőért válaszol, csak olvashatóan és részleges attribútumkészlettel. Ha a fiókok az egyik tartományban, a VPN-csoport pedig egy másikban van, az egytartományos lekérdezés megtalálhatja a felhasználót, és mégis elvéti a tagságot. Ez az az eset, amikor az URL katalógusportra mozgatása megoldja az elutasítást, és ez az az eset is, amikor az emberek túl messzire általánosítanak.

A részleges attribútumkészlet a határ: olyan attribútumra, amelyet a katalógus nem tartalmaz, nem lehet szűrni, ezért ugyanaz a változtatás az egyik üzembe helyezést működésre bírhatja, a másikat pedig üresen hagyhatja. A blokk újraírása előtt erősítse meg, mit ad vissza a végpont valójában a valódi felhasználó és csoport számára. Az átirányítások és a TLS megint külön kérdések, hiszen az átirányítást követni kell, és a TLS-t igénylő végpontnak megfelelő bizalmi fájlokra van szüksége.

Tartsa a fiókállapotot és a keresési hatókört a saját mezőikben

A letiltás jelzője a szűrőhöz tartozik, nem a csoportellenőrzéshez. Az Active Directoryban ez a userAccountControl második bitje, és e feltétel nélkül egy letiltott fiók érvényes jelszóval hitelesít, majd elbukik a csoportlépésnél, ami engedélyezési hibának látszik. A keresési hatókör az alap-DN-hez tartozik, mert a tartomány gyökerétől indulni lassabb, és olyan objektumokat is eltalálhat, amelyek a lefedni kívánt szervezeti egységen kívül vannak.

Tartsa szűken a kötési fiók jogait is. A széles könyvtárjogok sikeres lekérdezéssé alakítanak egy hibásan beállított szűrőt, és elrejtik a hibát, amíg valaki meg nem auditálja a fiókot. A tagságot magában a könyvtárban módosítsa, soha ne helyi kivétellistában, hogy a fiók letiltása elegendő legyen a hozzáférés eltávolításához. Ha másik csapat kezeli a csoportot, egyeztessen az attribútumról, amelyet kitöltenek, mielőtt szűrőt írna rá.

Bizonyítsa az eredményt három fiókkal

Futtassa a konfigurációt három identitás ellen: egy engedélyezett tag, egy érvényes fiók a csoporton kívül, és egy fiók, amelyet letiltottak. Ha mindhármat elutasítják, a kötés vagy a csoportlekérdezés hibás; ha mindhármat elfogadják, egyáltalán nem érvényesül csoportfeltétel. A vegyes eredmény az egyetlen, amely bizonyítja, hogy a konfiguráció megkülönbözteti az ön számára fontos eseteket.

Ugyanazt a három választ olvassa ki közvetlenül a könyvtárból, mielőtt a beépülőt hibáztatná. Az első lekérdezés a szűrő által használt csoportattribútumot mutatja, a második pedig a fiókvezérlés értékét. Cserélje ki a saját alap-DN-jére, fiókjára és végpontjára:

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

Egy felhasználó, akinek a memberOf üresen jön vissza, könyvtári tény, nem a beépülő hibája, és egy fiók, amely letiltás után is hitelesít, azt jelenti, hogy a szűrőből hiányzik a fiókvezérlés feltétele. Először ezt a bizonyítékot javítsa, majd futtassa újra a háromfiókos tesztet. Tartsa a sikertelen lépést megnevező naplósort a konfigurációváltozás mellett, hogy a következő ember a keresés megismétlése nélkül választhassa szét az engedélyezést a hitelesítéstől.

Kapcsolódó cikkek