Vërtetimi LDAP i OpenVPN funksionon, por kontrolli i grupit dështon: ku duhet shikuar

Kredencialet kalojnë, tuneli fillon të ngrihet dhe më pas sesioni dështon me një mesazh për grupin dhe jo për fjalëkalimin. Ky kombinim e vendos defektin në gjysmën e dytë të punës së shtojcës LDAP: lidhja dhe kontrolli i fjalëkalimit patën sukses, ndërsa vendimi për anëtarësinë që vjen më pas jo. Të dyja gjysmat lexojnë nga i njëjti bllok konfigurimi, prandaj një rregullim në një vend mund ta lërë tjetrin të paprekur. Filloni nga rreshti i regjistrit që emërton hapin, jo nga llogaria me të cilën po testoni rastësisht.

Trajtojeni refuzimin si një përgjigje autorizimi

Shtojca kryen një lidhje shërbimi, kërkon llogarinë, verifikon fjalëkalimin e dhënë dhe më pas pyet nëse ajo llogari i përket një grupi të lejuar. Këto janë katër veprime të ndryshme, dhe vetëm i fundit ka të bëjë me grupet. Prandaj një refuzim që vjen pas një lidhjeje të suksesshme nuk thotë asgjë për fjalëkalimin, edhe kur klienti shfaq një gabim të përgjithshëm vërtetimi. Ngritja e nivelit të regjistrit të shtojcës përpara se të ndryshoni konfigurimin është ajo që i ndan të katërt në dalje.

Kërkoni vetë vlerësimin e grupit. Kur nuk shfaqet fare një kërkesë për grup, blloku i autorizimit nuk arrihet, që zakonisht do të thotë se një direktivë qëndron jashtë bllokut që e zotëron ose mungon një opsion i detyrueshëm. Kur kërkesa shfaqet dhe nuk kthen asgjë, pika fundore ose filtri përgjigjet një pyetjeje tjetër nga ajo që kishit parasysh.

Vendosni nëse anëtarësia jeton në filtër apo në një bllok grupi

Ka dy forma të mbështetura, dhe përzierja e tyre është mënyra se si një konfigurim funksional ndalon së funksionuari. E para e shtyn anëtarësinë në kërkimin e përdoruesve duke kërkuar një atribut në objektin e përdoruesit; e dyta e lë kërkimin e përdoruesve në paqe dhe lë shtojcën të kërkojë objektin e grupit më pas. Zgjidhni një për çdo vendosje dhe shkruani cilën zgjodhët.

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

Me atë formë filtri vendos gjithçka, prandaj RequireGroup duhet të jetë false, përndryshe shtojca shkon të kërkojë një objekt grupi që filtri nuk e përmendi kurrë. Atributi në filtër duhet të ekzistojë në objektin e përdoruesit dhe të jetë i plotësuar, gjë që nuk garantohet kur grupet janë të ndërlidhura.

Forma tjetër e mban kërkimin të thjeshtë dhe shton një kërkim grupi pas tij. Objekti i grupit emërtohet në mënyrë eksplicite, dhe shtojca e krahason përdoruesin me anëtarët që drejtoria kthen për të. Asgjë në filtrin e përdoruesit nuk ndryshon, gjë që e bën këtë formë më të lehtë për t'u audituar kur grupin e administron një ekip tjetër.

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

Pika e verbër është e përbashkët: një krahasim i thjeshtë anëtarësie nuk i shpalos grupet e ndërlidhura, prandaj një llogari që e merr aksesin përmes një grupi prind dështon ndërsa konsola vazhdon të tregojë anëtarësinë. Active Directory ekspozon member në grup, skemat e tjera përdorin uniqueMember, dhe të tregosh atributin e gabuar kthen një rezultat bosh në vend të një gabimi.

Zgjidhni një pikë fundore që përmban objektin e grupit

