OpenVPNs LDAP-autentisering virker, men gruppekontrollen feiler: hvor du bør se

Innloggingsdataene går gjennom, tunnelen begynner å reise seg, og deretter feiler økten med en melding om gruppen snarere enn om passordet. Den kombinasjonen plasserer feilen i andre halvdel av LDAP-pluginnens arbeid: bindingen og passordkontrollen lyktes, og medlemskapsavgjørelsen som følger gjorde det ikke. Begge halvdeler leser fra samme konfigurasjonsblokk, og derfor kan en rettelse ett sted la den andre være urørt. Start ved logglinjen som navngir trinnet, ikke ved kontoen du tilfeldigvis tester med.

Behandle avvisningen som et autorisasjonssvar

Pluginnen utfører en tjenestebinding, søker etter kontoen, verifiserer passordet som ble oppgitt, og spør deretter om den kontoen tilhører en tillatt gruppe. Det er fire ulike operasjoner, og bare den siste handler om grupper. En avvisning som kommer etter en vellykket binding sier derfor ingenting om passordet, selv når klienten viser en generisk autentiseringsfeil. Å heve loggnivået til pluginnen før du endrer konfigurasjonen er det som skiller de fire i utdataene.

Se etter selve gruppevurderingen. Når ingen gruppespørring vises i det hele tatt, nås ikke autorisasjonsblokken, noe som vanligvis betyr at et direktiv står utenfor blokken som eier det, eller at et påkrevd alternativ mangler. Når spørringen vises og ikke returnerer noe, svarer endepunktet eller filteret på et annet spørsmål enn det du mente.

Avgjør om medlemskapet bor i filteret eller i en gruppeblokk

Det finnes to støttede former, og å blande dem er måten en fungerende konfigurasjon slutter å fungere på. Den første skyver medlemskapet inn i brukersøket ved å spørre etter et attributt på brukerobjektet; den andre lar brukersøket være og lar pluginnen slå opp gruppeobjektet etterpå. Velg én per utrulling og skriv ned hvilken du valgte.

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

Med den formen avgjør filteret alt, så RequireGroup må være false, ellers går pluginnen og leter etter et gruppeobjekt som filteret aldri nevnte. Attributtet i filteret må finnes på brukerobjektet og være fylt ut, noe som ikke er garantert når grupper er nestet.

Den andre formen holder søket enkelt og legger til et gruppeoppslag etter det. Gruppeobjektet navngis eksplisitt, og pluginnen sammenligner brukeren med medlemmene katalogen returnerer for den. Ingenting ved brukerfilteret endres, noe som gjør denne formen lettere å revidere når et annet team administrerer gruppen.

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

Den blinde flekken er felles: en enkel medlemskapssammenligning utvider ikke nestede grupper, så en konto hvis tilgang kommer gjennom en overordnet gruppe feiler mens konsollen fortsatt viser medlemskapet. Active Directory eksponerer member på gruppen, andre skjemaer bruker uniqueMember, og å peke på feil attributt returnerer et tomt resultat i stedet for en feil.

Velg et endepunkt som inneholder gruppeobjektet

URL-en avgjør hvilken katalog pluginnen spør, og en domenekontroller på port 389 svarer bare for sin egen navnekontekst. En global katalog på port 3268 svarer for hele skogen, skrivebeskyttet og med et delvis attributtsett. Når kontoene ligger i ett domene og VPN-gruppen i et annet, kan et enkeltdomene-søk finne brukeren og likevel overse medlemskapet. Det er tilfellet der flytting av URL-en til katalogporten løser avvisningen, og det er også tilfellet der folk generaliserer for langt.

Det delvise attributtsettet er grensen: et attributt katalogen ikke inneholder kan det ikke filtreres på, så den samme endringen kan få én utrulling til å virke og en annen til å returnere ingenting. Bekreft hva endepunktet faktisk returnerer for den ekte brukeren og gruppen før du skriver om blokken. Referaler og TLS er igjen egne forhold, siden en referal må følges og et endepunkt som krever TLS trenger de samsvarende tillitsfilene.

Hold kontotilstand og søkeomfang i sine egne felt

Deaktiveringsflagget hører i filteret, ikke i gruppekontrollen. I Active Directory er det den andre biten av userAccountControl, og uten den betingelsen autentiseres en deaktivert konto med gyldig passord og feiler deretter ved gruppetrinnet, noe som ser ut som en autorisasjonsfeil. Søkeomfang hører i basis-DN-en, fordi det er langsommere å starte ved domenets rot og kan treffe objekter utenfor organisasjonsenheten du ville dekke.

Hold også rettighetene til bind-kontoen smale. Brede katalogrettigheter gjør et feilkonfigurert filter til et vellykket søk og skjuler feilen til noen reviderer kontoen. Endre medlemskap i selve katalogen, aldri i en lokal unntaksliste, slik at det er nok å deaktivere kontoen for å fjerne tilgang. Hvis et annet team administrerer gruppen, bli enige om attributtet de fyller ut før du skriver et filter mot det.

Bevis resultatet med tre kontoer

Kjør konfigurasjonen mot tre identiteter: et tillatt medlem, en gyldig konto utenfor gruppen og en konto som er deaktivert. Hvis alle tre avvises, er bindingen eller gruppespørringen ødelagt; hvis alle tre godtas, brukes ingen gruppebetingelse i det hele tatt. Et blandet resultat er det eneste som beviser at konfigurasjonen skiller mellom tilfellene du bryr deg om.

Les de samme tre svarene direkte fra katalogen før du klandrer pluginnen. Den første spørringen viser gruppeattributtet filteret avhenger av, og den andre viser verdien for kontokontrollen. Bytt ut med din egen basis-DN, konto og endepunkt:

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

En bruker hvis memberOf kommer tomt tilbake, er et katalogfaktum, ikke en pluginfeil, og en konto som fortsatt autentiseres etter å ha blitt deaktivert, betyr at filteret mangler betingelsen for kontokontroll. Rett opp det beviset først, og kjør deretter tre-konto-testen på nytt. Hold logglinjen som navnga det feilende trinnet, ved siden av konfigurasjonsendringen, slik at neste person kan skille autorisasjon fra autentisering uten å gjenta søket.