Uthibitishaji wa LDAP wa OpenVPN hufanya kazi lakini ukaguzi wa kikundi unashindikana: wapi pa kuangalia

Uthibitishaji unaweza kupita wakati ukaguzi wa kikundi unakataa kila mtu. Pitia bloku ya Authorization, sifa ya uanachama na sehemu ya mwisho ya saraka moja baada ya nyingine.

Vitambulisho hupita, handaki huanza kupanda, kisha kipindi hushindikana kwa ujumbe kuhusu kikundi badala ya kuhusu nenosiri. Mchanganyiko huo huweka hitilafu katika nusu ya pili ya kazi ya programu-jalizi ya LDAP: uunganishaji na ukaguzi wa nenosiri ulifanikiwa, na uamuzi wa uanachama unaofuata haukufanikiwa. Nusu zote mbili zinasoma kutoka bloku moja ya usanidi, ndiyo sababu marekebisho mahali pamoja yanaweza kuiacha nyingine bila kuguswa. Anza na mstari wa kumbukumbu unaotaja hatua, si kwa akaunti unayoijaribu kwa bahati.

Chukulia kukataliwa kama jibu la uidhinishaji

Programu-jalizi hufanya uunganishaji wa huduma, hutafuta akaunti, huthibitisha nenosiri lililotolewa na kisha huuliza kama akaunti hiyo ni ya kikundi kilichoruhusiwa. Hizo ni operesheni nne tofauti, na ya mwisho pekee inahusu vikundi. Kwa hivyo kukataliwa kunakofika baada ya uunganishaji uliofanikiwa hakuambii chochote kuhusu nenosiri, hata wakati mteja anaonyesha hitilafu ya jumla ya uthibitishaji. Kupandisha kiwango cha kumbukumbu cha programu-jalizi kabla ya kubadilisha usanidi ndiko kunakotenganisha hizo nne katika matokeo.

Tafuta tathmini ya kikundi yenyewe. Wakati hakuna swali la kikundi linavyoonekana kabisa, bloku ya uidhinishaji haifikiki, ambayo kwa kawaida ina maana kwamba maagizo yamo nje ya bloku inayomiliki au chaguo la lazima halipo. Wakati swali linavyoonekana na hakuna kinachorudishwa, sehemu ya mwisho au kichujio kinajibu swali tofauti na lile ulilokusudia.

Amua kama uanachama unaishi katika kichujio au katika bloku ya kikundi

Kuna aina mbili zinazotumika, na kuzichanganya ndiyo njia ambayo usanidi unaofanya kazi huacha kufanya kazi. Ya kwanza inasukuma uanachama kwenye utafutaji wa mtumiaji kwa kuomba sifa kwenye kitu cha mtumiaji; ya pili inaacha utafutaji wa mtumiaji na kumruhusu programu-jalizi kutafuta kitu cha kikundi baadaye. Chagua moja kwa kila usambazaji na andika ni ipi uliyochagua.

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

Kwa aina hiyo kichujio huamua kila kitu, kwa hivyo RequireGroup lazima iwe false, vinginevyo programu-jalizi itakwenda kutafuta kitu cha kikundi ambacho kichujio hakikutaja kamwe. Sifa iliyo kwenye kichujio lazima iwepo kwenye kitu cha mtumiaji na ijazwe, jambo ambalo hakuna uhakika nalo vikundi vikiwa vimepachikwa.

Aina nyingine inaweka utafutaji rahisi na kuongeza utafutaji wa kikundi baada yake. Kitu cha kikundi kinatajwa kwa uwazi, na programu-jalizi inalinganisha mtumiaji na wanachama ambao saraka inarudisha kwa ajili yake. Hakuna kinachobadilika kwenye kichujio cha mtumiaji, jambo linalofanya aina hii iwe rahisi kukaguliwa wakati timu nyingine inasimamia kikundi.

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

Sehemu isiyoonekana ni ya pamoja: ulinganishaji rahisi wa uanachama haupanui vikundi vilivyopachikwa, kwa hivyo akaunti ambayo ufikiaji wake unakuja kupitia kikundi mzazi hushindikana wakati konsoli bado inaonyesha uanachama. Active Directory hufichua member kwenye kikundi, skima nyingine hutumia uniqueMember, na kuelekeza kwenye sifa isiyo sahihi hurudisha matokeo tupu badala ya hitilafu.

