OpenVPN LDAP-verifikasie werk, maar die groepkontrole misluk: waar om te kyk

Die aanmeldingsgegewens slaag, die tonnel begin opkom, en dan misluk die sessie met ’n boodskap oor die groep eerder as oor die wagwoord. Daardie kombinasie plaas die fout in die tweede helfte van die LDAP-inprop se werk: die bind en die wagwoordkontrole het geslaag, en die lidmaatskapbesluit wat daarop volg het nie. Albei helftes lees uit dieselfde konfigurasieblok, en daarom kan ’n regstelling op een plek die ander onaangeraak laat. Begin by die logreël wat die stap noem, nie by die rekening waarmee jy toevallig toets nie.

Behandel die verwerping as ’n magtigingsantwoord

Die inprop voer ’n diensbind uit, soek die rekening, verifieer die verskafde wagwoord en vra dan of daardie rekening aan ’n toegelate groep behoort. Dit is vier afsonderlike bewerkings, en net die laaste een gaan oor groepe. ’n Verwerping wat ná ’n suksesvolle bind opduik, sê dus niks oor die wagwoord nie, selfs wanneer die kliënt ’n generiese verifikasiefout wys. Om die inprop se logvlak te verhoog voordat jy die konfigurasie verander, is wat die vier in die uitset van mekaar skei.

Kyk na die groepbeoordeling self. Wanneer daar glad geen groepnavraag verskyn nie, word die magtigingsblok nie bereik nie, wat gewoonlik beteken dat ’n opdrag buite die blok staan wat dit besit, of dat ’n vereiste opsie ontbreek. Wanneer die navraag wel verskyn en niks teruggee nie, beantwoord die eindpunt of die filter ’n ander vraag as die een wat jy bedoel het.

Bepaal of lidmaatskap in die filter of in ’n groepblok woon

Daar is twee ondersteunde vorme, en om hulle te meng is hoe ’n werkende konfigurasie ophou werk. Die eerste skuif lidmaatskap in die gebruiker se soektog in deur na ’n kenmerk op die gebruikerobjek te vra; die tweede laat die gebruiker se soektog alleen en laat die inprop daarna die groepobjek opsoek. Kies een per ontplooiing en skryf neer watter een jy gekies het.

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

Met daardie vorm besluit die filter alles, so RequireGroup moet false wees, anders gaan soek die inprop na ’n groepobjek wat die filter nooit genoem het nie. Die kenmerk in die filter moet op die gebruikerobjek bestaan en gevul wees, wat nie gewaarborg is sodra groepe genest is nie.

Die ander vorm hou die soektog eenvoudig en voeg ’n groepsoektog daarna by. Die groepobjek word eksplisiet genoem, en die inprop vergelyk die gebruiker met die lede wat die gids daarvoor teruggee. Niks aan die gebruiker se filter verander nie, wat hierdie vorm makliker maak om te oudit wanneer ’n ander span die groep bestuur.

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

Die blinde kol is deel: ’n gewone lidmaatskapvergelyking brei geneste groepe nie uit nie, so ’n rekening wie se toegang deur ’n ouergroep kom, misluk terwyl die konsole steeds die lidmaatskap wys. Active Directory stel member op die groep bloot, ander skemas gebruik uniqueMember, en om na die verkeerde kenmerk te wys gee ’n leë resultaat in plaas van ’n fout.

Kies ’n eindpunt wat die groepobjek hou

Die URL bepaal watter gids die inprop vra, en ’n domeinbeheerder op poort 389 antwoord net vir sy eie naamkonteks. ’n Globale katalogus op poort 3268 antwoord vir die hele woud, net-lees en met ’n gedeeltelike kenmerksversameling. Wanneer die rekeninge in een domein sit en die VPN-groep in ’n ander, kan ’n navraag na een domein die gebruiker vind en steeds die lidmaatskap mis. Dit is die geval waar om die URL na die kataloguspoort te skuif die verwerping oplos, en dit is ook die geval waar mense te ver veralgemeen.

Die gedeeltelike kenmerksversameling is die beperking: op ’n kenmerk wat die katalogus nie hou nie, kan nie gefiltreer word nie, so dieselfde verandering kan een ontplooiing laat werk en ’n ander niks teruggee nie. Bevestig wat die eindpunt werklik vir die regte gebruiker en groep teruggee voordat jy die blok herskryf. Verwysings en TLS is weer aparte sake, want ’n verwysing moet gevolg word en ’n eindpunt wat TLS vereis, het die ooreenstemmende trust-lêers nodig.

Hou rekeningtoestand en soekbereik in hul eie velde

Die gedeaktiveerde vlag hoort in die filter, nie in die groepkontrole nie. In Active Directory is dit die tweede bis van userAccountControl, en sonder daardie voorwaarde verifieer ’n gedeaktiveerde rekening met ’n geldige wagwoord en misluk dan by die groepstap, wat soos ’n magtigingsfout lyk. Soekbereik hoort in die basis-DN, want om by die domeinwortel te begin is stadiger en kan objekte pas buite die organisasie-eenheid wat jy bedoel het.

Hou ook die bind-rekening se regte eng. Breë gidsregte maak ’n verkeerd gekonfigureerde filter ’n suksesvolle navraag en versteek die fout tot iemand die rekening oudit. Verander lidmaatskap in die gids self, nooit in ’n plaaslike uitsonderingslys nie, sodat dit genoeg is om die rekening te deaktiveer om toegang te verwyder. As ’n ander span die groep bestuur, kom ooreen oor die kenmerk wat hulle vul voordat jy ’n filter daarop skryf.

Bewys die resultaat met drie rekeninge

Toets die konfigurasie teen drie identiteite: ’n toegelate lid, ’n geldige rekening buite die groep en ’n rekening wat gedeaktiveer is. As al drie verwerp word, is die bind of die groepnavraag stukkend; as al drie aanvaar word, word glad geen groepvoorwaarde toegepas nie. ’n Gemengde resultaat is die enigste uitkoms wat bewys die konfigurasie onderskei die gevalle wat vir jou saak maak.

Lees dieselfde drie antwoorde direk uit die gids voordat jy die inprop blameer. Die eerste navraag wys die groepkenmerk waarvan die filter afhang, en die tweede wys die rekeningbeheer-waarde. Vervang dit met jou eie basis-DN, rekening en eindpunt:

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

’n Gebruiker wie se memberOf leeg terugkom, is ’n gidsfeit, nie ’n inpropfout nie, en ’n rekening wat ná deaktivering steeds verifieer, beteken die filter kort die rekeningbeheer-voorwaarde. Maak eers daardie bewys reg, en herhaal dan die toets met drie rekeninge. Hou die logreël wat die mislukte stap genoem het langs die konfigurasieverandering, sodat die volgende persoon magtiging van verifikasie kan skei sonder om die soektog te herhaal.