LDAP-autentiseringa i OpenVPN fungerer, men gruppekontrollen feilar: kvar du bør sjå

Autentiseringa kan gå gjennom medan gruppekontrollen avviser alle. Gå gjennom Authorization-blokka, medlemsattributtet og katalogendepunktet etter tur.

Innloggingsdataa går gjennom, tunnelen byrjar å reise seg, og deretter feilar økta med ei melding om gruppa snarare enn om passordet. Den kombinasjonen plasserer feilen i andre halvdel av arbeidet til LDAP-pluginen: bindinga og passordkontrollen lukkast, og medlemskapsavgjerda som følgjer gjorde det ikkje. Begge halvdelane les frå same konfigurasjonsblokk, og difor kan ei retting på éin stad la den andre vere urørt. Start ved logglinja som namngir steget, ikkje ved kontoen du tilfeldigvis testar med.

Behandle avvisinga som eit autorisasjonssvar

Pluginen utfører ei tenestebinding, søkjer etter kontoen, stadfester passordet som vart oppgitt, og spør deretter om den kontoen høyrer til ei tillaten gruppe. Det er fire ulike operasjonar, og berre den siste handlar om grupper. Ei avvising som kjem etter ei vellukka binding seier difor ingenting om passordet, sjølv når klienten viser ein generisk autentiseringsfeil. Å heve loggnivået til pluginen før du endrar konfigurasjonen er det som skil dei fire i utdataa.

Sjå etter sjølve gruppevurderinga. Når inga gruppespørjing blir vist i det heile, blir ikkje autorisasjonsblokka nådd, noko som vanlegvis betyr at eit direktiv står utanfor blokka som eig det, eller at eit påkravt alternativ manglar. Når spørjinga blir vist og ikkje returnerer noko, svarar endepunktet eller filteret på eit anna spørsmål enn det du meinte.

Avgjer om medlemskapet bur i filteret eller i ei gruppeblokk

Det finst to støtta former, og å blande dei er måten ein fungerande konfigurasjon sluttar å fungere på. Den første skyv medlemskapet inn i brukarsøket ved å spørje etter eit attributt på brukarobjektet; den andre lèt brukarsøket vere og lèt pluginen slå opp gruppeobjektet etterpå. Vel éi per utrulling og skriv ned kva du valde.

<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 forma avgjer filteret alt, så RequireGroup må vere false, elles går pluginen og leitar etter eit gruppeobjekt som filteret aldri nemnde. Attributtet i filteret må finnast på brukarobjektet og vere fylt ut, noko som ikkje er garantert når grupper er nesta.

Den andre forma held søket enkelt og legg til eit gruppeoppslag etter det. Gruppeobjektet blir namngjeve eksplisitt, og pluginen samanliknar brukaren med medlemene katalogen returnerer for det. Ingenting ved brukarfilteret blir endra, noko som gjer denne forma lettare å revidere når eit anna team administrerer gruppa.

<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: ein enkel medlemskapssamanlikning utvidar ikkje nesta grupper, så ein konto der tilgangen kjem gjennom ei overordna gruppe feilar medan konsollen framleis viser medlemskapet. Active Directory eksponerer member på gruppa, andre skjema brukar uniqueMember, og å peike på feil attributt returnerer eit tomt resultat i staden for ein feil.

Vel eit endepunkt som inneheld gruppeobjektet

URL-en avgjer kva katalog pluginen spør, og ein domenekontrollør på port 389 svarar berre for sin eigen namnekontekst. Ein global katalog på port 3268 svarar for heile skogen, skriveverna og med eit delvis attributtsett. Når kontoane ligg i eitt domene og VPN-gruppa i eit anna, kan eit enkeltdomene-søk finne brukaren og likevel oversjå medlemskapet. Det er tilfellet der flytting av URL-en til katalogporten løyser avvisinga, og det er òg tilfellet der folk generaliserer for langt.

Det delvise attributtsettet er grensa: eit attributt katalogen ikkje inneheld kan ein ikkje filtrere på, så den same endringa kan få éi utrulling til å fungere og ei anna til å returnere ingenting. Stadfest kva endepunktet faktisk returnerer for den verkelege brukaren og gruppa før du skriv om blokka. Referalar og TLS er igjen eigne tilhøve, sidan ein referal må følgjast og eit endepunkt som krev TLS treng dei samsvarande tillitsfilene.

Hald kontotilstand og søkjeomfang i sine eigne felt

Deaktiveringsflagget høyrer i filteret, ikkje i gruppekontrollen. I Active Directory er det den andre biten av userAccountControl, og utan den vilkåret autentiserer ein deaktivert konto med gyldig passord og feilar deretter ved gruppesteget, noko som ser ut som ein autorisasjonsfeil. Søkjeomfang høyrer i basis-DN-en, fordi det er tregare å starte ved rota av domenet og kan treffe objekt utanfor organisasjonseininga du ville dekkje.

Hald òg rettane til bind-kontoen smale. Breie katalogrettar gjer eit feilkonfigurert filter til eit vellukka søk og skjuler feilen til nokon reviderer kontoen. Endre medlemskap i sjølve katalogen, aldri i ei lokal unntaksliste, slik at det er nok å deaktivere kontoen for å fjerne tilgang. Viss eit anna team administrerer gruppa, bli einige om attributtet dei fyller ut før du skriv eit filter mot det.

Prov resultatet med tre kontoar

Køyr konfigurasjonen mot tre identitetar: eit tillate medlem, ein gyldig konto utanfor gruppa og ein konto som er deaktivert. Viss alle tre blir avviste, er bindinga eller gruppespørjinga øydelagd; viss alle tre blir godtekne, blir inga gruppevilkår brukt i det heile. Eit blanda resultat er det einaste som provar at konfigurasjonen skil mellom tilfella du bryr deg om.

Les dei same tre svara direkte frå katalogen før du klandrar pluginen. Den første spørjinga viser gruppeattributtet filteret er avhengig av, og den andre viser verdien for kontokontrollen. Byt ut med din eigen 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

Ein brukar der memberOf kjem tomt tilbake, er eit katalogfaktum, ikkje ein pluginfeil, og ein konto som framleis autentiserer etter å ha blitt deaktivert, betyr at filteret manglar vilkåret for kontokontroll. Rett opp det beviset først, og køyr deretter tre-konto-testen på nytt. Hald logglinja som namngav det feilande steget, ved sida av konfigurasjonsendringa, slik at neste person kan skilje autorisasjon frå autentisering utan å gjenta søket.

Relaterte artiklar