Аутентификация VPN-пользователей через Active Directory (NPS/RADIUS)

MAATRIX

Если у вас три VPN-сервера и на каждом — свой локальный список пользователей, вы уже знаете эту боль: увольняется сотрудник, и нужно вспомнить, где ещё у него был доступ, зайти туда руками и удалить учётку. Рано или поздно кого-то забывают. Network Policy Server (NPS) в связке с Active Directory решает это раз и навсегда: один каталог пользователей, один RADIUS-сервер, а VPN-шлюзы (RRAS, MikroTik, pfSense, да хоть Cisco) просто спрашивают у NPS «пустить или нет» на каждое подключение.

Зачем RADIUS между VPN и Active Directory

Без RADIUS у вас два плохих варианта. Первый — локальные пользователи прямо на VPN-сервере (в том же RRAS или на MikroTik): пароли живут отдельно от AD, синхронизировать их вручную — сизифов труд, а при увольнении сотрудника вы физически не сможете быть уверены, что закрыли все входы. Второй — прямой LDAP-бинд с VPN-шлюза в AD: работает, но не на всех платформах есть нормальная поддержка, и вы теряете гибкость политик (время суток, группы, тип подключения).

RADIUS — это протокол-посредник. VPN-сервер (RADIUS-клиент) отправляет запрос аутентификации на NPS (RADIUS-сервер), NPS проверяет логин и пароль в Active Directory, применяет политики доступа (сетевые политики NPS) и возвращает Access-Accept или Access-Reject — вместе с атрибутами вроде выделяемого VLAN или таймаута сессии. Дальше можно подключить хоть десять VPN-шлюзов к одному NPS, и все они будут жить по единым правилам домена: те же пароли, та же двухфакторка (если она настроена через AD), та же политика блокировки после N неверных попыток.

Отдельный плюс — централизованный аудит. Все попытки подключения логируются в одном месте (Event Viewer на сервере NPS, категория Network Policy Server), и не нужно собирать логи с трёх разных серверов, чтобы понять, кто и когда заходил.

Установка роли NPS

NPS — это роль сервера, которая ставится через Server Manager или PowerShell. Сам NPS не обязан жить на контроллере домена — обычно его выносят на отдельный сервер или ставят рядом с VPN-шлюзом, если это тоже Windows Server.

Install-WindowsFeature NPAS -IncludeManagementTools

После установки NPS должен быть зарегистрирован в Active Directory — это даёт ему право читать атрибуты dial-in пользователей и группы:

netsh nps add registeredserver

Без этой команды NPS будет молча отклонять запросы или выдавать ошибку авторизации — на неё стоит проверить в первую очередь, если аутентификация не проходит после чистой установки.

Если сервер NPS не входит в тот же домен, где расположены пользователи (или расположен в отдельном лесу с доверием), проверьте, что доверительные отношения (trust) настроены и позволяют аутентификацию — иначе NPS не увидит учётные записи.

RADIUS-клиенты: подключаем VPN-шлюз к NPS

Каждый VPN-сервер, который будет спрашивать NPS об аутентификации, нужно зарегистрировать как RADIUS-клиент — по IP-адресу и с общим секретом (shared secret), который знают обе стороны.

Через оснастку NPS (nps.msc): «RADIUS Clients and Servers» → «RADIUS Clients» → «New».

Ключевые поля:

• Friendly name — понятное имя, например VPN-Gateway-Moscow.
• Address (IP or DNS) — IP-адрес VPN-сервера, с которого будут приходить RADIUS-запросы.
• Shared secret — длинная случайная строка (от 22 символов), одинаковая на NPS и на VPN-шлюзе. Это не пароль пользователя, а ключ, которым RADIUS-пакеты подписываются и (частично) шифруются — относитесь к нему как к секрету инфраструктуры.

Через PowerShell то же самое делается быстрее, особенно если клиентов много:

New-NpsRadiusClient -Name "VPN-Gateway-Moscow" -Address "10.0.5.10" -SharedSecret "оченьдлинныйислучайныйсекрет123!"

Если VPN-шлюз — это RRAS на том же или соседнем Windows Server, IKEv2/L2TP/SSTP-подключения можно настроить с нуля по нашим статьям — например, RRAS VPN IKEv2 с нуля или RRAS VPN SSTP с нуля — а затем просто переключить метод аутентификации RRAS с Windows-аутентификации на RADIUS, указав адрес сервера NPS.

Для не-Windows шлюзов (MikroTik, pfSense, Cisco ASA) настройка аналогична: в интерфейсе устройства указывается IP сервера NPS, порты (обычно UDP 1812 для аутентификации и UDP 1813 для accounting) и тот же shared secret.

Сетевые политики NPS: кто и как получает доступ

Здесь начинается настоящая гибкость NPS — сетевые политики (Network Policies) определяют, кому разрешено подключаться и на каких условиях. Политики обрабатываются по порядку сверху вниз, и побеждает первая подошедшая.

Типичная структура для компании с двумя отделами:

1. VPN-Admins       — разрешить, группа AD "VPN-Admins", без ограничений по времени
2. VPN-RemoteStaff  — разрешить, группа AD "VPN-Users", только будни 07:00-21:00
3. Default Deny     — запретить всё остальное

Создание политики через PowerShell (пример для группы удалённых сотрудников):

