Автентифікація 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 повертається порожнім, — це факт каталогу, а не помилка плагіна, а обліковий запис, який після вимкнення все ще проходить автентифікацію, означає, що у фільтрі немає умови керування обліковим записом. Спершу виправте цей доказ, а потім знову запустіть тест із трьома обліковими записами. Тримайте рядок журналу, де названо збійний крок, поруч зі зміною конфігурації, щоб наступна людина могла відокремити авторизацію від автентифікації, не повторюючи пошук.

Схожі статті