OpenVPNs LDAP-autentisering fungerar men gruppkontrollen misslyckas: var du ska titta

Autentiseringen kan gå igenom medan gruppkontrollen avvisar alla. Gå igenom Authorization-blocket, medlemsattributet och katalogändpunkten i tur och ordning.

Inloggningsuppgifterna går igenom, tunneln börjar resa sig och sedan misslyckas sessionen med ett meddelande om gruppen snarare än om lösenordet. Den kombinationen placerar felet i den andra halvan av LDAP-plugginens arbete: bindningen och lösenordskontrollen lyckades, och medlemskapsbeslutet som följer gjorde det inte. Båda halvorna läser från samma konfigurationsblock, därför kan en rättelse på ett ställe lämna den andra orörd. Börja vid loggraden som namnger steget, inte vid kontot du råkar testa med.

Behandla avvisningen som ett auktoriseringssvar

Pluginen utför en tjänstebindning, söker efter kontot, verifierar lösenordet som angetts och frågar sedan om kontot tillhör en tillåten grupp. Det är fyra separata operationer, och bara den sista handlar om grupper. En avvisning som kommer efter en lyckad bindning säger därför ingenting om lösenordet, även när klienten visar ett allmänt autentiseringsfel. Att höja plugginens loggnivå innan du ändrar konfigurationen är det som skiljer de fyra åt i utdata.

Leta efter själva gruppbedömningen. När ingen gruppfråga visas alls nås inte auktoriseringsblocket, vilket vanligtvis betyder att ett direktiv står utanför blocket som äger det eller att ett obligatoriskt alternativ saknas. När frågan visas och inte returnerar något svarar ändpunkten eller filtret på en annan fråga än den du menade.

Avgör om medlemskapet bor i filtret eller i ett gruppblock

Det finns två stödda former, och att blanda dem är sättet en fungerande konfiguration slutar fungera. Den första trycker in medlemskapet i användarsökningen genom att fråga efter ett attribut på användarobjektet; den andra låter användarsökningen vara och låter pluginen slå upp gruppobjektet efteråt. Välj en per utrullning och skriv ner vilken 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 formen avgör filtret allt, så RequireGroup måste vara false, annars går pluginen och letar efter ett gruppobjekt som filtret aldrig nämnde. Attributet i filtret måste finnas på användarobjektet och vara ifyllt, vilket inte är garanterat när grupper är nästlade.

Den andra formen håller sökningen enkel och lägger till ett gruppuppslag efter den. Gruppobjektet namnges uttryckligen, och pluginen jämför användaren med de medlemmar katalogen returnerar för det. Ingenting i användarfiltret ändras, vilket gör den här formen lättare att granska när ett annat team administrerar 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 blinda fläcken är gemensam: en enkel medlemskapsjämförelse expanderar inte nästlade grupper, så ett konto vars åtkomst kommer via en överordnad grupp misslyckas medan konsolen fortfarande visar medlemskapet. Active Directory exponerar member på gruppen, andra scheman använder uniqueMember, och att peka på fel attribut returnerar ett tomt resultat i stället för ett fel.

Välj en ändpunkt som innehåller gruppobjektet

URL:en avgör vilken katalog pluginen frågar, och en domänkontrollant på port 389 svarar bara för sin egen namnkontext. En global katalog på port 3268 svarar för hela skogen, skrivskyddad och med en partiell attributmängd. När kontona ligger i en domän och VPN-gruppen i en annan kan en sökning i en enda domän hitta användaren och ändå missa medlemskapet. Det är fallet där flytten av URL:en till katalogporten löser avvisningen, och det är också fallet där människor generaliserar för långt.

Den partiella attributmängden är gränsen: ett attribut som katalogen inte innehåller går inte att filtrera på, så samma ändring kan få en utrullning att fungera och en annan att returnera ingenting. Bekräfta vad ändpunkten faktiskt returnerar för den verkliga användaren och gruppen innan du skriver om blocket. Hänvisningar och TLS är återigen egna frågor, eftersom en hänvisning måste följas och en ändpunkt som kräver TLS behöver motsvarande förtroendefiler.

Håll kontostatus och sökomfång i sina egna fält

Inaktiveringsflaggan hör hemma i filtret, inte i gruppkontrollen. I Active Directory är det den andra biten i userAccountControl, och utan det villkoret autentiseras ett inaktiverat konto med giltigt lösenord och misslyckas sedan vid gruppsteget, vilket ser ut som en auktoriseringsbugg. Sökomfånget hör hemma i bas-DN:en, eftersom det är långsammare att börja vid domänroten och kan träffa objekt utanför den organisationsenhet du ville täcka.

Håll också bindningskontots rättigheter snäva. Breda katalogrättigheter förvandlar ett felkonfigurerat filter till en lyckad sökning och döljer felet tills någon granskar kontot. Ändra medlemskap i själva katalogen, aldrig i en lokal undantagslista, så att det räcker att inaktivera kontot för att ta bort åtkomst. Om ett annat team administrerar gruppen, kom överens om attributet de fyller i innan du skriver ett filter mot det.

Bevisa resultatet med tre konton

Kör konfigurationen mot tre identiteter: en tillåten medlem, ett giltigt konto utanför gruppen och ett konto som har inaktiverats. Om alla tre avvisas är bindningen eller gruppfrågan trasig; om alla tre accepteras tillämpas ingen gruppvillkor alls. Ett blandat resultat är det enda som bevisar att konfigurationen skiljer på de fall du bryr dig om.

Läs samma tre svar direkt från katalogen innan du skyller på pluginen. Den första frågan visar gruppattributet som filtret beror på, och den andra visar värdet för kontokontrollen. Byt ut mot din egen bas-DN, konto och ändpunkt:

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 användare vars memberOf kommer tillbaka tomt är ett katalogfaktum, inte en pluginfel, och ett konto som fortfarande autentiseras efter att ha inaktiverats betyder att filtret saknar villkoret för kontokontroll. Rätta det beviset först och kör sedan tre-kontotestet igen. Håll loggraden som namngav det misslyckade steget bredvid konfigurationsändringen, så att nästa person kan skilja auktorisering från autentisering utan att upprepa sökningen.

Relaterade artiklar