New-NpsNetworkPolicy -Name "VPN-RemoteStaff" `
  -Enabled $true `
  -Order 2 `
  -Condition @{WindowsGroups="CONTOSO\VPN-Users"} `
  -Access Grant `
  -AuthenticationMethod EAPTLS `
  -TunnelType L2TP

Через GUI это делается на вкладке «Policies» → «Network Policies» → «New». Обратите внимание на порядок вкладок при создании:

1. Conditions — условия срабатывания: группа Windows, тип NAS-порта (VPN), время суток, день недели.
2. Access Permission — Grant или Deny.
3. Authentication Methods — обязательно проверьте, что включены нужные протоколы (MS-CHAPv2 как минимум, EAP-TLS для сертификатной аутентификации, если она используется).
4. Constraints — тайм-ауты сессии, ограничение по дню/времени.
5. Settings — здесь можно назначить IP-фильтры, VLAN ID, статический маршрут для конкретной группы.

Практический совет: держите политику Default Deny всегда последней и явно видимой — это ваша страховка от ситуации «неопределённая группа получила доступ по умолчанию». NPS, как и большинство RADIUS-серверов, по умолчанию либеральный, если явного запрета нет.

Группы безопасности AD как единица управления доступом

Вместо того чтобы прописывать в политике NPS конкретных пользователей, используйте группы безопасности Active Directory — это ключевая идея всей схемы. Заводите группу VPN-Users (или несколько — по отделам, по уровню доступа), включаете туда учётные записи, а NPS ссылается на группу в условиях политики.

New-ADGroup -Name "VPN-Users" -GroupScope Global -GroupCategory Security -Path "OU=Groups,DC=contoso,DC=local"
Add-ADGroupMember -Identity "VPN-Users" -Members "ivanov.p", "petrova.a"

Дальше управление доступом сводится к добавлению/удалению пользователя из группы — никаких изменений на VPN-серверах не требуется. Уволили сотрудника — убрали из AD (или из группы) — доступ пропал сразу на всех VPN-шлюзах, подключённых к NPS. Это и есть главный практический выигрыш централизованной схемы.

Отдельно стоит проверить свойство dial-in на самой учётной записи пользователя (вкладка «Dial-in» в ADUC, параметр Network Access Permission) — по умолчанию в доменах, поднятых в родном режиме Windows Server 2000+, оно выставлено в «Control access through NPS Network Policy», что и нужно. Но если в вашем домене остались легаси-настройки, где-то может стоять явный Deny на конкретных учётках — это перебивает любую политику NPS.

Логирование и troubleshooting

Первое место, куда стоит смотреть при проблемах с аутентификацией — Event Viewer → Custom Views → Server Roles → Network Policy and Access Services. Там пишутся все Access-Accept и Access-Reject с указанием, какая именно политика сработала (или не сработала).

Полезная таблица частых кодов reason-code при отказе:

Для более подробного разбора включите логирование NPS в файл (вкладка «Accounting» в оснастке NPS) — формат IAS-совместимый, читается стандартными парсерами RADIUS-логов, и там видно полный обмен атрибутами, а не только итоговый вердикт.

Ещё одна частая проблема — рассинхронизация shared secret. Она проявляется характерно: NPS вообще не создаёт запись в логе о попытке аутентификации (потому что не может проверить подпись пакета и тихо его отбрасывает), тогда как ошибки логина/пароля всегда оставляют запись. Если подключений в логе NPS нет вообще — проверяйте секрет и сетевую доступность (UDP 1812/1813 между VPN-шлюзом и NPS, никакой firewall между ними не режет).

Если сам VPN-сервер настроен через RRAS и проблема не в NPS, а в самом туннеле — посмотрите отдельные статьи о частых ошибках подключения, например по мониторингу активных VPN-подключений: мониторинг VPN-подключений на Windows Server — там разобраны сценарии, когда соединение обрывается уже после успешной аутентификации.

Отказоустойчивость: второй NPS-сервер

Единственный NPS — это единая точка отказа: упал сервер — никто не может подключиться к VPN, даже если сам VPN-шлюз жив. Стандартное решение — поднять второй NPS и указать оба сервера на VPN-шлюзе как основной и резервный RADIUS-сервер (большинство платформ, включая RRAS, MikroTik и pfSense, поддерживают список из нескольких RADIUS-серверов с приоритетом).

Конфигурации политик между двумя NPS-серверами синхронизируются вручную или через экспорт/импорт:

Export-NpsConfiguration -Path "C:\nps-backup\nps-config.xml"

На втором сервере:

Import-NpsConfiguration -Path "C:\nps-backup\nps-config.xml"

Это не живая репликация — при изменении политик на основном сервере нужно повторно экспортировать и импортировать на резервный. Для небольшой инфраструктуры (до пары десятков RADIUS-клиентов) этого достаточно; для крупных сред стоит автоматизировать экспорт по расписанию через задачу планировщика, чтобы резервный сервер не отставал слишком сильно.

Учтите ограничение: NPS в Windows Server не имеет встроенного кластера с общим состоянием сессий — если пользователь подключился через первый NPS и тот упал посреди сессии, переподключение пойдёт через второй NPS как новая аутентификация. Для VPN это обычно не критично (клиент просто переподключается), но стоит держать в голове при проектировании SLA.

Частые вопросы