OpenVPN LDAP-autentikaasje wurket, mar de groepskontrôle misleit: wêr’t jo sykje moatte

Autentikaasje kin slagje wylst de groepskontrôle elkenien ôfwiist. Gean it Authorization-blok, it lidmaatskip-attribute en it einpunt fan it argyf efterinoar nei.

De oanmeldgegevens passearje, de tunnel begjint omheech te kommen, en dan misleit de sesje mei in berjocht oer de groep yn stee fan oer it wachtwurd. Dy kombinaasje pleatst de flater yn de twadde helte fan it wurk fan de LDAP-útwreiding: de bind en de wachtwurdkontrôle slaggen, en it lidmaatskipbeslút dat dêrop folget net. Beide helten lêze út itselde konfiguraasjeblok, en dêrom kin in repitaasje op ien plak it oare ûnoantaast litte. Begjin by de logrigel dy’t de stap neamt, net by it akkount dêr’t jo tafallich mei testje.

Behannelje de ôfwizing as in autorisaasje-antwurd

De útwreiding docht in tsjinstbind, siket it akkount, ferifiearret it oanleverje wachtwurd en freget dan oft dat akkount ta in tastiene groep heart. Dat binne fjouwer aparte bewurkings, en allinne de lêste giet oer groepen. In ôfwizing dy’t nei in slagge bind komt, seit dêrom neat oer it wachtwurd, sels as de klant in algemiene autentikaasjeflater toant. It lognivo fan de útwreiding ferheegje foardat jo de konfiguraasje feroarje is wat de fjouwer yn de útfier skiedt.

Sykje de groepsbeoardieling sels. As der hielendal gjin groepsquery ferskynt, wurdt it autorisaasjeblok net berikt, wat meastentiids betsjut dat in rjochtline bûten it blok stiet dat der eigner fan is of dat in ferplichte opsje ûntbrekt. As de query ferskynt en neat weromjout, beäntwurdet it einpunt of it filter in oare fraach as dy’t jo bedoelden.

Bepale oft lidmaatskip yn it filter of yn in groepsblok wennet

Der binne twa stipe foarmen, en se minge is de manier wêrop in wurkjende konfiguraasje ophâldt te wurkjen. De earste skoot lidmaatskip yn it brûkersykjen troch in attribute op it brûkersobjekt te freegjen; de twadde lit it brûkersykjen gewurde en lit de útwreiding dêrnei it groepsopsjekt sykje. Kies ien per útrôl en skriuw op hokker ien jo keazen hawwe.

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

Mei dy foarm beslút it filter alles, dus RequireGroup moat false wêze, oars giet de útwreiding op syk nei in groepsopsjekt dat it filter nea neamde. It attribute yn it filter moat op it brûkersobjekt bestean en ynfold wêze, wat net garandearre is sadree’t groepen nêstele binne.

De oare foarm hâldt it sykjen simpel en foeget dêrnei in groepssykjen ta. It groepsopsjekt wurdt eksplisyt neamd, en de útwreiding fergeliket de brûker mei de leden dy’t it argyf derfoar weromjout. Neat oan it brûkersfilter feroaret, wat dizze foarm makliker te auditen makket as in oar team de groep beheart.

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

It blynde plak is dield: in gewoane lidmaatskipfergeliking wreidet nêstele groepen net út, dus in akkount waans tagong fia in âlder groep komt misleit, wylst de konsole it lidmaatskip noch altyd toant. Active Directory lit member op de groep sjen, oare skema’s brûke uniqueMember, en nei it ferkearde attribute wize jout in leech resultaat yn stee fan in flater.

Kies in einpunt dat it groepsopsjekt befettet

De URL beslút hokker argyf de útwreiding freget, en in domeinkontrôler op poarte 389 antwurdet allinne foar syn eigen nammekontekst. In globale katalogus op poarte 3268 antwurdet foar it hiele bosk, allinnich-lêze en mei in partiel attribútset. As de akkounts yn ien domein sitte en de VPN-groep yn in oar, kin in query op ien domein de brûker fine en dochs it lidmaatskip misse. Dat is it gefal wêryn’t it ferpleatsen fan de URL nei de kataloguspoarte de ôfwizing oplost, en it is ek it gefal wêryn’t minsken te fier generalisearje.

It partiele attribútset is de grins: op in attribute dat de katalogus net hat, kin net filtrearre wurde, dus deselde feroaring kin ien útrôl wurkje litte en in oare neat weromjaan. Befêstigje wat it einpunt foar de echte brûker en groep wier weromjout foardat jo it blok oerskriuwe. Ferwizings en TLS binne wer aparte saken, om’t in ferwizing folge wurde moat en in einpunt dat TLS easket de byhearrende fertrouwensbestannen nedich hat.

Hâld akkountsteat en sykberik yn har eigen fjilden

De útskeakelflagge heart yn it filter, net yn de groepskontrôle. Yn Active Directory is it it twadde bit fan userAccountControl, en sûnder dy betingst autentisearret in útskeakele akkount mei in jildich wachtwurd him en misleit dan by de groepstap, wat op in autorisaasjeflater liket. Sykberik heart yn it basis-DN, om’t fan de domeinwoartel ôf begjinne stadiger is en objekten bûten de organisaasje-ienheid reitsje kin dy’t jo dekke woene.

Hâld de rjochten fan it bind-akkount ek nau. Brede argyfrjochten meitsje fan in ferkeard konfigurearre filter in slagge query en ferbergje de flater oant immen it akkount auditearret. Feroarje lidmaatskip yn it argyf sels, nea yn in pleatslike útsûnderingslist, sadat it útskeakeljen fan it akkount genôch is om tagong te ferwiderjen. As in oar team de groep beheart, kom dan oerien oer it attribute dat sy ynfolje foardat jo dêr in filter op skriuwe.

Bewiis it resultaat mei trije akkounts

Rin de konfiguraasje tsjin trije identiteiten: in tastien lid, in jildich akkount bûten de groep en in akkount dat útskeakele is. As alle trije ôfwiisd wurde, is de bind of de groepsquery stikken; as alle trije akseptearre wurde, wurdt hielendal gjin groepbetingst tapast. In mongen resultaat is de iennige útkomst dy’t bewiist dat de konfiguraasje de gefallen dy’t jo wichtich fine ûnderskiedt.

Lês deselde trije antwurden streekrjocht út it argyf foardat jo de útwreiding de skuld jouwe. De earste query toant it groepattribute dêr’t it filter fan ôfhinklik is, en de twadde toant de akkountkontrôlewearde. Ferfange troch jo eigen basis-DN, akkount en einpunt:

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

In brûker waans memberOf leech weromkomt is in argyffeit, gjin flater fan de útwreiding, en in akkount dat nei útskeakeljen noch autentisearret betsjut dat it filter de akkountkontrôlebetingst mist. Reparearje earst dat bewiis, rin dan de trije-akkounttest opnij. Hâld de logrigel dy’t de mislearre stap neamde njonken de konfiguraasjeferoaring, sadat de folgjende persoan autorisaasje fan autentikaasje skiede kin sûnder it sykjen te werheljen.

Relatearre artikelen