Gumagana ang LDAP authentication ng OpenVPN pero nabibigo ang group check: saan titingin

Pumapasa ang mga kredensyal, nagsisimulang umangat ang tunnel, at pagkatapos ay nabigo ang sesyon sa isang mensaheng tungkol sa grupo at hindi sa password. Inilalagay ng kombinasyong iyon ang fault sa ikalawang kalahati ng trabaho ng LDAP plugin: nagtagumpay ang bind at ang pagsusuri ng password, at ang desisyon sa membership na sumusunod ay hindi. Pareho silang nagbabasa mula sa iisang configuration block, kaya ang isang pagwawasto sa isang lugar ay maaaring iwang hindi nagalaw ang isa. Magsimula sa log line na nagngangalan sa hakbang, hindi sa account na nagkataong sinusubukan mo.

Ituring ang pagtanggi bilang sagot ng awtorisasyon

Nagsasagawa ang plugin ng service bind, hinahanap ang account, bineberipika ang ibinigay na password, at pagkatapos ay nagtatanong kung kabilang ang account na iyon sa pinapayagang grupo. Apat na magkakaibang operasyon iyon, at ang huli lamang ang tungkol sa mga grupo. Kaya ang pagtanggi na dumarating pagkatapos ng matagumpay na bind ay walang sinasabi tungkol sa password, kahit nagpapakita ang client ng pangkalahatang error sa authentication. Ang pagtaas ng log level ng plugin bago baguhin ang configuration ang naghihiwalay sa apat sa output.

Hanapin ang mismong pagsusuri ng grupo. Kapag wala talagang lumilitaw na query ng grupo, hindi naaabot ang authorization block, na karaniwang nangangahulugang ang isang direktiba ay nasa labas ng block na nagmamay-ari nito o may kulang na kinakailangang opsyon. Kapag lumitaw ang query at walang ibinabalik, ang endpoint o ang filter ay sumasagot sa ibang tanong kaysa sa nilalayon mo.

Magpasya kung ang membership ay nasa filter o sa isang block ng grupo

May dalawang sinusuportahang anyo, at ang paghahalo sa kanila ang paraan para tumigil sa paggana ang isang gumaganang configuration. Itinutulak ng una ang membership sa paghahanap ng user sa pamamagitan ng paghingi ng attribute sa user object; hinahayaan ng pangalawa ang paghahanap ng user at pinapahanap sa plugin ang group object pagkatapos. Pumili ng isa kada deployment at isulat kung alin ang pinili mo.

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

Sa anyong iyon, ang filter ang nagpapasya sa lahat, kaya dapat false ang RequireGroup, kung hindi ay hahanapin ng plugin ang isang group object na hindi kailanman binanggit ng filter. Dapat umiral ang attribute sa filter sa user object at dapat puno ito, na hindi ginagarantiyahan kapag naka-nest ang mga grupo.

Ang isa pang anyo ay nagpapanatiling simple ng paghahanap at nagdaragdag ng paghahanap ng grupo pagkatapos. Tahasang pinangalanan ang group object, at inihahambing ng plugin ang user sa mga miyembrong ibinabalik ng direktoryo para dito. Walang nagbabago sa filter ng user, na ginagawang mas madaling i-audit ang anyong ito kapag ibang team ang namamahala sa grupo.

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

Ang blind spot ay kapareho: hindi pinalalawak ng simpleng paghahambing ng membership ang mga naka-nest na grupo, kaya nabibigo ang account na ang access ay dumarating sa pamamagitan ng parent group habang ipinapakita pa rin ng console ang membership. Inilalantad ng Active Directory ang member sa grupo, gumagamit ang ibang schema ng uniqueMember, at ang pagturo sa maling attribute ay nagbabalik ng walang laman na resulta sa halip na error.

Pumili ng endpoint na naglalaman ng group object

