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

Удостоверяването може да мине, докато проверката на групата отхвърля всички. Разгледайте блока Authorization, атрибута за членство и крайната точка на директорията едно по едно.

Данните за вход минават, тунелът започва да се вдига и след това сесията се проваля със съобщение за групата, а не за паролата. Тази комбинация поставя неизправността във втората половина от работата на LDAP плъгина: обвързването и проверката на паролата са успели, а решението за членство, което следва, не е. Двете половини четат от един и същ конфигурационен блок, затова поправка на едно място може да остави другата незасегната. Започнете от реда в журнала, който назовава стъпката, а не от акаунта, с който случайно тествате.

Третирайте отказа като отговор за оторизация

Плъгинът извършва service bind, търси акаунта, проверява подадената парола и след това пита дали този акаунт принадлежи на разрешена група. Това са четири отделни операции и само последната е за групи. Затова отказ, който идва след успешен bind, не казва нищо за паролата, дори когато клиентът показва обща грешка за удостоверяване. Повишаването на нивото на журнала на плъгина преди промяна на конфигурацията е това, което разделя четирите в изхода.

Търсете самата оценка на групата. Когато изобщо не се появи заявка за група, блокът за оторизация не се достига, което обикновено означава, че директива стои извън блока, който я притежава, или липсва задължителна опция. Когато заявката се появи и не върне нищо, крайната точка или филтърът отговаря на друг въпрос, а не на този, който сте имали предвид.

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

Има две поддържани форми и смесването им е начинът, по който работеща конфигурация спира да работи. Първата изтласква членството в търсенето на потребители, като иска атрибут върху обекта на потребителя; втората оставя търсенето на потребители непокътнато и кара плъгина да потърси обекта на групата след това. Изберете една за всяко внедряване и запишете коя сте избрали.

<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 се връща празен, е факт от директорията, а не дефект на плъгина, а акаунт, който все още се удостоверява след деактивиране, означава, че на филтъра липсва условието за контрол на акаунта. Поправете това доказателство първо, после пуснете отново теста с три акаунта. Дръжте реда в журнала, който назоваваше провалилата се стъпка, до промяната в конфигурацията, за да може следващият човек да отдели оторизацията от удостоверяването, без да повтаря търсенето.

Подобни статии