LDAP-aŭtentikigo de OpenVPN funkcias, sed la grupa kontrolo malsukcesas: kie rigardi

Aŭtentikigo povas sukcesi dum la grupa kontrolo malakceptas ĉiujn. Trairu la blokon Authorization, la membran atributon kaj la finpunkton de la dosierujo unu post la alia.

La akreditiloj trapasas, la tunelo komencas leviĝi, kaj poste la sesio malsukcesas per mesaĝo pri la grupo anstataŭ pri la pasvorto. Tiu kombinaĵo lokas la fuŝon en la dua duono de la laboro de la LDAP-kromaĵo: la bind kaj la pasvorta kontrolo sukcesis, sed la sekva decido pri membreco ne. Ambaŭ duonoj legas el la sama agordbloko, kaj tial riparo en unu loko povas lasi la alian netuŝita. Komencu per la protokola linio, kiu nomas la paŝon, ne per la konto, kun kiu vi hazarde testas.

Traktu la malakcepton kiel respondon pri rajtigo

La kromaĵo faras servan bind, serĉas la konton, kontrolas la donitan pasvorton kaj poste demandas, ĉu tiu konto apartenas al permesita grupo. Tio estas kvar apartaj operacioj, kaj nur la lasta temas pri grupoj. Malakcepto, kiu alvenas post sukcesa bind, do diras nenion pri la pasvorto, eĉ kiam la kliento montras ĝeneralan aŭtentikigan eraron. Altigi la protokolan nivelon de la kromaĵo antaŭ ol ŝanĝi la agordon estas tio, kio apartigas la kvar en la eligo.

Serĉu la grupan pritakson mem. Kiam entute neniu grupa peto aperas, la rajtiga bloko ne estas atingata, kio kutime signifas, ke direktivo staras ekster la bloko, kiu posedas ĝin, aŭ ke mankas deviga opcio. Kiam la peto aperas kaj redonas nenion, la finpunkto aŭ la filtrilo respondas al alia demando ol tiu, kiun vi celis.

Decidu, ĉu membreco loĝas en la filtrilo aŭ en grupa bloko

Ekzistas du subtenataj formoj, kaj miksi ilin estas la maniero, kiel funkcianta agordo ĉesas funkcii. La unua puŝas membrecon en la uzantan serĉon petante atributon sur la uzanta objekto; la dua lasas la uzantan serĉon trankvila kaj igas la kromaĵon poste serĉi la grupan objekton. Elektu unu por ĉiu deplojo kaj notu, kiun vi elektis.

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

Kun tiu formo la filtrilo decidas ĉion, do RequireGroup devas esti false, alie la kromaĵo iras serĉi grupan objekton, kiun la filtrilo neniam menciis. La atributo en la filtrilo devas ekzisti sur la uzanta objekto kaj esti plenigita, kio ne estas garantiita, kiam grupoj estas nestitaj.

La alia formo tenas la serĉon simpla kaj aldonas grupan serĉon post ĝi. La grupa objekto estas nomata eksplicite, kaj la kromaĵo komparas la uzanton kun la membroj, kiujn la dosierujo redonas por ĝi. Nenio pri la uzanta filtrilo ŝanĝiĝas, kio igas ĉi tiun formon pli facile reviziebla, kiam alia teamo administras la grupon.

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

La blinda punkto estas komuna: simpla komparo de membreco ne malvolvas nestitajn grupojn, do konto, kies aliro venas tra parenta grupo, malsukcesas dum la konzolo ankoraŭ montras la membrecon. Active Directory elmetas member sur la grupo, aliaj skemoj uzas uniqueMember, kaj montri la malĝustan atributon redonas malplenan rezulton anstataŭ eraron.

Elektu finpunkton, kiu tenas la grupan objekton

La URL decidas, kiun dosierujon la kromaĵo demandas, kaj domajna regilo sur pordo 389 respondas nur por sia propra nomada kunteksto. Tutmonda katalogo sur pordo 3268 respondas por la tuta arbaro, nurlege kaj kun parte atributa aro. Kiam la kontoj sidas en unu domajno kaj la VPN-grupo en alia, unudomajna peto povas trovi la uzanton kaj tamen maltrafi la membrecon. Tio estas la kazo, en kiu movi la URL al la kataloga pordo solvas la malakcepton, kaj ĝi ankaŭ estas la kazo, en kiu homoj tro ĝeneraligas.

La parte atributa aro estas la limo: atributon, kiun la katalogo ne tenas, oni ne povas filtri, do la sama ŝanĝo povas igi unu deplojon funkcii kaj alian redoni nenion. Konfirmu, kion la finpunkto efektive redonas por la reala uzanto kaj grupo, antaŭ ol vi reverku la blokon. Plusendoj kaj TLS estas denove apartaj aferoj, ĉar plusendon oni devas sekvi, kaj finpunkto, kiu postulas TLS, bezonas la kongruajn fido-dosierojn.

Tenu la kontostaton kaj la serĉan amplekson en iliaj propraj kampoj

La malŝalta flago apartenas al la filtrilo, ne al la grupa kontrolo. En Active Directory ĝi estas la dua bito de userAccountControl, kaj sen tiu kondiĉo malŝaltita konto kun valida pasvorto aŭtentikiĝas kaj poste malsukcesas ĉe la grupa paŝo, kio aspektas kiel rajtiga fuŝo. La serĉa amplekso apartenas al la baza DN, ĉar eki ĉe la domajna radiko estas pli malrapida kaj povas trafi objektojn ekster la organiza unuo, kiun vi volis kovri.

Tenu ankaŭ la rajtojn de la binda konto mallarĝaj. Vastaj dosierujaj rajtoj transformas mise agorditan filtrilon en sukcesan peton kaj kaŝas la fuŝon, ĝis iu revizias la konton. Ŝanĝu membrecon en la dosierujo mem, neniam en loka escepta listo, tiel ke malŝalti la konton sufiĉu por forigi aliron. Se alia teamo administras la grupon, interkonsentu pri la atributo, kiun ili plenigas, antaŭ ol skribi filtrilon kontraŭ ĝi.

Pruvu la rezulton per tri kontoj

Rulu la agordon kontraŭ tri identecoj: permesita membro, valida konto ekster la grupo kaj konto, kiu estis malŝaltita. Se ĉiuj tri estas malakceptitaj, la bind aŭ la grupa peto estas rompita; se ĉiuj tri estas akceptitaj, neniu grupa kondiĉo estas aplikata entute. Miksita rezulto estas la sola eliro, kiu pruvas, ke la agordo distingas la kazojn, kiuj gravas al vi.

Legu la samajn tri respondojn rekte el la dosierujo antaŭ ol kulpigi la kromaĵon. La unua peto montras la grupan atributon, de kiu la filtrilo dependas, kaj la dua montras la kontoviglan valoron. Anstataŭigu per via propra baza DN, konto kaj finpunkto:

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

Uzanto, kies memberOf revenas malplena, estas fakto de la dosierujo, ne fuŝo de la kromaĵo, kaj konto, kiu ankoraŭ aŭtentikiĝas post malŝalto, signifas, ke la filtrilo mankas la kondiĉon de kontoviglo. Riparu unue tiun pruvon, poste rerulu la teston kun tri kontoj. Tenu la protokolan linion, kiu nomis la malsukcesan paŝon, apud la agorda ŝanĝo, por ke la sekva persono povu apartigi rajtigon de aŭtentikigo sen ripeti la serĉon.

Rilataj artikoloj