OpenVPN LDAP-godkendelse virker, men gruppekontrollen fejler: hvor du skal kigge

Legitimationsoplysningerne går igennem, tunnelen begynder at komme op, og derefter fejler sessionen med en besked om gruppen snarere end om adgangskoden. Den kombination placerer fejlen i den anden halvdel af LDAP-pluginnets arbejde: bindingen og adgangskodekontrollen lykkedes, og medlemskabsbeslutningen, der følger, gjorde ikke. Begge halvdele læser fra samme konfigurationsblok, og derfor kan en rettelse ét sted lade den anden være urørt. Start ved den loglinje, der navngiver trinnet, ikke ved den konto, du tilfældigvis tester med.

Behandl afvisningen som et autorisationssvar

Pluginnet udfører en servicebinding, søger efter kontoen, verificerer den angivne adgangskode og spørger derefter, om den konto tilhører en tilladt gruppe. Det er fire forskellige operationer, og kun den sidste handler om grupper. En afvisning, der kommer efter en vellykket binding, siger derfor intet om adgangskoden, selv når klienten viser en generisk godkendelsesfejl. At hæve pluginnets logniveau, før du ændrer konfigurationen, er det, der adskiller de fire i outputtet.

Se efter selve gruppevurderingen. Når der slet ikke vises nogen gruppeforespørgsel, nås autorisationsblokken ikke, hvilket normalt betyder, at en direktiv står uden for den blok, der ejer den, eller at en påkrævet indstilling mangler. Når forespørgslen vises og ikke returnerer noget, svarer slutpunktet eller filteret på et andet spørgsmål end det, du mente.

Afgør, om medlemskab ligger i filteret eller i en gruppeblok

Der er to understøttede former, og at blande dem er måden, hvorpå en fungerende konfiguration holder op med at fungere. Den første skubber medlemskab ind i brugersøgningen ved at spørge efter en attribut på brugerobjektet; den anden lader brugersøgningen være og får pluginnet til at slå gruppeobjektet op bagefter. Vælg én for hver udrulning, 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 form afgør filteret alt, så RequireGroup skal være false, ellers går pluginnet på jagt efter et gruppeobjekt, som filteret aldrig har nævnt. Attributten i filteret skal findes på brugerobjektet og være udfyldt, hvilket ikke er garanteret, når grupper er indlejrede.

Den anden form holder søgningen enkel og tilføjer et gruppeopslag efter den. Gruppeobjektet navngives eksplicit, og pluginnet sammenligner brugeren med de medlemmer, kataloget returnerer for den. Intet ved brugerfilteret ændres, hvilket gør denne form lettere at revidere, når et andet 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>

Det blinde punkt er fælles: en simpel medlemskabssammenligning udvider ikke indlejrede grupper, så en konto, hvis adgang kommer gennem en overordnet gruppe, fejler, mens konsollen stadig viser medlemskabet. Active Directory eksponerer member på gruppen, andre skemaer bruger uniqueMember, og at pege på den forkerte attribut returnerer et tomt resultat i stedet for en fejl.

Vælg et slutpunkt, der rummer gruppeobjektet

URL’en afgør, hvilket katalog pluginnet spørger, og en domænecontroller på port 389 svarer kun for sin egen navngivningskontekst. En global katalog på port 3268 svarer for hele skoven, skrivebeskyttet og med et delvist attributsæt. Når kontoerne ligger i ét domæne og VPN-gruppen i et andet, kan en enkeltdomæneforespørgsel finde brugeren og alligevel overse medlemskabet. Det er tilfældet, hvor flytning af URL’en til katalogporten løser afvisningen, og det er også tilfældet, hvor folk generaliserer for langt.

Det delvise attributsæt er grænsen: en attribut, som kataloget ikke rummer, kan der ikke filtreres på, så den samme ændring kan få én udrulning til at virke og en anden til at returnere intet. Bekræft, hvad slutpunktet faktisk returnerer for den rigtige bruger og gruppe, før du omskriver blokken. Viderestillinger og TLS er igen særskilte forhold, da en viderestilling skal følges, og et slutpunkt, der kræver TLS, har brug for de matchende tillidsfiler.

Hold kontotilstand og søgeområde i deres egne felter

Deaktiveringsflaget hører i filteret, ikke i gruppekontrollen. I Active Directory er det den anden bit af userAccountControl, og uden den betingelse godkendes en deaktiveret konto med en gyldig adgangskode og fejler derefter ved gruppetrinnet, hvilket ser ud som en autorisationsfejl. Søgeområde hører i basis-DN’et, fordi det er langsommere at starte ved domæneroden og kan ramme objekter uden for den organisatoriske enhed, du ville dække.

Hold også bind-kontoens rettigheder snævre. Brede katalogrettigheder gør et fejlkonfigureret filter til en vellykket forespørgsel og skjuler fejlen, indtil nogen reviderer kontoen. Skift medlemskab i selve kataloget, aldrig i en lokal undtagelsesliste, så det er nok at deaktivere kontoen for at fjerne adgang. Hvis et andet team administrerer gruppen, aftal den attribut, de udfylder, før du skriver et filter mod den.

Bevis resultatet med tre konti

Kør konfigurationen mod tre identiteter: et tilladt medlem, en gyldig konto uden for gruppen og en konto, der er blevet deaktiveret. Hvis alle tre afvises, er bindingen eller gruppeforespørgslen i stykker; hvis alle tre accepteres, anvendes ingen gruppebetingelse overhovedet. Et blandet resultat er det eneste udfald, der beviser, at konfigurationen skelner de tilfælde, du har brug for.

Læs de samme tre svar direkte fra kataloget, før du bebrejder pluginnet. Den første forespørgsel viser den gruppeattribut, filteret afhænger af, og den anden viser værdien for kontokontrol. Erstat med dit eget basis-DN, din konto og dit slutpunkt:

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 bruger, hvis memberOf kommer tomt tilbage, er et katalogfaktum, ikke en pluginfejl, og en konto, der stadig godkendes efter at være blevet deaktiveret, betyder, at filteret mangler kontokontrolbetingelsen. Ret det bevis først, og kør derefter tre-konto-testen igen. Hold loglinjen, der navngav det fejlende trin, ved siden af konfigurationsændringen, så den næste person kan skelne autorisation fra godkendelse uden at gentage søgningen.