Akreditācijas dati iziet, tunelis sāk celties, un tad sesija neizdodas ar ziņojumu par grupu, nevis par paroli. Šī kombinācija novieto kļūdu LDAP spraudņa darba otrajā pusē: piesaiste un paroles pārbaude izdevās, bet tai sekojošais dalības lēmums ne. Abas puses lasa no viena konfigurācijas bloka, tāpēc labojums vienā vietā var atstāt otru neaizskartu. Sāciet ar žurnāla rindu, kas nosauc soli, nevis ar kontu, ar kuru nejauši testējat.

Uztveriet noraidījumu kā autorizācijas atbildi

Spraudnis veic pakalpojuma piesaisti, meklē kontu, pārbauda doto paroli un pēc tam jautā, vai šis konts pieder atļautai grupai. Tie ir četri atsevišķi darbības veidi, un tikai pēdējais ir par grupām. Tāpēc noraidījums, kas nāk pēc veiksmīgas piesaistes, neko neizsaka par paroli, pat ja klients rāda vispārīgu autentifikācijas kļūdu. Spraudņa žurnāla līmeņa paaugstināšana pirms konfigurācijas maiņas ir tas, kas izvadē atdala šos četrus.

Meklējiet pašu grupas novērtējumu. Ja grupas vaicājums neparādās nemaz, autorizācijas bloks netiek sasniegts, kas parasti nozīmē, ka direktīva atrodas ārpus bloka, kuram tā pieder, vai trūkst obligātā parametra. Ja vaicājums parādās un neko neatgriež, galapunkts vai filtrs atbild uz citu jautājumu nekā tas, ko jūs domājāt.

Izlemiet, vai dalība dzīvo filtrā vai grupas blokā

Ir divas atbalstītas formas, un to sajaukšana ir veids, kā strādājoša konfigurācija pārstāj strādāt. Pirmā iebīda dalību lietotāja meklēšanā, pieprasot atribūtu lietotāja objektā; otrā atstāj lietotāja meklēšanu mierā un ļauj spraudnim vēlāk meklēt grupas objektu. Izvēlieties vienu katram izvietojumam un pierakstiet, kuru izvēlējāties.

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

Ar šo formu filtrs nosaka visu, tāpēc RequireGroup ir jābūt false, citādi spraudnis dosies meklēt grupas objektu, kuru filtrs nekad nav pieminējis. Filtra atribūtam jāpastāv lietotāja objektā un jābūt aizpildītam, kas nav garantēts, tiklīdz grupas ir ligzdotas.

Otra forma saglabā meklēšanu vienkāršu un pievieno grupas meklēšanu pēc tam. Grupas objekts tiek nosaukts skaidri, un spraudnis salīdzina lietotāju ar dalībniekiem, ko katalogs tam atgriež. Lietotāja filtrā nekas nemainās, kas šo formu padara vieglāk auditējamu, kad grupu pārvalda cita komanda.

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

Aklā zona ir kopīga: vienkāršs dalības salīdzinājums neizvērš ligzdotās grupas, tāpēc konts, kura piekļuve nāk caur vecākgrupu, neizdodas, kamēr konsole joprojām rāda dalību. Active Directory atklāj member grupā, citas shēmas izmanto uniqueMember, un norādot uz nepareizo atribūtu tiek atgriezts tukšs rezultāts, nevis kļūda.

Izvēlieties galapunktu, kas satur grupas objektu

URL nosaka, kuru katalogu spraudnis jautā, un domēna kontrolieris uz porta 389 atbild tikai par savu nosaukumu kontekstu. Globālais katalogs uz porta 3268 atbild par visu mežu, tikai lasīšanai un ar daļēju atribūtu kopu. Kad konti atrodas vienā domēnā, bet VPN grupa citā, viena domēna vaicājums var atrast lietotāju un tomēr palaist garām dalību. Šis ir gadījums, kad URL pārvietošana uz kataloga portu atrisina noraidījumu, un tas ir arī gadījums, kad cilvēki vispārina pārāk tālu.

Daļējā atribūtu kopa ir robeža: atribūtu, kura katalogā nav, nevar filtrēt, tāpēc viena un tā pati izmaiņa var likt vienam izvietojumam strādāt, bet citam atgriezt neko. Pirms bloka pārrakstīšanas pārliecinieties, ko galapunkts patiešām atgriež īstajam lietotājam un grupai. Novirzījumi un TLS atkal ir atsevišķi jautājumi, jo novirzījumam ir jāseko, un galapunktam, kam nepieciešams TLS, vajadzīgi atbilstošie uzticības faili.

Turiet konta stāvokli un meklēšanas apjomu savos laukos

Deaktivizācijas karodziņš pieder filtram, nevis grupas pārbaudei. Active Directory tas ir userAccountControl otrais bits, un bez šī nosacījuma deaktivizēts konts ar derīgu paroli autentificējas un pēc tam neizdodas grupas solī, kas izskatās kā autorizācijas kļūda. Meklēšanas apjoms pieder bāzes DN, jo sākšana no domēna saknes ir lēnāka un var saskanēt ar objektiem ārpus organizācijas vienības, kuru gribējāt aptvert.

Turiet arī piesaistes konta tiesības šauras. Plašas kataloga tiesības nepareizi konfigurētu filtru pārvērš veiksmīgā vaicājumā un slēpj kļūdu, līdz kāds kontu audita. Mainiet dalību pašā katalogā, nekad vietējā izņēmumu sarakstā, lai konta deaktivizēšana būtu pietiekama, lai noņemtu piekļuvi. Ja grupu pārvalda cita komanda, vienojieties par atribūtu, ko viņi aizpilda, pirms rakstāt tam filtru.

Pierādiet rezultātu ar trim kontiem

Palaidiet konfigurāciju pret trim identitātēm: atļauts dalībnieks, derīgs konts ārpus grupas un konts, kas ir deaktivizēts. Ja visi trīs tiek noraidīti, piesaiste vai grupas vaicājums ir salauzti; ja visi trīs tiek pieņemti, grupas nosacījums netiek piemērots vispār. Jaukts rezultāts ir vienīgais, kas pierāda, ka konfigurācija izšķir jums svarīgos gadījumus.

Izlasiet tās pašas trīs atbildes tieši no kataloga, pirms vainojat spraudni. Pirmais vaicājums rāda grupas atribūtu, no kura atkarīgs filtrs, un otrais rāda konta vadības vērtību. Aizstājiet ar savu bāzes DN, kontu un galapunktu:

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

Lietotājs, kuram memberOf atgriežas tukšs, ir kataloga fakts, nevis spraudņa kļūda, un konts, kas pēc deaktivizēšanas joprojām autentificējas, nozīmē, ka filtram trūkst konta vadības nosacījuma. Vispirms izlabojiet šo pierādījumu, pēc tam vēlreiz palaidiet trīs kontu testu. Turiet žurnāla rindu, kas nosauca neizdevušos soli, blakus konfigurācijas izmaiņām, lai nākamā persona varētu atdalīt autorizāciju no autentifikācijas, neatkārtojot meklēšanu.

Saistītie raksti