OpenVPN username-as-common-name: чому ваша перевірка CN порожня

Ви додаєте скрипт client-connect, який відхиляє будь-яке з'єднання, де common_name відрізняється від username, і це виглядає як прив'язка сертифіката до облікового запису. На сервері з username-as-common-name це порівняння вже втратило сенс на момент запуску скрипта. Обидва значення — той самий рядок, тому перевірка проходить і для сертифіката, виданого зовсім іншій людині.

Перевірка неправильна не тому, що скрипт погано написаний. Вона неправильна тому, що значення, яке він читає, було замінене раніше в тому самому з'єднанні.

Що порівняння нібито доводить

Автентифікація за сертифікатом і автентифікація за паролем — різні докази, і сервер може вимагати обидва, не вимагаючи, щоб вони належали одній людині. Розрив реальний: чинний сертифікат пристрою плюс будь-який чинний обліковий запис — це інше твердження, ніж той самий сертифікат плюс один названий обліковий запис. Скрипт, що порівнює common_name з username, читається як відсутня ланка між ними. Так і було б, якби common_name досі означало те, що сказав сертифікат.

Чи це так, залежить від однієї опції сервера, і цю опцію зазвичай вмикають з не пов'язаної причини, наприклад щоб файли конфігурації для кожного користувача було простіше називати.

Що username-as-common-name робить з іменем

Коли username-as-common-name увімкнено, OpenVPN замінює спільне ім'я сертифіката на автентифіковане ім'я користувача після перевірки імені користувача й пароля. Хук перевірки, що виконується під час цієї перевірки, все ще отримує спільне ім'я сертифіката, бо заміна ще не відбулася. Усе подальше, включно з client-connect, бачить ім'я користувача. Тому пізніший зворотний виклик отримує одну особу двічі й не може порівняти її з поданим сертифікатом.

Простежте одне ілюстративне з'єднання: сертифікат, виданий для bob-device, успішний вхід до каталогу як alice і ввімкнена опція. Етап перевірки все ще може бачити два різні рядки. Етап з'єднання бачить alice і alice.

Цей приклад показує, чому порівняння порожнє. Він не показує, що з'єднання інакше було б прийняте, оскільки перевірка сертифіката й перевірка пароля все ще працюють окремо.

Розмістіть прив'язку там, де обидві особи ще існують

Правило має застосовуватися на етапі, який бачить особу сертифіката й обліковий запис одночасно, що на практиці означає хук перевірки імені користувача та пароля або завантажений там плагін. Підтримуваний плагін, який уже виконує перевірку пароля, зазвичай є правильним місцем для додавання правила зіставлення, бо заміна його порівнянням імен повністю прибрала б перевірку пароля.

Визначте зіставлення до написання коду, оскільки рівність рідко буває справжньою політикою. Сертифікат часто ідентифікує пристрій, а вхід — людину, і один пристрій може законно обслуговувати кількох людей. Зберігайте зв'язок у формі, видачу якої контролюєте ви, і вирішіть, що відбувається при перейменуванні, перевидачі та з іменами з доменом. Переведення в нижній регістр або видалення доменного префікса без розуміння каталогу може об'єднати два облікові записи, які мали залишитися окремими.

Пам'ятайте, що опція також змінює, яка конфігурація для кожного клієнта застосовується, бо client-config-dir прив'язаний до спільного імені.

Перевірте зіставлення з двома чинними обліковими даними

Почніть із пари, яку дозволяє ваша політика, і підтвердьте, що вона з'єднується. Потім подайте той самий чинний сертифікат з іншим, але так само чинним обліковим записом: ця спроба має не вдатися, і невдача має бути через правило зіставлення, а не через неправильно введений пароль. Неправильний пароль доводить, що перевірка пароля працює, і нічого не каже про правило між сертифікатом і обліковим записом.

Перевірте також шляхи з відсутнім і недійсним сертифікатом і підтвердьте, яку особу сервер використовує для налаштувань кожного клієнта. Якщо єдиний спосіб змусити порівняння працювати — вимкнути username-as-common-name, спершу оцініть вартість цієї зміни, бо вона повертає пошук конфігурації кожного клієнта до імені сертифіката.