URL-ja vendos se cilën drejtori pyet shtojca, dhe një kontrollues domeni në portën 389 përgjigjet vetëm për kontekstin e vet të emrave. Një katalog global në portën 3268 përgjigjet për të gjithë pyllin, vetëm-lexim dhe me një grup të pjesshëm atributësh. Kur llogaritë janë në një domen dhe grupi VPN në një tjetër, një kërkesë një-domenëshe mund ta gjejë përdoruesin dhe gjithsesi ta humbasë anëtarësinë. Ky është rasti kur zhvendosja e URL-së në portën e katalogut e zgjidh refuzimin, dhe është gjithashtu rasti kur njerëzit përgjithësojnë tepër.

Grupi i pjesshëm i atributeve është kufiri: mbi një atribut që katalogu nuk e mban nuk mund të filtrohet, prandaj i njëjti ndryshim mund ta bëjë një vendosje të funksionojë dhe një tjetër të kthejë bosh. Konfirmoni çfarë kthen në të vërtetë pika fundore për përdoruesin dhe grupin realë përpara se ta rishkruani bllokun. Ridrejtimet dhe TLS janë përsëri çështje të veçanta, pasi një ridrejtim duhet ndjekur dhe një pikë fundore që kërkon TLS ka nevojë për skedarët përkatës të besimit.

Mbajini gjendjen e llogarisë dhe shtrirjen e kërkimit në fushat e tyre

Flamuri i çaktivizimit i përket filtrit, jo kontrollit të grupit. Në Active Directory është biti i dytë i userAccountControl, dhe pa atë kusht një llogari e çaktivizuar me fjalëkalim të vlefshëm vërtetohet dhe më pas dështon në hapin e grupit, gjë që duket si një defekt autorizimi. Shtrirja e kërkimit i përket DN-së bazë, sepse fillimi nga rrënja e domenit është më i ngadalshëm dhe mund të përputhet me objekte jashtë njësisë organizative që dëshironit të mbulonit.

Mbajini të ngushta edhe të drejtat e llogarisë së lidhjes. Të drejtat e gjera të drejtorisë e kthejnë një filtër të konfiguruar gabimisht në një kërkesë të suksesshme dhe e fshehin defektin derisa dikush ta auditojë llogarinë. Ndryshoni anëtarësinë në vetë drejtorinë, kurrë në një listë lokale përjashtimesh, në mënyrë që çaktivizimi i llogarisë të mjaftojë për të hequr aksesin. Nëse grupin e administron një ekip tjetër, bihuni dakord për atributin që plotësojnë ata përpara se të shkruani një filtër mbi të.

Vërtetoni rezultatin me tre llogari

Ekzekutoni konfigurimin kundrejt tre identiteteve: një anëtar i lejuar, një llogari e vlefshme jashtë grupit dhe një llogari që është çaktivizuar. Nëse të treja refuzohen, lidhja ose kërkesa e grupit është e prishur; nëse të treja pranohen, nuk zbatohet fare ndonjë kusht grupi. Një rezultat i përzier është i vetmi që provon se konfigurimi i dallon rastet që ju interesojnë.

Lexoni të njëjtat tre përgjigje drejtpërdrejt nga drejtoria përpara se ta fajësoni shtojcën. Kërkesa e parë tregon atributin e grupit nga i cili varet filtri, dhe e dyta tregon vlerën e kontrollit të llogarisë. Zëvendësoni me DN-në tuaj bazë, llogarinë dhe pikën fundore:

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

Një përdorues, memberOf i të cilit kthehet bosh, është fakt i drejtorisë, jo defekt i shtojcës, dhe një llogari që vërtetohet edhe pas çaktivizimit do të thotë që filtrit i mungon kushti i kontrollit të llogarisë. Rregulloni së pari atë provë, pastaj riekzekutoni testin me tre llogari. Mbajeni rreshtin e regjistrit që emërtoi hapin e dështuar pranë ndryshimit të konfigurimit, që personi tjetër të mund të ndajë autorizimin nga vërtetimi pa përsëritur kërkimin.