Chagua sehemu ya mwisho ambayo ina kitu cha kikundi

URL huamua ni saraka ipi programu-jalizi inauliza, na kidhibiti cha kikoa kwenye lango 389 hujibu kwa muktadha wake wa majina pekee. Katalogi ya kimataifa kwenye lango 3268 hujibu kwa msitu wote, kusoma tu na kwa seti ya sifa isiyokamilika. Wakati akaunti ziko katika kikoa kimoja na kikundi cha VPN kiko kingine, swali la kikoa kimoja linaweza kumpata mtumiaji na bado likakosa uanachama. Hiyo ndiyo hali ambayo kuhamisha URL hadi lango la katalogi hutatua kukataliwa, na hiyo pia ni hali ambayo watu hujumlisha kupita kiasi.

Seti isiyokamilika ya sifa ndiyo kikomo: sifa ambayo katalogi haihifadhi haiwezi kuchujwa, kwa hivyo mabadiliko hayo hayo yanaweza kufanya usambazaji mmoja ufanye kazi na mwingine urudishe tupu. Thibitisha kile sehemu ya mwisho hurudisha kwa mtumiaji na kikundi halisi kabla ya kuandika upya bloku. Marejeo na TLS ni masuala tofauti tena, kwa kuwa rejea lazima ifuatwe na sehemu ya mwisho inayohitaji TLS inahitaji faili za uaminifu zinazolingana.

Weka hali ya akaunti na wigo wa utafutaji katika sehemu zao wenyewe

Bendera ya kuzima ni ya kichujio, si ya ukaguzi wa kikundi. Katika Active Directory ni biti ya pili ya userAccountControl, na bila sharti hilo akaunti iliyozimwa yenye nenosiri halali huthibitika kisha hushindikana katika hatua ya kikundi, jambo linaloonekana kama hitilafu ya uidhinishaji. Wigo wa utafutaji ni wa DN msingi, kwa sababu kuanza kutoka mzizi wa kikoa ni polepole zaidi na kunaweza kulingana na vitu vilivyo nje ya kitengo cha shirika ulichokusudia kufunika.

Weka pia haki za akaunti ya uunganishaji ziwe nyembamba. Haki pana za saraka hufanya kichujio kilichosanidiwa vibaya kuwa swali lililofanikiwa na huficha hitilafu hadi mtu mmoja akague akaunti. Badilisha uanachama katika saraka yenyewe, kamwe si katika orodha ya kipekee ya ndani, ili kuzima akaunti kutoshe kwa kuondoa ufikiaji. Ikiwa timu nyingine inasimamia kikundi, kubalianeni kuhusu sifa wanayoijaza kabla ya kuandika kichujio juu yake.

Thibitisha matokeo kwa akaunti tatu

Endesha usanidi dhidi ya utambulisho tatu: mwanachama aliyeruhusiwa, akaunti halali nje ya kikundi na akaunti iliyozimwa. Ikiwa zote tatu zinakataliwa, uunganishaji au swali la kikundi limevunjika; ikiwa zote tatu zinakubaliwa, hakuna sharti la kikundi linalotumika kabisa. Matokeo mchanganyiko ndiyo matokeo pekee yanayothibitisha kuwa usanidi unatofautisha hali zinazokujia muhimu.

Soma majibu hayo matatu moja kwa moja kutoka saraka kabla ya kulaumu programu-jalizi. Swali la kwanza linaonyesha sifa ya kikundi ambayo kichujio kinategemea, na la pili linaonyesha thamani ya udhibiti wa akaunti. Badilisha na DN msingi wako, akaunti na sehemu ya mwisho:

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

Mtumiaji ambaye memberOf yake inarudi tupu ni ukweli wa saraka, si hitilafu ya programu-jalizi, na akaunti inayoendelea kuthibitika baada ya kuzimwa ina maana kwamba kichujio kinakosa sharti la udhibiti wa akaunti. Rekebisha ushahidi huo kwanza, kisha endesha tena jaribio la akaunti tatu. Weka mstari wa kumbukumbu uliotaja hatua iliyoshindikana kando ya mabadiliko ya usanidi, ili mtu anayefuata aweze kutenganisha uidhinishaji na uthibitishaji bila kurudia utafutaji.

Makala zinazohusiana