Добавление пользователя в группу VPN само по себе не даёт доступа
Членство в группе — одно условие, а не разрешение. Посмотрите, что шлюз действительно сопоставил, прочитайте запись о приёме или отказе и проверьте оба исхода.
Учётная запись в нужной группе, вход прошёл, а соединение всё равно отклоняется или устанавливается и не даёт ничего полезного. Обычная реакция — добавлять пользователя в новые группы, пока что-то не ослабнет, и так организации выдают гораздо больше, чем просил тикет. Членство в группе — один вход в решение об авторизации, но никогда само решение: шлюз собирает несколько фактов о сеансе, сопоставляет их с упорядоченной политикой и только затем решает, к чему сеанс имеет доступ. Если не выполнено другое условие, смена группы меняет только вашу экспозицию.
Членство в группе — условие, а не разрешение
В RADIUS группа приходит как атрибут авторизации, а атрибуты описывают сеанс, а не разрешают его. Сервер отвечает Access-Accept или Access-Reject; при принятии он может приложить Filter-Id, Class или туннельные атрибуты из RFC 2868, и сетевое оборудование на другом конце трактует их так, как решил производитель. Ничто в протоколе не превращает группу в полный доступ; это сопоставление пишет тот, кто настроил политику на шлюзе или сервере сетевого доступа.
Поэтому одно и то же имя группы ведёт себя по-разному в двух системах. Microsoft NPS собирает сетевые политики из условий, ограничений и настроек и оценивает их в заданном порядке. OpenVPN Access Server имеет собственную модель групп и правил доступа, а общинный сервер OpenVPN часто передаёт весь вопрос скрипту client-connect или файлу client-config-dir.
Решает правило, которое совпало, а не группа, которую вы ждали
Большинство движков останавливаются на первой подходящей политике или на самой конкретной. Если политика 3 отказывает, а политика 7 разрешает, сеанс может не пройти, так и не дойдя до правила, которое его пропустило бы. Порядок — реальная настройка в NPS и большинстве продуктов контроля сетевого доступа, и он смещается с годами.
Условия, идущие вместе с группой, — вторая половина. Состояние устройства, метод аутентификации, завершённая MFA, исходная сеть, субъект сертификата или временное окно могут быть в одной политике. Если одного нет, политика не совпадает, движок падает, и действует отказ по умолчанию. С точки зрения пользователя группа игнорируется; с точки зрения движка группу вообще не спрашивали.
Детали каталога создают ту же иллюзию. Политика по членству в группах Windows читает SID в токене пользователя, а там перечислены только группы безопасности, группа распространения никогда не появляется. Основная группа хранится в отдельном поле, а не в списке, поэтому политика, привязанная к ней, может тихо не сработать.
Прочитайте запись о приёме или отказе, прежде чем трогать группу
Сначала один вопрос: дошёл ли запрос до этапа авторизации? В NPS ответ уже в журнале событий, где 6272 фиксирует выданный доступ, 6273 — отказ, а 6274 — запрос, отброшенный сервером до оценки политики. Эти три числа делят проблему на три разных расследования, и только одно из них про группы.
| What the record shows | What it means | Where to look next |
|---|---|---|
| 6272, access granted | Authentication and authorization both succeeded | Routes, split tunnel, DNS, per-resource rules |
| 6273, access denied | A policy matched and denied, or nothing matched and the default denied | The conditions of the policy that fired, in order |
| 6274, request discarded | The request never reached authorization | Shared secret, NAS client entry, proxy chain, malformed attributes |
Если журнал недоступен, спросите сервер напрямую и прочитайте ответ. Ответ без Filter-Id и туннельных атрибутов означает, что сервер считает сеанс обычным, а шлюз применяет собственные правила. Ответ с атрибутами, которые точка применения не реализует, — другая неисправность: авторизация прошла, а устройство проигнорировало результат.
radtest alice 'password' 10.0.0.5 0 testing123Сравните возвращённые атрибуты с теми, что документирует шлюз, а не с тем, что подсказывает имя группы. Это сравнение обычно отделяет проблему политики от проблемы применения.
Смена группы не действует задним числом
Атрибуты авторизации возвращаются один раз, при аутентификации сеанса. Шлюз хранит их на сеансе и не перечитывает каталог для каждого пакета, поэтому установленный сеанс продолжает работать после удаления пользователя из группы, а новый может не пройти.
Чтобы изменение вступило в силу, нужно новое решение об авторизации, а не только новые ключи. Если сервер поддерживает RFC 5176, Disconnect-Request или CoA-Request на UDP 3799 заставляет сеанс пересчитать; иначе отключите клиента и дайте ему подключиться заново. Переговоры обновляют ключи туннеля и обычно не трогают результат авторизации.
Исправляйте условие, а не группу
Когда известно, какая политика сработала, исправление обычно малое: переставьте отказ, который заслоняет нужное разрешение, добавьте недостающее условие устройства или MFA в политику, которую вы имели в виду, или напишите узкое правило для одного ресурса вместо повышения пользователя в группу с ещё десятью.
Короткий цикл держит изменение честным:
- Воспроизведите отказ с исходной учётной записью и запишите ID события, прежде чем что-то менять.
- Меняйте один объект — порядок политик, одно условие или одну группу — и записывайте, какой именно.
- Откройте новый сеанс, убедитесь, что разрешение видно в журнале, и что ресурс действительно открывается.
- Проверьте пользователя, которому всё ещё должны отказывать, чтобы исправление не расширило политику случайно.
Если разрешение верное, а ресурс не открывается, проблема сместилась в маршрутизацию или разрешение имён в момент, когда авторизация прошла. Держите эти две неисправности раздельно, и следующий тикет займёт минуты, а не полдня.