Preverjanje pristnosti LDAP v OpenVPN deluje, a preverjanje skupine ne uspe: kam pogledati

Preverjanje pristnosti lahko uspe, medtem ko preverjanje skupine zavrne vse. Preglejte blok Authorization, atribut članstva in končno točko imenika po vrsti.

Poverilnice gredo skozi, tunel se začne dvigovati, nato pa seja spodleti s sporočilom o skupini in ne o geslu. Ta kombinacija postavi napako v drugo polovico dela vtičnika LDAP: povezava in preverjanje gesla sta uspela, odločitev o članstvu, ki sledi, pa ne. Obe polovici bereta iz istega konfiguracijskega bloka, zato lahko popravek na enem mestu pusti drugo nedotaknjeno. Začnite pri vrstici dnevnika, ki poimenuje korak, ne pri računu, s katerim slučajno testirate.

Zavrnitev obravnavajte kot odgovor o avtorizaciji

Vtičnik izvede storitveno povezavo, poišče račun, preveri poslano geslo in nato vpraša, ali ta račun pripada dovoljeni skupini. To so štiri ločene operacije in le zadnja se nanaša na skupine. Zato zavrnitev, ki pride po uspešni povezavi, ne pove ničesar o geslu, tudi ko odjemalec prikaže splošno napako preverjanja pristnosti. Dvig ravni dnevnika vtičnika pred spremembo konfiguracije je tisto, kar te štiri v izpisu loči.

Poiščite samo oceno skupine. Ko se ne pojavi nobena poizvedba o skupini, blok avtorizacije ni dosežen, kar običajno pomeni, da direktiva stoji zunaj bloka, ki ji pripada, ali da manjka obvezna možnost. Ko se poizvedba pojavi in ne vrne ničesar, končna točka ali filter odgovarja na drugo vprašanje od tistega, ki ste ga imeli v mislih.

Odločite, ali članstvo živi v filtru ali v bloku skupine

Obstajata dve podprti obliki in njuno mešanje je način, kako delujoča konfiguracija neha delovati. Prva potisne članstvo v iskanje uporabnikov z zahtevo po atributu na uporabniškem objektu; druga pusti iskanje uporabnikov pri miru in vtičniku omogoči, da pozneje poišče objekt skupine. Izberite eno na uvedbo in zapišite, katero ste izbrali.

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

Pri tej obliki filter odloči o vsem, zato mora biti RequireGroup false, sicer vtičnik odide iskat objekt skupine, ki ga filter nikoli ni omenil. Atribut v filtru mora obstajati na uporabniškem objektu in biti izpolnjen, kar ni zagotovljeno, ko so skupine gnezdene.

Druga oblika ohranja iskanje preprosto in doda iskanje skupine za njim. Objekt skupine je izrecno poimenovan, vtičnik pa primerja uporabnika s člani, ki jih imenik zanj vrne. V uporabniškem filtru se nič ne spremeni, kar to obliko naredi lažjo za revizijo, ko skupino upravlja druga ekipa.

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

Slepa pega je skupna: preprosta primerjava članstva ne razširi gnezdenih skupin, zato račun, katerega dostop pride prek nadrejene skupine, spodleti, medtem ko konzola še vedno prikazuje članstvo. Active Directory razkrije member na skupini, druge sheme uporabljajo uniqueMember, kažipot na napačen atribut pa vrne prazen rezultat namesto napake.

Izberite končno točko, ki vsebuje objekt skupine

URL odloči, kateri imenik vtičnik vpraša, domenski krmilnik na vratih 389 pa odgovarja le za svoj lastni imenski kontekst. Globalni katalog na vratih 3268 odgovarja za cel gozd, samo za branje in z delnim naborom atributov. Ko so računi v eni domeni, skupina VPN pa v drugi, lahko poizvedba v eni domeni najde uporabnika in vseeno zgreši članstvo. To je primer, ko premik URL na vrata kataloga reši zavrnitev, in to je tudi primer, ko ljudje preveč posplošujejo.

Delni nabor atributov je meja: atributa, ki ga katalog ne vsebuje, ni mogoče filtrirati, zato lahko ista sprememba eno uvedbo požene in druga vrne nič. Preden prepišete blok, potrdite, kaj končna točka v resnici vrne za pravega uporabnika in skupino. Preusmeritve in TLS so spet ločene zadeve, saj je treba preusmeritev slediti, končna točka, ki zahteva TLS, pa potrebuje ustrezne datoteke zaupanja.

Ohranite stanje računa in obseg iskanja v njunih lastnih poljih

Zastavica onemogočeno pripada filtru, ne preverjanju skupine. V Active Directory je to drugi bit userAccountControl, in brez tega pogoja se onemogočen račun z veljavnim geslom preveri in nato spodleti pri koraku skupine, kar je videti kot napaka avtorizacije. Obseg iskanja pripada osnovnemu DN, ker je začetek v korenu domene počasnejši in lahko zadene objekte zunaj organizacijske enote, ki ste jo želeli pokriti.

Tudi pravice računa za povezavo naj bodo ozke. Široke pravice v imeniku spremenijo napačno nastavljen filter v uspešno poizvedbo in skrijejo napako, dokler nekdo ne revidira računa. Članstvo spreminjajte v imeniku samem, nikoli na lokalnem seznamu izjem, da zadostuje onemogočanje računa za odvzem dostopa. Če skupino upravlja druga ekipa, se dogovorite o atributu, ki ga izpolnjujejo, preden nanj napišete filter.

Dokažite rezultat s tremi računi

Zaženite konfiguracijo proti trem identitetam: dovoljeni član, veljaven račun zunaj skupine in račun, ki je bil onemogočen. Če so vsi trije zavrnjeni, sta povezava ali poizvedba skupine pokvarjeni; če so vsi trije sprejeti, se ne uveljavlja noben pogoj skupine. Mešani rezultat je edini, ki dokaže, da konfiguracija razlikuje primere, ki so za vas pomembni.

Preberite iste tri odgovore neposredno iz imenika, preden obtožite vtičnik. Prva poizvedba pokaže atribut skupine, od katerega je odvisen filter, druga pa pokaže vrednost nadzora računa. Nadomestite s svojim osnovnim DN, računom in končno točko:

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

Uporabnik, katerega memberOf se vrne prazen, je dejstvo imenika, ne napaka vtičnika, račun, ki se po onemogočenju še vedno preveri, pa pomeni, da filtru manjka pogoj nadzora računa. Najprej popravite ta dokaz, nato znova zaženite test s tremi računi. Vrstico dnevnika, ki je poimenovala neuspeli korak, hranite ob spremembi konfiguracije, da bo naslednja oseba lahko ločila avtorizacijo od preverjanja pristnosti brez ponavljanja iskanja.

Sorodni članki