Realm автентифікації VPN: який простір імен облікових записів перемагає?

Кожен вхід у VPN потрапляє до якогось простору імен облікових записів, і realm — це селектор, який вирішує, до якого саме. Він нічого не каже про країну, розташування сервера чи рівень довіри. Два однакові імена користувача можуть жити в різних realm, тому правильний пароль іноді автентифікує не той обліковий запис. Цей посібник спершу фіксує форму ідентифікатора, а потім простежує запит до системи, яка фактично відповіла.

Що вибирає realm

Шлюз отримує ім'я користувача і має вирішити, де його перевіряти. Realm — це частина цього імені або атрибут поруч із ним, який вибирає базу даних: каталог, пул RADIUS, локальний файл облікових записів. NPS від Microsoft називає це іменем realm і маршрутизує за ним запити підключення, а ідентифікатор мережевого доступу EAP несе ту саму ідею як суфікс після знака at у RFC 7542. Обидва є селекторами, і жоден не вирішує, чи придатні облікові дані.

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

Синтаксис realm належить розгортанню. Одні служби хочуть некваліфіковане ім'я плюс атрибут, інші хочуть user@domain, а небагато очікують форму зі зворотною косою рискою, про яку більшість посібників не згадує.

Використовуйте форму, якої очікує бекенд

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

Не вважайте адміністративний обліковий запис доказом. Вебконсоль, у якій ви керуєте службою, може автентифікуватися за локальним файлом, тоді як тунель перевіряє зовсім інший каталог. Тестуйте з обліковими даними, які використав би реальний користувач, в інтерфейсі, який використав би реальний користувач. Успішний вхід у консоль нічого не каже про realm, який шлюз застосовує до автентифікації VPN.

Браузери та поштові клієнти іноді кешують попередній ідентифікатор і мовчки надсилають його знову. Коли повідомлене ім'я користувача відрізняється від введеного, цей кеш — перше місце для перевірки.

Простежте запит через проксі

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

grep -n -A4 '^realm' /etc/freeradius/3.0/proxy.conf
radtest '[email protected]' 'wrong-password' 10.20.30.10 0 testing123
journalctl -u freeradius --since '-10 min' | grep -iE 'realm|stripped'

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

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

Зафіксуйте спробу, не розкриваючи її

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

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