NetExtender входить, але доступу нема: SonicWall локальний + LDAP
NetExtender підключається, але ніщо не відповідає: відокремте автентифікацію SonicWall, членство в службі SSL VPN і дозволи доступу VPN для локальних користувачів і користувачів LDAP.
Вхід успішний, тунель піднімається, і ніщо за міжмережевим екраном не відповідає. Цей шаблон на SonicWall SSL VPN зазвичай означає, що обліковий запис пройшов автентифікацію і зупинився на одному з двох наступних дозволів: допуску до служби SSL VPN або дозволу досягти ресурсу. Змішані локальні та LDAP-записи погіршують ситуацію, бо два сховища досягають цих дозволів різними шляхами. Симптом однаковий з боку клієнта, тому шари треба навмисно розділяти.
Симптом і три дозволи за ним
Між іменем користувача і доступним сервером стоять три незалежні рішення. Метод автентифікації вирішує, чи приймаються облікові дані і яким сховищем. Членство в службі SSL VPN вирішує, чи може цей обліковий запис взагалі використовувати SSL VPN. Список доступу VPN вирішує, до яких приватних призначень сеанс може дістатися. Проходження одного нічого не каже про наступні два.
Користувач, який проходить автентифікацію, але не входить до групи служби SSL VPN, бачить з'єднання, яке встановлюється і потім нічого не передає, а журнал міжмережевого екрана показує прийнятий вхід, а не помилку. Це випадок, який варто швидко розпізнати, бо рішення — членство в групі, а не скидання пароля.
Користувач, який допущений, але не має ресурсів, бачить сеанс, який підключається і нікуди корисно не маршрутизується. Обидва виглядають як зламаний тунель з погляду служби підтримки, і обидва — це конфігурація, а не зв'язність.
Поле домену — не каталог
NetExtender запитує домен, і це поле не є базою пошуку для Active Directory. У стандартній конфігурації поле має дорівнювати домену користувача SSL VPN, налаштованому на міжмережевому екрані, а документоване значення за замовчуванням для нього LocalDomain. Порівняння розрізняє великі та малі літери, тому значення, введене з іншим регістром, не проходить навіть за правильного облікового запису.
Якщо налаштовано розділення автентифікації, зовнішній контекст автентифікації вибирають назви розділів, а налаштоване значення за замовчуванням зберігає свою роль. В обох конфігураціях мітка домену на боці клієнта не передається в LDAP або RADIUS як частина імені користувача, тому вона не може керувати пошуком у каталозі.
Тримайте три рядки окремо в нотатках: DNS-суфікс компанії, базу пошуку LDAP і мітку домену NetExtender. Вони виглядають схоже, і жоден не замінює інший. Копіюйте значення оператора для цієї установки, а не значення з повідомлення на форумі про іншу версію прошивки.
Допуск і доступ до ресурсів — окремі дозволи
Локальним обліковим записам потрібне членство в групі служби SSL VPN, перш ніж служба їх прийме. Записи каталогу досягають тієї ж групи через підтримуваний процес зіставлення груп, тобто зв'язок групи LDAP треба налаштувати, а потім перевірити як фактичне членство, а не припускати з боку каталогу.
Доступ до ресурсів іде далі, у розділі доступ VPN для користувача або групи. Дайте конкретні підмережі та служби, потрібні ролі, і не піддавайтеся спокусі видати всю локальну мережу, бо потрібен один застосунок. Маршрути сеансу, правила доступу й дозволи служби призначення мають усі відповідати цьому обсягу.
| Layer | What it decides | Where it is set |
|---|---|---|
| Authentication | Whether the credential is accepted, and by which store | Authentication method and directory configuration |
| Admission | Whether the identity may use the SSL VPN | SSL VPN service group membership |
| Resource | Which destinations the session may reach | VPN Access on the user or group |
Маршрут на клієнті робить призначення вибираним і не дає на нього дозволу. Членство в групі SSL VPN також не робить обліковий запис адміністратором міжмережевого екрана, і не варто ставитися до нього як до загального надання привілеїв.
Два облікові записи, по чотири перевірки
Тестуйте з одним локальним записом і одним записом каталогу, обидва вузько авторизовані й обидва задокументовані як тестові. Для кожного запишіть джерело автентифікації, яке прийняло вхід, ефективні групи, призначений доступ до ресурсів і одну дозволену операцію застосунку. Чотири перевірки, два сховища і письмовий результат для кожної комбінації.
Потім перевірте негативні випадки: ресурс, до якого запис не повинен діставатися, і запис, який треба відхилити одразу. Дизайн, що доводить лише позитивний шлях, часто залишає відкритим другий вхід, особливо коли те саме коротке ім'я користувача існує в обох сховищах. Вимкніть запис каталогу і переконайтеся, що локальний не продовжує тихо працювати.
Перегляньте дублікати імен як частину впровадження, а не після інциденту. Одна й та сама людина в двох сховищах водночас і зручність підтримки, і проблема аудиту, а міжмережевий екран охоче автентифікує той запис, який ви налаштували.
Тримайте шлях відновлення вузьким
Зберігайте політику MFA для кожного класу записів, замість того щоб звільняти від неї локальні записи. Якщо локальні записи дають затверджений шлях відновлення на випадок збою каталогу, обмежте цей шлях названими адміністраторами і ведіть його свідомо, бо локальний аварійний запис для кожного працівника — це друга система автентифікації з слабшим наглядом.
Запишіть домен клієнта, джерело автентифікації і чинний доступ в один запис. Наступний адміністратор зможе тоді відтворити робочий дизайн змішаних записів, замість того щоб перебирати рядки домену, доки вхід не вдасться.