OpenVPNin LDAP-todennus toimii, mutta ryhmätarkistus epäonnistuu: mistä katsoa

Tunnistetiedot menevät läpi, tunneli alkaa nousta ja sitten istunto epäonnistuu viestiin, joka kertoo ryhmästä eikä salasanasta. Tämä yhdistelmä sijoittaa vian LDAP-liitännäisen työn toiseen puoliskoon: sidonta ja salasanan tarkistus onnistuivat, mutta sitä seuraava jäsenyyspäätös ei. Molemmat puoliskot lukevat samasta asetuskohdasta, minkä vuoksi korjaus yhdessä paikassa voi jättää toisen koskemattomaksi. Aloita lokiriviltä, joka nimeää vaiheen, älä tililtä, jolla satut testaamaan.

Kohtele hylkäystä valtuutusvastauksena

Liitännäinen tekee palvelusidoksen, etsii tilin, varmistaa annetun salasanan ja kysyy sitten, kuuluuko tili sallittuun ryhmään. Nämä ovat neljä erillistä toimintoa, ja vain viimeinen koskee ryhmiä. Onnistuneen sidonnan jälkeen tuleva hylkäys ei siis kerro salasanasta mitään, vaikka asiakas näyttäisi yleisen todennusvirheen. Liitännäisen lokitason nostaminen ennen asetuksen muuttamista on se, mikä erottaa neljä toisistaan tulosteessa.

Etsi itse ryhmän arviointi. Kun ryhmäkyselyä ei ilmesty lainkaan, valtuutuslohkoon ei päästä, mikä yleensä tarkoittaa, että direktiivi on sen omistavan lohkon ulkopuolella tai pakollinen asetus puuttuu. Kun kysely ilmestyy eikä palauta mitään, päätepiste tai suodatin vastaa eri kysymykseen kuin tarkoitit.

Päätä, asuuko jäsenyys suodattimessa vai ryhmälohkossa

Tuettuja muotoja on kaksi, ja niiden sekoittaminen on tapa, jolla toimiva asetus lakkaa toimimasta. Ensimmäinen työntää jäsenyyden käyttäjähakuun kysymällä määritettä käyttäjäobjektilta; toinen jättää käyttäjahaun rauhaan ja antaa liitännäisen etsiä ryhmäobjektin myöhemmin. Valitse yksi käyttöönottoa kohden ja kirjoita muistiin, kumman valitsit.

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

Tässä muodossa suodatin päättää kaikesta, joten RequireGroup on oltava false, muuten liitännäinen lähtee etsimään ryhmäobjektia, jota suodatin ei koskaan maininnut. Suodattimen määritteen on oltava käyttäjäobjektilla ja täytettynä, mitä ei taata, kun ryhmät ovat sisäkkäisiä.

Toinen muoto pitää haun yksinkertaisena ja lisää sen jälkeen ryhmähaun. Ryhmäobjekti nimetään nimenomaisesti, ja liitännäinen vertaa käyttäjää jäseniin, jotka hakemisto sille palauttaa. Käyttäjäsuodattimessa ei muutu mikään, mikä tekee tästä muodosta helpomman auditoida, kun toinen tiimi hallinnoi ryhmää.

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

Sokea piste on yhteinen: yksinkertainen jäsenyysvertailu ei laajenna sisäkkäisiä ryhmiä, joten tili, jonka pääsy tulee yliryhmän kautta, epäonnistuu, kun konsoli näyttää jäsenyyden edelleen. Active Directory paljastaa member ryhmässä, muut skeemat käyttävät uniqueMember, ja väärään määritteeseen osoittaminen palauttaa tyhjän tuloksen virheen sijaan.

Valitse päätepiste, joka sisältää ryhmäobjektin

URL päättää, miltä hakemistolta liitännäinen kysyy, ja toimialueen ohjain portissa 389 vastaa vain omasta nimitilastaan. Globaali luettelo portissa 3268 vastaa koko metsästä, vain luku -tilassa ja osittaisella määritejoukolla. Kun tilit ovat yhdessä toimialueessa ja VPN-ryhmä toisessa, yhden toimialueen kysely voi löytää käyttäjän ja silti ohittaa jäsenyyden. Tämä on se tapaus, jossa URL:n siirtäminen luettelon porttiin ratkaisee hylkäyksen, ja se on myös tapaus, jossa ihmiset yleistävät liikaa.

Osittainen määritejoukko on raja: määritettä, jota luettelo ei sisällä, ei voi suodattaa, joten sama muutos voi saada yhden käyttöönoton toimimaan ja toisen palauttamaan tyhjää. Varmista, mitä päätepiste todella palauttaa todelliselle käyttäjälle ja ryhmälle, ennen kuin kirjoitat lohkon uudelleen. Uudelleenohjaukset ja TLS ovat jälleen eri asioita, koska uudelleenohjausta on seurattava ja TLS:ää vaativa päätepiste tarvitsee vastaavat luottamustiedostot.

Pidä tilin tila ja haun laajuus omissa kentissään

Poistokäytössä-merkintä kuuluu suodattimeen, ei ryhmätarkistukseen. Active Directoryssa se on userAccountControl toinen bitti, ja ilman sitä ehtoa käytöstä poistettu tili, jolla on kelvollinen salasana, todennetaan ja epäonnistuu sitten ryhmävaiheessa, mikä näyttää valtuutusvirheeltä. Haun laajuus kuuluu perus-DN:ään, koska toimialueen juuresta aloittaminen on hitaampaa ja voi osua objekteihin sen organisaatioyksikön ulkopuolella, jonka halusit kattaa.

Pidä myös sidontatilin oikeudet kapeina. Laajat hakemisto-oikeudet muuttavat väärin määritetyn suodattimen onnistuneeksi kyselyksi ja piilottavat vian, kunnes joku auditoi tilin. Muuta jäsenyyttä itse hakemistossa, älä koskaan paikallisessa poikkeusluettelossa, jotta tilin poistaminen käytöstä riittää pääsyn poistamiseen. Jos toinen tiimi hallinnoi ryhmää, sovi määritteestä, jonka he täyttävät, ennen kuin kirjoitat sitä vasten suodattimen.

Todista tulos kolmella tilillä

Aja asetus kolmea identiteettiä vasten: sallittu jäsen, kelvollinen tili ryhmän ulkopuolella ja tili, joka on poistettu käytöstä. Jos kaikki kolme hylätään, sidonta tai ryhmäkysely on rikki; jos kaikki kolme hyväksytään, mitään ryhmäehtoa ei sovelleta lainkaan. Sekatulos on ainoa lopputulos, joka todistaa, että asetus erottaa ne tapaukset, joilla on sinulle merkitystä.

Lue samat kolme vastausta suoraan hakemistosta ennen kuin syytät liitännäistä. Ensimmäinen kysely näyttää sen ryhmämääritteen, josta suodatin riippuu, ja toinen näyttää tilin hallinnan arvon. Korvaa omalla perus-DN:lläsi, tililläsi ja päätepisteelläsi:

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

Käyttäjä, jonka memberOf palaa tyhjänä, on hakemiston tosiasia, ei liitännäisen vika, ja tili, joka todennetaan edelleen käytöstä poistamisen jälkeen, tarkoittaa, että suodattimesta puuttuu tilin hallinnan ehto. Korjaa ensin se todiste ja aja sitten kolmen tilin testi uudelleen. Pidä lokirivi, joka nimesi epäonnistuneen vaiheen, asetusmuutoksen vieressä, jotta seuraava henkilö voi erottaa valtuutuksen todennuksesta toistamatta hakua.