Ang URL ang nagpapasya kung aling direktoryo ang tinatanong ng plugin, at ang domain controller sa port 389 ay sumasagot lamang para sa sarili nitong naming context. Ang global catalog sa port 3268 ay sumasagot para sa buong forest, read-only at may partial na set ng attribute. Kapag ang mga account ay nasa isang domain at ang VPN group ay nasa iba, ang query sa isang domain ay maaaring mahanap ang user at maaaring makaligtaan pa rin ang membership. Ito ang kaso kung saan ang paglipat ng URL sa catalog port ay lumulutas sa pagtanggi, at ito rin ang kaso kung saan labis na nag-generalize ang mga tao.

Ang partial na set ng attribute ang hangganan: ang attribute na hindi hawak ng catalog ay hindi maaaring i-filter, kaya ang parehong pagbabago ay maaaring magpagana sa isang deployment at magpabalik ng walang laman sa isa pa. Kumpirmahin kung ano talaga ang ibinabalik ng endpoint para sa tunay na user at grupo bago muling isulat ang block. Ang mga referral at TLS ay hiwalay na usapin muli, dahil kailangang sundan ang referral at ang endpoint na nangangailangan ng TLS ay kailangan ng tugmang trust file.

Panatilihin ang estado ng account at saklaw ng paghahanap sa sarili nilang field

Ang disabled flag ay kabilang sa filter, hindi sa group check. Sa Active Directory ito ang ikalawang bit ng userAccountControl, at kung wala ang kundisyong iyon, ang disabled na account na may valid na password ay nagpapatotoo at pagkatapos ay nabibigo sa hakbang ng grupo, na parang bug sa awtorisasyon. Ang saklaw ng paghahanap ay kabilang sa base DN, dahil mas mabagal ang pagsisimula sa root ng domain at maaaring tumugma sa mga object sa labas ng organizational unit na nais mong masaklaw.

Panatilihing makitid din ang mga karapatan ng bind account. Ang malawak na karapatan sa direktoryo ay nagiging matagumpay na query ang isang maling naka-configure na filter at itinatago ang bug hanggang may mag-audit sa account. Baguhin ang membership sa direktoryo mismo, hindi kailanman sa lokal na listahan ng exception, upang sapat na ang pag-disable ng account para alisin ang access. Kung ibang team ang namamahala sa grupo, magkasundo sa attribute na pinupuno nila bago magsulat ng filter laban dito.

Patunayan ang resulta gamit ang tatlong account

Patakbuhin ang configuration laban sa tatlong pagkakakilanlan: isang pinapayagang miyembro, isang valid na account sa labas ng grupo at isang account na na-disable. Kung tatlo ang tinanggihan, sira ang bind o ang query ng grupo; kung tatlo ang tinanggap, wala talagang kundisyon ng grupo na inilalapat. Ang pinaghalong resulta ang tanging nagpapatunay na nakikilala ng configuration ang mga kaso na mahalaga sa iyo.

Basahin ang parehong tatlong sagot nang direkta mula sa direktoryo bago sisihin ang plugin. Ipinapakita ng unang query ang attribute ng grupo na pinagkakatiwalaan ng filter, at ipinapakita ng pangalawa ang halaga ng kontrol ng account. Palitan ng sarili mong base DN, account at endpoint:

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

Ang user na ang memberOf ay bumabalik na walang laman ay katotohanan ng direktoryo, hindi bug ng plugin, at ang account na nagpapatotoo pa rin pagkatapos ma-disable ay nangangahulugang kulang ang filter sa kundisyon ng kontrol ng account. Ayusin muna ang ebidensiyang iyon, pagkatapos ay patakbuhin muli ang tatlong-account na pagsubok. Itago ang log line na nagngangalan sa nabigong hakbang sa tabi ng pagbabago sa configuration, upang maihiwalay ng susunod na tao ang awtorisasyon sa authentication nang hindi inuulit ang paghahanap.