Клієнт Windows IKEv2 підключається, і запит RADIUS надходить з адресою там, де має бути ім'я облікового запису. Поки нічого не зламалося, і саме це бентежить: шлюз повідомляє ідентифікатор, який клієнт представив на рівні IKE. Ім'я користувача, яке потрібне вашому бекенду, може надходити з окремого обміну EAP, що ще не відбувся. Вирішіть, хто його запитує, перш ніж змінювати обліковий запис.

Два ідентифікатори подорожують в одному з'єднанні

В одному з'єднанні можуть з'явитися два імені. Ідентифікатор IKE визначає партнера під час налаштування тунелю, і плагін eap-radius спочатку копіює його в RADIUS User-Name. Ідентифікатор EAP — інше значення, яке використовується для автентифікації користувача, і він може ніколи не надсилатися, якщо ніхто його не запросить.

Тому журнал RADIUS може показувати адресу, хоча обліковий запис існує, а пароль правильний. У бекенду запитують про неправильний рівень. Атрибут RADIUS — лише транспорт для обраного імені.

Попросіть шлюз запросити ідентифікатор EAP

Одна підтримувана конфігурація змушує шлюз запитувати ідентифікатор EAP до передавання автентифікації в RADIUS. У розділі віддаленої автентифікації з'єднання задайте метод eap-radius і явно запросіть ідентифікатор EAP. Фрагмент нижче належить усередину наявного блоку з'єднання, а не в окремий файл. Підтвердьте з'єднання й бекенд конфігурації, перш ніж копіювати синтаксис з іншого розгортання.

remote {
    auth = eap-radius
    eap_id = %any
}

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

Або дозвольте RADIUS розпочати обмін EAP

Інша конфігурація залишає перший хід на боці RADIUS. Плагін може надіслати індикацію EAP-Start замість очікування початкової відповіді з ідентифікатором, що дає змогу серверу керувати обміном. Це конфігурація рівня плагіна, тому вона впливає на кожне з'єднання, яке використовує плагін.

charon {
    plugins {
        eap-radius {
            eap_start = yes
        }
    }
}

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

Простежте одну спробу в обох журналах

Зіставте одну спробу в обох журналах. Дивіться на ідентифікатор IKE, потім на те, чи відбувається обмін EAP-Identity, потім на те, яке ім'я отримує крок автентифікації. Бекенд, який відхиляє адресу до обміну EAP, може зупинити процес раніше, ніж передбачуваний ідентифікатор взагалі буде помічений.

journalctl -u strongswan -f

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

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

Схожі статті