OpenVPN LDAP автентикацијата работи, но проверката на групата не успева: каде да се погледне

Автентикацијата може да помине додека проверката на групата ги одбива сите. По ред разгледајте го блокот Authorization, атрибутот за членство и крајната точка на директориумот.

Пријавните податоци поминуваат, тунелот почнува да се крева, а потоа сесијата не успева со порака за групата, а не за лозинката. Таа комбинација ја сместува грешката во втората половина од работата на додатокот LDAP: врзувањето и проверката на лозинката успеаја, а одлуката за членство што следи не. Двете половини читаат од истиот конфигурациски блок, затоа поправка на едно место може да ја остави другата недопрена. Започнете од линијата во дневникот што го именува чекорот, а не од сметката со која случајно тестирате.

Третирајте го одбивањето како одговор за авторизација

Додатокот извршува врзување на услуга, ја бара сметката, ја проверува дадената лозинка и потоа прашува дали таа сметка припаѓа на дозволена група. Тоа се четири одделни операции, и само последната е за групи. Затоа одбивањето што доаѓа по успешно врзување не кажува ништо за лозинката, дури и кога клиентот прикажува општа грешка при автентикација. Подигнувањето на нивото на дневникот на додатокот пред да се смени конфигурацијата е она што ги раздвојува четирите во излезот.

Побарајте ја самата проценка на групата. Кога воопшто не се појавува барање за група, блокот за авторизација не се достигнува, што обично значи дека директивата стои надвор од блокот што ја поседува или дека недостига задолжителна опција. Кога барањето се појавува и не враќа ништо, крајната точка или филтерот одговараат на друго прашање од она што сте го мислеле.

Одлучете дали членството живее во филтерот или во блок за група

Постојат два поддржани облика и нивното мешање е начинот на кој работечката конфигурација престанува да работи. Првиот го турка членството во пребарувањето на корисници барајќи атрибут на корисничкиот објект; вториот го остава пребарувањето на корисници на мир и му дозволува на додатокот подоцна да го побара објектот на групата. Изберете еден по распоредување и запишете кој сте го избрале.

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

Со тој облик филтерот одлучува за сите детали, затоа RequireGroup мора да биде false, инаку додатокот оди да бара објект на група што филтерот никогаш не го спомнал. Атрибутот во филтерот мора да постои на корисничкиот објект и да биде пополнет, што не е загарантирано штом групите се вгнездени.

Другиот облик го држи пребарувањето едноставно и додава барање за група по него. Објектот на групата се именува експлицитно и додатокот го споредува корисникот со членовите што директориумот ги враќа за него. Ништо во корисничкиот филтер не се менува, што го прави овој облик полесен за ревизија кога групата ја управува друг тим.

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

Слепата точка е заедничка: едноставната споредба на членство не ги разградува вгнездените групи, затоа сметката чиј пристап доаѓа преку родителска група не успева, додека конзолата и понатаму го покажува членството. Active Directory го изложува member на групата, други шеми користат uniqueMember, а покажувањето на погрешен атрибут враќа празен резултат наместо грешка.

Изберете крајна точка што го содржи објектот на групата

URL-то одлучува кој директориум го прашува додатокот, а контролерот на домен на портата 389 одговара само за својот контекст на имиња. Глобалниот каталог на портата 3268 одговара за целата шума, само за читање и со делумен сет на атрибути. Кога сметките се во еден домен, а VPN групата во друг, барање на еден домен може да го најде корисникот и сепак да го пропушти членството. Тоа е случајот кога преместувањето на URL-то на портата на каталогот го решава одбивањето, и тоа е исто така случајот кога луѓето претерано генерализираат.

Делумниот сет на атрибути е границата: атрибут што каталогот не го содржи не може да се филтрира, затоа истата промена може да направи едно распоредување да работи, а друго да врати ништо. Пред да го препишете блокот, потврдете што крајната точка навистина враќа за вистинскиот корисник и група. Препратките и TLS се повторно одделни прашања, бидејќи препратката мора да се следи, а крајната точка што бара TLS има потреба од соодветните доверливи датотеки.

Држете ја состојбата на сметката и опфатот на пребарувањето во нивни полиња

Знамето за деактивирање припаѓа на филтерот, не на проверката на групата. Во Active Directory тоа е вториот бит на userAccountControl, и без тој услов деактивирана сметка со валидна лозинка се автентицира и потоа не успева на чекорот со групата, што изгледа како грешка во авторизацијата. Опфатот на пребарувањето припаѓа на основниот DN, бидејќи почнувањето од коренот на доменот е побавно и може да погоди објекти надвор од организациската единица што сте сакале да ја покриете.

Држете ги и правата на сметката за врзување тесни. Широките права во директориумот претвораат погрешно конфигуриран филтер во успешно барање и ја кријат грешката додека некој не ја ревидира сметката. Менувајте го членството во самиот директориум, никогаш во локален список на исклучоци, за да биде доволно деактивирањето на сметката за да се отстрани пристапот. Ако групата ја управува друг тим, договорете се за атрибутот што тие го пополнуваат пред да напишете филтер врз него.

Докажете го резултатот со три сметки

Пуштете ја конфигурацијата против три идентитети: дозволен член, валидна сметка надвор од групата и сметка што е деактивирана. Ако сите три се одбиени, врзувањето или барањето за група се скршени; ако сите три се прифатени, воопшто не се применува услов за група. Мешовитиот резултат е единствениот што докажува дека конфигурацијата ги разликува случаите што ви се важни.

Прочитајте ги истите три одговори директно од директориумот пред да го обвините додатокот. Првото барање го покажува атрибутот на групата од кој зависи филтерот, а второто ја покажува вредноста за контрола на сметката. Заменете со свој основни DN, сметка и крајна точка:

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

Корисник чиј memberOf се враќа празен е факт од директориумот, не грешка на додатокот, а сметка што и понатаму се автентицира по деактивирањето значи дека на филтерот му недостига условот за контрола на сметката. Прво поправете го тој доказ, потоа повторно пуштете го тестот со три сметки. Држете ја линијата во дневникот што го именуваше неуспешниот чекор до промената во конфигурацијата, за да може следната личност да ја оддели авторизацијата од автентикацијата без да го повторува пребарувањето.

Поврзани статии