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

Аутентификација може да прође док провера групе одбија све. По реду прегледајте 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 се враћа празан је чињеница директоријума, не грешка додатка, а налог који се и после деактивације аутентификује значи да филтеру недостаје услов контроле налога. Прво поправите тај доказ, затим поново покрените тест са три налога. Држите линију дневника која је именовала неуспели корак поред промене конфигурације, да би следећа особа могла да раздвоји ауторизацију од аутентификације без понављања претраге.

Повезани чланци