Как настроить RADIUS-сервер (NPS) в Windows Server

В Windows Server функции RADIUS-сервера выполняет служба Network Policy Server (NPS). Она позволяет централизованно выполнять аутентификацию и авторизацию пользователей и устройств при подключении к сетевому оборудованию, VPN-серверам и корпоративным Wi-Fi-сетям. NPS можно интегрировать с Active Directory и использовать существующие доменные учетные записи и группы безопасности для управления доступом.

В этой статье мы подробно разберем, как установить и настроить RADIUS-сервер на базе NPS в Windows Server 2025, 2022, 2019 и 2016. Настроим интеграцию с Active Directory, добавим RADIUS-клиентов и политики доступа, а затем рассмотрим практические примеры аутентификации на оборудовании Cisco и MikroTik. Отдельно покажем настройку RADIUS для корпоративной Wi-Fi-сети с аутентификацией 802.1X и разберем, где искать события и ошибки NPS при диагностике проблем.

Как настроить RADIUS-сервер в Windows Server: кратко

Чтобы настроить RADIUS-сервер в Windows Server, установите роль Network Policy and Access Services (NPAS) и службу Network Policy Server (NPS), зарегистрируйте NPS в Active Directory, добавьте сетевые устройства в качестве RADIUS-клиентов и создайте Network Policy с условиями доступа и необходимыми методами аутентификации. После этого NPS сможет централизованно аутентифицировать пользователей и устройства через RADIUS.

По умолчанию RADIUS использует UDP-порт 1812 для аутентификации и UDP-порт 1813 для Accounting. В качестве RADIUS-клиентов NPS могут выступать коммутаторы, маршрутизаторы, VPN-серверы и беспроводные точки доступа.

Что такое RADIUS и как он работает

RADIUS (Remote Authentication Dial-In User Service) — это сетевой протокол, предназначенный для централизованной аутентификации, авторизации и учета действий пользователей и устройств. Такой подход часто называют моделью AAA — Authentication, Authorization and Accounting.

Вместо того чтобы создавать отдельные локальные учетные записи на каждом коммутаторе, маршрутизаторе, VPN-шлюзе или точке доступа, можно передать проверку учетных данных центральному RADIUS-серверу. В инфраструктуре Windows Server эту роль выполняет Network Policy Server (NPS).

В доменной среде NPS можно интегрировать с Active Directory. Благодаря этому для доступа к сетевому оборудованию и другим ресурсам можно использовать существующие доменные учетные записи и группы безопасности AD. Например, администратор может входить на коммутатор Cisco под своей доменной учетной записью, а разрешение на доступ будет определяться членством пользователя в соответствующей группе Active Directory и настроенными политиками NPS.

Как работает RADIUS-аутентификация через NPS:

1. Пользователь пытается подключиться к сетевому устройству, VPN или корпоративной Wi-Fi-сети.
2. Сетевое устройство, выступающее в роли RADIUS-клиента, получает учетные данные пользователя и отправляет запрос на RADIUS-сервер.
3. NPS проверяет учетную запись пользователя и применяет настроенные политики доступа.
4. Если пользователь прошел проверку и соответствует условиям политики, NPS возвращает ответ Access-Accept. В противном случае сервер отправляет Access-Reject.
5. Сетевое устройство разрешает или запрещает пользователю доступ в зависимости от полученного ответа.

При необходимости RADIUS также может выполнять учет подключений (Accounting). В этом случае на сервер передается информация о начале и завершении пользовательских сессий и другие сведения о подключениях.

RADIUS использует UDP-порт 1812 для аутентификации и UDP-порт 1813 для учета (Accounting). В старых конфигурациях также можно встретить UDP-порт 1645 для аутентификации и UDP-порт 1646 для Accounting.

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

Установка и настройка NPS (RADIUS) в Windows Server

Для настройки RADIUS-сервера в Windows Server необходимо установить роль Network Policy and Access Services (NPAS) со службой Network Policy Server (NPS), зарегистрировать NPS в Active Directory и подготовить доменную группу пользователей, которым будет разрешена RADIUS-аутентификация.

Перед началом настройки убедитесь, что синхронизация времени в домене настроена корректно и время на сервере NPS, контроллерах домена и сетевых устройствах синхронизировано. Корректная синхронизация времени особенно важна при использовании сертификатов и методов аутентификации EAP-TLS/PEAP. Значительное расхождение времени может приводить к ошибкам аутентификации и проблемам при установлении защищенного соединения.

Проверить состояние синхронизации времени на Windows Server можно командой:

w32tm /query /status

На сетевом оборудовании также рекомендуется настроить синхронизацию времени с корпоративным NTP-сервером.

Например, на оборудовании Cisco настроить NTP-сервер и часовой пояс можно командами:

ntp server 192.168.1.10
clock timezone UTC 0

Установка NPS в Windows Server

Роль Network Policy Server входит в состав Network Policy and Access Services (Службы политики сети и доступа) и доступна в Windows Server 2025, 2022, 2019 и 2016.

Чтобы установить Network Policy Server (NPS) через графический интерфейс Windows Server, откройте Server Manager (Диспетчер серверов) и выберите:

Manage (Управление) → Add Roles and Features (Добавить роли и компоненты).

Пройдите стандартные этапы Add Roles and Features Wizard (Мастера добавления ролей и компонентов). На странице Server Roles (Роли сервера) установите флажок Network Policy and Access Services (Службы политики сети и доступа) и завершите установку роли.

После установки проверьте, что роль NPAS успешно добавлена на сервер:

Get-WindowsFeature -Name NPAS

В результате выполнения команды для Network Policy and Access Services в столбце Install State (Состояние установки) должно отображаться значение Installed (Установлено).

Чтобы установить Network Policy Server (NPS) с помощью PowerShell, выполните следующую команду:

Install-WindowsFeature NPAS -IncludeManagementTools

Параметр -IncludeManagementTools дополнительно устанавливает средства администрирования, необходимые для управления NPS.

После завершения установки откройте консоль Network Policy Server (Сервер политики сети):

Server Manager (Диспетчер серверов) → Tools (Средства) → Network Policy Server (Сервер политики сети).

Также оснастку можно запустить непосредственно командой:

nps.msc

Регистрация NPS в Active Directory

Если NPS будет использоваться для аутентификации доменных пользователей, сервер необходимо зарегистрировать в Active Directory. Это позволит NPS получать необходимые сведения об учетных записях пользователей и группах безопасности AD при обработке запросов аутентификации.

В консоли Network Policy Server (Сервер политики сети) щелкните правой кнопкой мыши по корневому узлу NPS (Local) (NPS (локальный)) и выберите Register server in Active Directory (Зарегистрировать сервер в Active Directory).

Подтвердите регистрацию сервера в появившемся окне.

В результате учетная запись компьютера NPS-сервера будет добавлена во встроенную доменную группу RAS and IAS Servers. Членство в этой группе предоставляет NPS необходимые разрешения для чтения свойств учетных записей пользователей Active Directory, используемых при обработке запросов аутентификации.

Зарегистрировать NPS-сервер в Active Directory можно и из командной строки:

netsh ras add registeredserver

Посмотреть список NPS-серверов, зарегистрированных в Active Directory, можно командой:

netsh ras show registeredserver

Создание группы пользователей для RADIUS-аутентификации

Для управления доступом через RADIUS рекомендуется создать в Active Directory отдельную группу безопасности и добавить в нее пользователей, которым будет разрешена RADIUS-аутентификация. Эту группу затем можно использовать в условиях Network Policy на сервере NPS, централизованно разрешая или запрещая пользователям доступ.

Например, если NPS будет использоваться для предоставления администраторам доступа к коммутаторам и маршрутизаторам Cisco, создадим группу безопасности RemoteCiscoUsers и добавим в нее соответствующих пользователей.

Позже эту группу мы укажем в качестве одного из условий Network Policy (Сетевой политики) на сервере NPS. В результате пройти RADIUS-аутентификацию и получить доступ к сетевому оборудованию смогут только пользователи, соответствующие условиям созданной политики.

Использование отдельной группы Active Directory значительно упрощает дальнейшее управление доступом. Чтобы предоставить пользователю возможность авторизоваться на сетевом оборудовании, достаточно добавить его учетную запись в группу RemoteCiscoUsers. Если доступ необходимо отозвать — удалить пользователя из группы.

Добавление и управление RADIUS-клиентами

Следующий этап — добавление RADIUS-клиентов. RADIUS-клиент — это сетевое устройство, которое отправляет запросы аутентификации на сервер NPS. В этой роли могут выступать маршрутизаторы, коммутаторы, точки беспроводного доступа, VPN-серверы и другое оборудование с поддержкой RADIUS.

Важно не путать RADIUS-клиента с компьютером пользователя. Например, если администратор подключается к коммутатору Cisco по SSH, именно коммутатор обращается к NPS для проверки учетных данных. Следовательно, в NPS в качестве RADIUS-клиента необходимо добавить сам коммутатор.

Добавление устройства Cisco в качестве RADIUS-клиента

Откройте консоль Network Policy Server (Сервер политики сети) и разверните:

RADIUS Clients and Servers (RADIUS-клиенты и серверы) → RADIUS Clients (RADIUS-клиенты).

Щелкните правой кнопкой мыши по RADIUS Clients (RADIUS-клиенты) и выберите New (Создать).

В окне New RADIUS Client (Новый RADIUS-клиент) необходимо указать IP-адрес устройства Cisco и Shared Secret (общий секрет), который будет использоваться для аутентификации запросов между RADIUS-клиентом и сервером NPS.

На вкладке Settings (Параметры) заполните следующие поля:

• Friendly name (Понятное имя) — удобное имя устройства, по которому его можно будет идентифицировать в NPS;
• Address (IP or DNS) (Адрес (IP или DNS)) — IP-адрес или DNS-имя сетевого устройства;
• Shared secret (Общий секрет) — общий секретный ключ, который будет использоваться для взаимодействия между устройством и NPS;
• Confirm shared secret (Подтверждение общего секрета) — повторно введите Shared Secret.

Перейдите на вкладку Advanced (Дополнительно) и в поле Vendor name (Имя поставщика) выберите Cisco.

Выбор производителя позволяет использовать специфичные для Cisco RADIUS-атрибуты. Позже, при настройке политики NPS, мы воспользуемся этим для назначения уровня привилегий пользователям на оборудовании Cisco.

Обратите особое внимание на Shared Secret. Это не пароль пользователя и не пароль администратора от сетевого устройства. Shared Secret — отдельный общий секрет, который должен быть одинаково настроен на сервере NPS и на соответствующем RADIUS-клиенте.

Если значения Shared Secret на NPS и сетевом устройстве не совпадают, сервер не сможет корректно обработать запрос аутентификации.

Для Shared Secret можно использовать два варианта:

• Manual (Вручную) — задать секрет самостоятельно;
• Generate (Создать) — автоматически сгенерировать случайное значение.

В примере в поле Friendly name (Понятное имя) указано Cisco_3360, а в качестве адреса устройства используется 192.168.0.1.

Для каждого сетевого устройства желательно использовать отдельный длинный случайно сгенерированный Shared Secret. Не рекомендуется применять один и тот же секрет на всех RADIUS-клиентах: если конфигурация одного устройства будет скомпрометирована, общий секрет остальных устройств при этом останется защищен.

Добавление RADIUS-клиента с помощью PowerShell

Добавлять RADIUS-клиентов можно не только через графическую консоль NPS, но и с помощью PowerShell. Это особенно удобно, если необходимо настроить сразу несколько сетевых устройств.

Чтобы добавить RADIUS-клиента в NPS с помощью PowerShell, используйте командлет New-NpsRadiusClient. Например:

New-NpsRadiusClient -Address "192.168.31.1" -Name "cisco2960" -SharedSecret "Zb+kp^JUy]v\ePb-h.Q*d=weya2AY?hn+npRRp[/J7d"

После добавления нового RADIUS-клиента рекомендуется перезапустить службу Network Policy Server, чтобы изменения конфигурации применились сразу:

Restart-Service IAS

Порты RADIUS и настройка Windows Firewall

Для работы RADIUS сервер NPS использует UDP-порт 1812 для аутентификации и UDP-порт 1813 для Accounting. Также NPS поддерживает устаревшие порты RADIUS 1645 и 1646:

• UDP 1812 — аутентификация;
• UDP 1813 — Accounting;
• UDP 1645 — устаревший порт аутентификации;
• UDP 1646 — устаревший порт Accounting.

При установке роли NPS необходимые правила для этих портов автоматически создаются и включаются в Windows Defender Firewall (Брандмауэр Защитника Windows).

Посмотреть созданные правила можно с помощью PowerShell:

Get-NetFirewallRule -DisplayGroup "Network Policy Server"

Если RADIUS-клиент находится в DMZ, отдельном сетевом сегменте или между устройством и NPS установлен межсетевой экран, необходимо дополнительно разрешить соответствующий UDP-трафик на промежуточном оборудовании.

Настройка политик NPS на RADIUS-сервере

После добавления RADIUS-клиентов необходимо настроить политики NPS, которые определяют, каким пользователям разрешена RADIUS-аутентификация, при каких условиях предоставляется доступ и какие параметры авторизации будут переданы сетевому устройству.

В нашем примере настроим политику для оборудования Cisco и свяжем ее с созданной ранее группой безопасности Active Directory RemoteCiscoUsers. В результате доступ через RADIUS будет предоставляться только пользователям из этой группы.

Connection Request Policy и Network Policy

В NPS используются два основных типа политик:

• Connection Request Policies (Политики запросов на подключение) — определяют, каким образом NPS должен обрабатывать поступивший RADIUS-запрос и где должна выполняться его аутентификация;
• Network Policies (Сетевые политики) — определяют, кому разрешен доступ, при каких условиях и какие параметры авторизации должны применяться.

В нашем сценарии NPS самостоятельно выполняет аутентификацию пользователей через Active Directory, поэтому отдельно настраивать Connection Request Policy (Политику запросов на подключение) нам не потребуется. Основную настройку выполним с помощью Network Policy (Сетевой политики).

Создание новой Network Policy

Чтобы создать новую Network Policy (Сетевую политику) в NPS, откройте консоль Network Policy Server (Сервер политики сети) и перейдите:

Policies (Политики) → Network Policies (Сетевые политики).

Щелкните правой кнопкой мыши по Network Policies (Сетевые политики) и выберите New (Создать).

В поле Policy name (Имя политики) задайте понятное название политики. Например:

Cisco RADIUS

Параметр Type of network access server (Тип сервера сетевого доступа) оставьте со значением Unspecified (Не определено).

Нажмите Next (Далее).

Настройка условий применения политики

На этапе Specify Conditions (Задание условий) необходимо настроить условия применения Network Policy — определить, какие пользователи смогут проходить RADIUS-аутентификацию и от каких RADIUS-клиентов NPS будет принимать запросы в рамках этой политики.

В нашем случае зададим два условия:

• пользователь должен входить в доменную группу RemoteCiscoUsers;
• запрос должен поступать от RADIUS-клиента Cisco.

Нажмите Add (Добавить) и добавьте условие Windows Groups (Группы Windows). Укажите созданную ранее группу безопасности:

RemoteCiscoUsers

Затем добавьте условие Client Friendly Name (Понятное имя клиента) и укажите:

Cisco_*

Маска Cisco_* позволяет одной политикой обрабатывать запросы сразу от нескольких RADIUS-клиентов, если их Friendly name (Понятное имя) начинается с Cisco_. Например, это могут быть Cisco_SW01, Cisco_SW02, Cisco_Router01 и т. д.

Нажмите Next (Далее).

Предоставление доступа

На странице Specify Access Permission (Указание разрешения доступа) выберите:

Access granted (Доступ разрешен).

Параметр Access granted (Доступ разрешен) разрешает RADIUS-аутентификацию пользователям, которые соответствуют всем условиям созданной Network Policy. В нашем примере доступ получат пользователи из группы RemoteCiscoUsers, если запрос поступил от соответствующего RADIUS-клиента Cisco.

Нажмите Next (Далее).

Выбор методов аутентификации

На следующем этапе необходимо выбрать методы аутентификации NPS, которые будут разрешены для созданной Network Policy. Выбор метода зависит от возможностей RADIUS-клиента и требований к безопасности.

Некоторое устаревшее сетевое оборудование может поддерживать только PAP или SPAP. Однако эти протоколы обеспечивают слабую защиту учетных данных и по возможности использовать их не следует.

В современной инфраструктуре предпочтительнее применять PEAP, EAP-TLS или MS-CHAP v2, если соответствующий сценарий и сетевое оборудование поддерживают эти методы.

Если использование PAP или SPAP необходимо для совместимости со старым оборудованием, RADIUS-трафик следует передавать только внутри доверенных и изолированных управляющих сетей.

После выбора необходимых методов нажмите Next (Далее).

Этап Configure Constraints (Настройка ограничений) в нашем примере можно оставить без изменений и перейти далее.

Настройка стандартных RADIUS-атрибутов

На странице Configure Settings (Настройка параметров) перейдите:

RADIUS Attributes (Атрибуты RADIUS) → Standard (Стандартные).

Удалите имеющиеся там атрибуты, если они были добавлены мастером автоматически, и нажмите Add (Добавить).

Выберите:

Access type (Тип доступа) → All (Все),

затем добавьте атрибут Service-Type и установите для него значение:

Others (Другие) → Login.

RADIUS-атрибут Service-Type = Login сообщает сетевому устройству, что после успешной аутентификации через NPS пользователю необходимо предоставить интерактивный доступ к устройству.

Настройка Cisco Vendor-Specific Attribute

Чтобы назначить пользователю уровень привилегий на оборудовании Cisco после успешной RADIUS-аутентификации, в Network Policy необходимо настроить Cisco Vendor-Specific Attribute (VSA).

Перейдите:

RADIUS Attributes (Атрибуты RADIUS) → Vendor Specific (Атрибуты поставщика).

Нажмите Add (Добавить) и выберите производителя Cisco.

Добавьте атрибут Cisco и укажите значение:

shell:priv-lvl=15

Значение priv-lvl=15 предоставляет успешно авторизованному пользователю максимальный уровень привилегий Cisco IOS. Фактически пользователь после входа получает административный доступ к устройству.

После завершения настройки мастер покажет итоговые параметры созданной политики. Проверьте их и нажмите Finish (Готово).

Порядок обработки политик NPS

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

Поэтому более специфичные политики обычно следует располагать выше более общих.

Порядок можно изменить непосредственно в консоли NPS с помощью значения Processing Order (Порядок обработки).

Неправильный порядок политик — одна из причин ситуаций, когда пользователь вводит правильные учетные данные и входит в нужную группу Active Directory, но NPS все равно отклоняет запрос или применяет не те параметры доступа.

Проверка разрешений пользователя в Active Directory

Если NPS отклоняет RADIUS-аутентификацию доменного пользователя, проверьте параметр Network Access Permission (Разрешение сетевого доступа) в свойствах его учетной записи Active Directory.

Откройте Active Directory Users and Computers (Пользователи и компьютеры Active Directory) командой:

dsa.msc

Откройте свойства нужного пользователя и перейдите на вкладку Dial-in (Входящие звонки).

В разделе Network Access Permission (Разрешение сетевого доступа) рекомендуется использовать:

Control access through NPS Network Policy (Управление доступом через сетевую политику NPS).

В этом случае решение о предоставлении или запрете доступа принимает настроенная нами Network Policy, а не индивидуальное разрешение в свойствах пользователя.

Если для учетной записи явно установлено Deny access (Запретить доступ), это необходимо учитывать при диагностике отказов RADIUS-аутентификации.

На этом основная настройка политики NPS для оборудования Cisco завершена. Сервер знает, от каких RADIUS-клиентов принимать запросы, какие пользователи могут пройти аутентификацию и какой уровень привилегий передать устройству Cisco.

Следующий этап — настроить сам коммутатор или маршрутизатор Cisco для работы с нашим RADIUS-сервером.

Настройка RADIUS-аутентификации Cisco через NPS

После настройки RADIUS-клиента и Network Policy на сервере NPS необходимо настроить RADIUS-аутентификацию на маршрутизаторе или коммутаторе Cisco. Устройство будет передавать учетные данные администратора на сервер NPS для проверки через RADIUS, а при недоступности RADIUS-сервера позволит выполнить вход с помощью резервной локальной учетной записи.

Настройка безопасного доступа по SSH

Для безопасного удаленного администрирования оборудования Cisco следует использовать SSH. В отличие от SSH, протокол Telnet передает данные, включая учетные данные пользователя, по сети без шифрования, поэтому использовать его для административного доступа не рекомендуется.

Перейдите в режим конфигурации Cisco и выполните следующие команды:

configure terminal
crypto key generate rsa modulus 2048
ip ssh version 2
ip ssh time-out 60
ip ssh authentication-retries 3

Команды создают RSA-ключ длиной 2048 бит, включают SSH версии 2, задают тайм-аут подключения 60 секунд и ограничивают количество попыток аутентификации тремя.

Перед включением RADIUS-аутентификации на Cisco обязательно создайте локальную учетную запись администратора для резервного доступа. Она позволит войти на устройство, если сервер NPS, Active Directory или сетевое соединение с RADIUS-сервером окажется недоступно:

username cisco_local algorithm-type scrypt secret VeryStrongLocalPassword

Вместо VeryStrongLocalPassword укажите собственный сложный пароль.

Теперь запретим подключения по Telnet и разрешим удаленный доступ только по SSH:

line vty 5 15
login authentication default
transport input ssh

Проверка связи с RADIUS-сервером

Перед проверкой пользовательской аутентификации необходимо убедиться, что устройство Cisco может обращаться к RADIUS-серверу NPS. После настройки RADIUS на Cisco для проверки аутентификации рекомендуется отправить реальный AAA-запрос на сервер NPS.

После настройки группы RADIUS-серверов проверить AAA-аутентификацию непосредственно с Cisco можно командой:

test aaa group radius_srv_group username password legacy

Вместо username и password укажите тестовую учетную запись Active Directory, которой разрешен доступ через созданную ранее политику NPS.

При успешной проверке устройство должно получить от RADIUS-сервера положительный ответ на запрос аутентификации.

Для полноценной проверки лучше отправить реальный RADIUS-запрос с сетевого устройства, а при возникновении проблем проверить события NPS и прохождение UDP-трафика между устройством и сервером. Диагностику RADIUS мы подробно рассмотрим далее в статье.

Пример настройки RADIUS на Cisco Catalyst

Рассмотрим пример настройки RADIUS-аутентификации на Cisco Catalyst через NPS в Windows Server. В этой конфигурации администраторы будут проходить аутентификацию через RADIUS-сервер NPS, а при его недоступности Cisco сможет использовать локальную учетную запись.

Сначала включим механизм AAA (Authentication, Authorization and Accounting):

aaa new-model
enable algorithm-type scrypt secret VeryStrongEnablePassword

Теперь добавим RADIUS-сервер NPS в конфигурацию Cisco. В нашем примере сервер NPS имеет IP-адрес 192.168.1.16 и использует стандартные UDP-порты RADIUS 1812 для аутентификации и 1813 для Accounting:

radius server NPS01
 address ipv4 192.168.1.16 auth-port 1812 acct-port 1813
 key VeryStrongSharedSecretHere
 timeout 5
 retransmit 3

Здесь:

• NPS01 — произвольное имя RADIUS-сервера в конфигурации Cisco;
• 192.168.1.16 — IP-адрес сервера NPS;
• auth-port 1812 — UDP-порт аутентификации;
• acct-port 1813 — UDP-порт Accounting;
• key — Shared Secret, который должен полностью совпадать со значением, указанным для этого устройства в NPS;
• timeout 5 — время ожидания ответа RADIUS-сервера;
• retransmit 3 — количество повторных попыток отправки запроса.

Создадим на Cisco группу RADIUS-серверов и добавим в нее настроенный сервер NPS. Использование группы позволяет централизованно обращаться к RADIUS-серверам и при необходимости добавить второй NPS-сервер для резервирования:

aaa group server radius radius_srv_group
 server name NPS01
 radius-server deadtime 10

Настроим AAA-аутентификацию на Cisco через RADIUS с резервным входом по локальной учетной записи. Сначала устройство будет отправлять запрос на сервер NPS из группы radius_srv_group, а если RADIUS-сервер окажется недоступен — использовать локальную базу пользователей:

aaa authentication login default group radius_srv_group local
aaa authentication enable default group radius_srv_group local

Ключевое слово local здесь особенно важно: оно обеспечивает резервный вариант входа при недоступности RADIUS.

После настройки аутентификации включим AAA-авторизацию на Cisco через RADIUS для пользовательской EXEC-сессии и команд с уровнем привилегий 15. Если RADIUS-сервер окажется недоступен, для авторизации будет использоваться локальная база устройства:

aaa authorization exec default group radius_srv_group local
aaa authorization commands 15 default group radius_srv_group local

Включим RADIUS Accounting на Cisco, чтобы устройство отправляло на сервер NPS информацию о начале и завершении пользовательских EXEC-сессий, а также о выполняемых командах:

aaa accounting exec default start-stop group radius_srv_group
aaa accounting commands 1 default start-stop group radius_srv_group
aaa accounting commands 15 default start-stop group radius_srv_group

Если на устройстве Cisco настроено несколько интерфейсов, рекомендуется явно указать исходный интерфейс для RADIUS-запросов с помощью команды ip radius source-interface:

ip radius source-interface vlan 10

Это важный параметр. IP-адрес указанного интерфейса должен соответствовать адресу RADIUS-клиента, который мы ранее добавили в NPS. Если запрос придет с другого IP-адреса, NPS может не распознать устройство как настроенный RADIUS-клиент.

Настройка нескольких RADIUS-серверов

Для отказоустойчивости RADIUS-аутентификации на Cisco можно настроить два NPS-сервера — основной и резервный. Оба RADIUS-сервера добавляются в одну группу radius_srv_group:

aaa group server radius radius_srv_group
 server 192.168.1.16
 server 192.168.101.16

При такой схеме устройство сможет использовать резервный RADIUS-сервер, если основной станет недоступен.

Для проверки RADIUS-аутентификации Cisco через NPS подключитесь к устройству по SSH с доменной учетной записью пользователя из группы RemoteCiscoUsers. При успешной аутентификации сервер NPS применит созданную Network Policy и передаст устройству Cisco настроенный RADIUS-атрибут:

shell:priv-lvl=15

В результате пользователь получит соответствующий уровень административных привилегий.

Настройка RADIUS-аутентификации MikroTik через NPS

Network Policy Server (NPS) можно использовать как RADIUS-сервер для аутентификации пользователей VPN на маршрутизаторе MikroTik. В такой конфигурации пользователи подключаются к VPN с помощью своих доменных учетных записей Active Directory, MikroTik передает учетные данные по RADIUS на сервер NPS, а NPS проверяет пользователя в Active Directory и применяет соответствующую Network Policy.

Добавление MikroTik в качестве RADIUS-клиента

Чтобы сервер NPS принимал RADIUS-запросы от маршрутизатора MikroTik, необходимо добавить MikroTik в NPS в качестве RADIUS-клиента и указать его IP-адрес и Shared Secret.

Откройте консоль Network Policy Server (Сервер политики сети) командой:

nps.msc

Перейдите:

RADIUS Clients and Servers (RADIUS-клиенты и серверы) → RADIUS Clients (RADIUS-клиенты).

Щелкните правой кнопкой мыши по RADIUS Clients (RADIUS-клиенты) и выберите New (Создать).

В окне New RADIUS Client (Новый RADIUS-клиент) укажите:

• включите Enable this RADIUS client (Включить этот RADIUS-клиент);
• Friendly name (Понятное имя) — укажите удобное имя маршрутизатора MikroTik;
• Address (IP or DNS) (Адрес (IP или DNS)) — укажите IP-адрес MikroTik;
• Shared secret (Общий секрет) — задайте Shared Secret, который затем необходимо будет указать в RouterOS.

Как и в случае с Cisco, IP-адрес должен соответствовать адресу, с которого MikroTik фактически будет отправлять RADIUS-запросы. Shared Secret также должен полностью совпадать на обеих сторонах.

Создание Network Policy для пользователей MikroTik

Для RADIUS-аутентификации пользователей VPN на MikroTik создайте в NPS отдельную Network Policy (Сетевую политику). Она будет определять, каким пользователям Active Directory разрешено подключаться к VPN через маршрутизатор MikroTik.

В условиях политики укажите группу безопасности AD, содержащую пользователей, которым разрешено VPN-подключение.

Например, для этого можно создать отдельную группу:

MikroTik-VPN-Users

Далее настройте следующие параметры политики:

• User Groups (Группы пользователей) — группа Active Directory, пользователям которой разрешено подключение;
• Authentication Type (Тип аутентификации) — MS-CHAP v2;
• Tunnel Type (Тип туннеля) — Point-to-Point Tunneling Protocol (PPTP);
• Access Permission (Разрешение доступа) — Access granted (Доступ разрешен).

В разделе Configure Authentication Methods (Настройка методов аутентификации) оставьте только Microsoft Encrypted Authentication version 2 (MS-CHAP-v2).

При необходимости можно также включить параметр User can change password after it has expired (Пользователь может изменить пароль после истечения срока его действия).

Для Multilink and Bandwidth Allocation Protocol (BAP) установите запрет Multilink-подключений.

В разделе стандартных RADIUS-атрибутов удалите Service-Type = Framed и оставьте:

Framed-Protocol = PPP

В параметрах шифрования оставьте наиболее стойкий из доступных для этого устаревшего сценария вариант:

Strongest encryption (MPPE 128-bit).

Проверка портов RADIUS на NPS

Для RADIUS-аутентификации MikroTik через NPS используются стандартные порты: UDP 1812 для аутентификации и UDP 1813 для Accounting. После создания политики откройте свойства Network Policy Server (Сервер политики сети) и убедитесь, что сервер NPS использует эти порты:

• Authentication (Аутентификация) — UDP 1812;
• Accounting (Учет) — UDP 1813.

Также убедитесь, что входящий трафик на эти UDP-порты разрешен в Microsoft Defender Firewall (Брандмауэр Microsoft Defender) и на промежуточных межсетевых экранах между MikroTik и сервером NPS.

Настройка RADIUS на MikroTik RouterOS

Теперь настроим RADIUS-аутентификацию на MikroTik RouterOS через сервер NPS. Маршрутизатор будет передавать учетные данные пользователей VPN на NPS для проверки через Active Directory.

Предполагается, что PPP/VPN-сервер на MikroTik уже настроен. Поскольку в примере используется PPTP, сначала откройте параметры PPTP-сервера и убедитесь, что в качестве метода аутентификации разрешен только:

mschap2

Еще раз подчеркну: данная конфигурация PPTP приведена только для демонстрации работы RADIUS и совместимости с существующими системами. Для нового VPN-развертывания PPTP использовать не следует.

Теперь добавим сервер NPS в конфигурацию RouterOS.

Откройте раздел RADIUS и выберите New RADIUS Server (Новый RADIUS-сервер).

Укажите следующие параметры:

• Service (Служба) — ppp;
• Address (Адрес) — IP-адрес сервера NPS;
• Secret (Секрет) — тот же Shared Secret, который был указан при создании MikroTik как RADIUS-клиента в NPS;
• Src. Address (Исходный адрес) — IP-адрес MikroTik, с которого будут отправляться RADIUS-запросы;
• Authentication Port (Порт аутентификации) — 1812;
• Accounting Port (Порт учета) — 1813.

На параметр Src. Address (Исходный адрес) стоит обратить особое внимание. Этот адрес должен совпадать с IP-адресом, который мы указали для MikroTik при создании RADIUS-клиента на сервере NPS.

Если маршрутизатор отправит запрос с другого интерфейса и, соответственно, другого IP-адреса, NPS может не распознать его как зарегистрированный RADIUS-клиент.

При необходимости добавьте соответствующие разрешающие правила в Firewall MikroTik для обмена трафиком с сервером NPS.

Включение RADIUS-аутентификации для PPP

Чтобы использовать NPS для RADIUS-аутентификации VPN-пользователей на MikroTik, необходимо включить использование RADIUS для PPP-подключений:

Перейдите в настройки PPP → Secrets → PPP Authentication & Accounting и включите параметр:

Use RADIUS (Использовать RADIUS).

После этого MikroTik будет отправлять данные пользователей, подключающихся к VPN, на сервер NPS.

Пользователь сможет указать свою доменную учетную запись Active Directory при создании VPN-подключения. Для успешной аутентификации его учетная запись должна входить в группу AD, которую мы указали в условиях соответствующей Network Policy (Сетевой политики) на сервере NPS.

Таким образом, управление доступом к VPN можно централизовать через Active Directory: для предоставления пользователю доступа достаточно добавить его в соответствующую группу безопасности, а для отзыва — удалить из нее.

Настройка Wi-Fi 802.1X через RADIUS-сервер NPS

Network Policy Server (NPS) можно использовать в качестве RADIUS-сервера для настройки корпоративной Wi-Fi-сети с аутентификацией IEEE 802.1X. В такой конфигурации пользователи и компьютеры проходят индивидуальную аутентификацию через RADIUS вместо использования общего пароля Wi-Fi.

В доменной инфраструктуре NPS позволяет использовать учетные записи и группы Active Directory для централизованного управления доступом пользователей и компьютеров к корпоративной беспроводной сети.

Схема подключения выглядит следующим образом:

Windows-клиент → точка доступа Wi-Fi → RADIUS/NPS → Active Directory

При этом точка доступа выступает в роли RADIUS-клиента: она принимает запрос на подключение от устройства и передает запрос аутентификации серверу NPS.

Настройка NPS для Wi-Fi-аутентификации

Чтобы настроить NPS как RADIUS-сервер для Wi-Fi 802.1X, откройте консоль Network Policy Server (Сервер политики сети) и запустите мастер настройки подключений 802.1X.

На стартовой странице в разделе Standard Configuration (Стандартная конфигурация) выберите:

RADIUS server for 802.1X Wireless or Wired Connections (RADIUS-сервер для беспроводных или проводных подключений 802.1X).

Нажмите Configure 802.1X (Настроить 802.1X), чтобы запустить мастер настройки.

В мастере выберите тип подключения:

Secure Wireless Connections (Безопасные беспроводные подключения).

Далее необходимо добавить беспроводные точки доступа, которые будут обращаться к серверу NPS.

Для каждой точки доступа укажите:

• Friendly name (Понятное имя) — удобное имя точки доступа;
• Address (IP or DNS) (Адрес (IP или DNS)) — IP-адрес или DNS-имя устройства;
• Shared Secret (Общий секрет) — общий секрет RADIUS.

Shared Secret должен полностью совпадать в настройках NPS и точки доступа.

Если в беспроводной инфраструктуре используется централизованный Wi-Fi-контроллер и именно он отправляет RADIUS-запросы на NPS, в качестве RADIUS-клиента необходимо зарегистрировать адрес контроллера.

Выбор метода аутентификации PEAP

На следующем этапе выберите метод аутентификации:

Microsoft: Protected EAP (PEAP).

PEAP (Protected EAP) создает защищенный TLS-туннель между клиентским устройством и сервером NPS, внутри которого выполняется аутентификация пользователя. Для работы PEAP серверу NPS необходим действующий сертификат, которому доверяют клиентские устройства.

Нажмите Configure (Настроить) и выберите сертификат, который NPS будет использовать для подтверждения своей подлинности перед клиентами.

Сертификат должен быть действующим, доверенным клиентскими компьютерами и содержать назначение:

Server Authentication (Проверка подлинности сервера)

в Enhanced Key Usage — EKU (Расширенное использование ключа).

Проверить сертификаты в личном хранилище локального компьютера можно с помощью PowerShell:

Get-ChildItem Cert:\LocalMachine\My

Если сертификат выпущен корпоративным центром сертификации, клиентские устройства должны доверять соответствующему корневому CA.

В инфраструктуре с повышенными требованиями к безопасности вместо PEAP можно использовать EAP-TLS, обеспечивающий сертификатную аутентификацию клиента и сервера.

Настройка Network Policy для Wi-Fi

После завершения мастера NPS автоматически создаст две политики:

• Connection Request Policy (Политика запросов на подключение);
• Network Policy (Сетевая политика).

Чтобы ограничить доступ к корпоративной Wi-Fi-сети определенными пользователями, откройте созданную Network Policy (Сетевую политику) и на вкладке Conditions (Условия) укажите группу безопасности Active Directory, которой разрешена RADIUS-аутентификация через NPS.

Например:

WiFi-Users

Также проверьте параметр NAS Port Type (Тип порта NAS). Для беспроводных подключений должно использоваться:

Wireless – Other (Беспроводная сеть — другое)

или:

Wireless – IEEE 802.11.

Таким образом, политика будет применяться только к соответствующим пользователям и беспроводным RADIUS-подключениям.

Настройка точек доступа и клиентских компьютеров

Чтобы использовать NPS для аутентификации Wi-Fi 802.1X, настройте беспроводные точки доступа или Wi-Fi-контроллер на работу с NPS в качестве RADIUS-сервера.

В параметрах корпоративной беспроводной сети необходимо указать:

• IP-адрес NPS-сервера;
• UDP-порт аутентификации 1812;
• при использовании Accounting — UDP-порт 1813;
• Shared Secret, совпадающий со значением в настройках соответствующего RADIUS-клиента NPS.

После этого параметры корпоративного Wi-Fi можно централизованно развернуть на доменные Windows-компьютеры с помощью групповой политики.

Развертывание Wi-Fi-профиля через Group Policy

Откройте Group Policy Management (Управление групповой политикой) и создайте новую GPO либо используйте существующую политику, применяемую к нужным компьютерам.

Перейдите:

Computer Configuration (Конфигурация компьютера) → Policies (Политики) → Windows Settings (Параметры Windows) → Security Settings (Параметры безопасности) → Wireless Network (IEEE 802.11) Policies (Политики беспроводной сети (IEEE 802.11)).

Выберите:

Create A New Wireless Network Policy for Windows Vista and Later (Создать новую политику беспроводной сети для Windows Vista и более поздних версий).

В параметрах созданной политики добавьте корпоративную беспроводную сеть.

Укажите:

• Profile Name (Имя профиля) — имя профиля беспроводной сети;
• Network Name (SSID) (Имя сети (SSID)) — SSID корпоративной Wi-Fi-сети.

Также включите:

Connect automatically when this network is in range (Подключаться автоматически, если сеть находится в радиусе действия).

Настройка безопасности корпоративного Wi-Fi

Для настройки аутентификации Wi-Fi 802.1X через NPS откройте вкладку Security (Безопасность) созданного беспроводного профиля GPO и укажите параметры безопасности корпоративной Wi-Fi-сети:

• Authentication (Проверка подлинности) — WPA2-Enterprise;
• Encryption (Шифрование) — AES-CCMP;
• Network authentication method (Метод проверки подлинности сети) — Microsoft: Protected EAP (PEAP);
• Authentication mode (Режим проверки подлинности) — User or computer authentication (Проверка подлинности пользователя или компьютера).

Режим User or computer authentication (Проверка подлинности пользователя или компьютера) позволяет выполнять аутентификацию с использованием учетной записи пользователя или компьютера в зависимости от текущего состояния Windows и настроенной политики.

Нажмите Properties (Свойства) рядом с методом PEAP.

В параметрах Protected EAP Properties (Свойства защищенного EAP) включите проверку сертификата сервера и выберите доверенный корневой центр сертификации, которым был выпущен сертификат NPS.

Проверка сертификата позволяет клиентскому компьютеру удостовериться, что он подключается именно к доверенному корпоративному NPS-серверу.

Поэтому отключать проверку сертификата ради устранения проблем с подключением не рекомендуется.

Включение Single Sign-On

В дополнительных параметрах беспроводного профиля включите:

Enable Single Sign On for this network (Включить единый вход для этой сети).

Single Sign-On (SSO) позволяет использовать учетные данные доменного пользователя, введенные при входе в Windows, для автоматической аутентификации в корпоративной Wi-Fi-сети через 802.1X и NPS. Пользователю не потребуется повторно вводить логин и пароль при подключении к беспроводной сети.

После применения групповой политики профиль Wi-Fi автоматически появится на целевых доменных компьютерах. Windows сможет подключаться к корпоративной беспроводной сети с использованием настроенной 802.1X-аутентификации.

В результате схема доступа выглядит следующим образом:

Windows-клиент → точка доступа или Wi-Fi-контроллер → NPS → Active Directory

NPS проверяет пользователя или компьютер, применяет соответствующую Network Policy и возвращает RADIUS-клиенту решение о предоставлении доступа.

Диагностика ошибок RADIUS и событий NPS

Если RADIUS-аутентификация через NPS не работает, диагностику следует начинать с журнала событий Windows на сервере NPS. В нем можно найти успешные и неудачные попытки RADIUS-аутентификации, имя пользователя, RADIUS-клиента, примененную Network Policy и причину, по которой NPS разрешил или отклонил доступ.

Кратко: что проверить, если RADIUS/NPS не работает:

• Event ID 6273 — посмотреть причину отклонения запроса и Reason Code;
• RADIUS-клиент — проверить IP-адрес устройства и совпадение Shared Secret;
• Network Policy — проверить условия политики, группу Active Directory и порядок обработки;
• UDP 1812 — убедиться, что RADIUS-трафик не блокируется Windows Firewall или промежуточным межсетевым экраном;
• метод аутентификации — проверить, что клиент и политика NPS используют совместимый метод.

Но прежде чем искать события, необходимо убедиться, что на сервере включен аудит Network Policy Server.

Включение аудита NPS

Откройте редактор локальной групповой политики:

gpedit.msc

Перейдите:

Computer Configuration (Конфигурация компьютера) → Windows Settings (Параметры Windows) → Security Settings (Параметры безопасности) → Advanced Audit Policy Configuration (Расширенная конфигурация политики аудита) → Audit Policies (Политики аудита) → Logon/Logoff (Вход/выход) → Audit Network Policy Server (Аудит сервера сетевой политики).

Откройте параметр Audit Network Policy Server (Аудит сервера сетевой политики) и включите аудит:

• Configure the following audit events (Настроить следующие события аудита);
• Success (Успех);
• Failure (Отказ).

После включения аудита Network Policy Server (NPS) Windows будет записывать в журнал Security (Безопасность) события успешной и неудачной RADIUS-аутентификации. Эти события можно использовать для диагностики отказов доступа и проверки работы политик NPS.

Просмотр событий RADIUS в Event Viewer

Откройте Event Viewer (Просмотр событий):

eventvwr.msc

Перейдите:

Windows Logs (Журналы Windows) → Security (Безопасность).

Чтобы найти успешные RADIUS-аутентификации через NPS, отфильтруйте журнал Security (Безопасность) по идентификатору события 6272.

Event ID 6272 означает, что Network Policy Server успешно проверил запрос и разрешил пользователю доступ:

Network Policy Server granted access to a user.

В свойствах события содержится подробная информация о запросе: учетная запись пользователя, RADIUS-клиент, IP-адрес устройства, примененная Network Policy, метод аутентификации и другие параметры. Эти данные особенно полезны при диагностике, когда на одном NPS-сервере обслуживается сразу несколько сетевых устройств.

Основные события NPS: 6272, 6273 и 6279

При диагностике RADIUS-аутентификации чаще всего встречаются следующие события.

Event ID 6272 — доступ разрешен:

Network Policy Server granted access to a user.

Это означает, что запрос пользователя успешно прошел проверку NPS и сервер разрешил подключение.

Event ID 6273 означает, что сервер NPS отклонил запрос RADIUS-аутентификации. При диагностике ошибки в первую очередь проверьте Reason Code (Код причины) и текстовое описание отказа — они позволяют определить, почему NPS не разрешил пользователю доступ.

Например, при неправильном имени пользователя или пароле в событии может быть указано:

Authentication failed due to a user credentials mismatch.

Но правильный пароль еще не гарантирует успешную авторизацию. NPS также может отклонить запрос из-за условий созданной Network Policy (Сетевой политики).

Например, пользователь может не входить в необходимую группу безопасности Active Directory.

Также следует проверить свойства учетной записи пользователя в:

Active Directory Users and Computers (Пользователи и компьютеры Active Directory) → Dial-in (Входящие звонки) → Network Access Permission (Разрешение сетевого доступа).

Если там явно установлено Deny access (Запретить доступ), NPS может зарегистрировать сообщение:

The Network Access Permission setting in the dial-in properties of the user account in Active Directory is set to Deny access...

В большинстве сценариев, где доступом управляют политики NPS, здесь должно использоваться:

Control access through NPS Network Policy (Управление доступом через сетевую политику NPS).

Блокировка учетной записи при ошибках аутентификации

Если при RADIUS-аутентификации через NPS многократно передается неправильный пароль, доменная учетная запись пользователя может быть заблокирована в соответствии с настроенной в Active Directory политикой блокировки учетных записей.

В контексте NPS при повторяющихся неудачных попытках аутентификации может регистрироваться событие:

Event ID 6279

с сообщением:

Network Policy Server locked the user account due to repeated failed authentication attempts.

При этом важно понимать, что фактическая блокировка доменной учетной записи выполняется контроллером домена. На контроллере домена блокировка учетной записи регистрируется в журнале Security (Безопасность) как событие:

Event ID 4740

Поэтому при расследовании постоянных блокировок пользователя имеет смысл проверять не только журнал NPS, но и события 4740 на контроллерах домена.

Поиск успешных RADIUS-подключений пользователя через PowerShell

Чтобы найти успешные RADIUS-подключения конкретного пользователя через NPS, можно использовать PowerShell и отфильтровать в журнале Security события с идентификатором 6272. Это особенно удобно, если сервер NPS обрабатывает большое количество запросов.

В оригинальном примере используется PowerShell-скрипт, который выбирает из журнала Security события 6272 для конкретного пользователя и группирует их по IP-адресам.

Например, для пользователя pavel.lunin:

$Query = @"
<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
      *[
        EventData[
          Data[@Name='SubjectUserName']='pavel.lunin'
        ]
      ]
      and
      *[
        System[
          (EventID='6272')
        ]
      ]
    </Select>
  </Query>
</QueryList>
"@

$events = Get-WinEvent -FilterXML $Query

$ipaddr = @{
    Label = "IP"
    Expression = { $_.Properties[9].Value }
}

$events |
    Select-Object $ipaddr |
    Group-Object IP |
    Format-Table Count, Name -AutoSize

Замените pavel.lunin на имя нужной учетной записи.

Скрипт выбирает успешные события NPS с идентификатором 6272, извлекает IP-адрес и группирует результаты. Это позволяет быстро определить, с каких адресов выполнялась успешная RADIUS-аутентификация конкретного пользователя.

Что проверять при проблемах с RADIUS

Если RADIUS-аутентификация через NPS не работает, помимо событий в журнале Security необходимо проверить несколько типичных причин: синхронизацию времени, Shared Secret, IP-адрес RADIUS-клиента, сертификат NPS, условия Network Policy и доступность UDP-портов 1812/1813.

1. Синхронизация времени. Рассинхронизация времени между сервером, клиентами и другими компонентами инфраструктуры может приводить к проблемам с PEAP и EAP-TLS.

   На Windows Server состояние службы времени можно проверить командой:

   
   w32tm /query /status
   
   

2. Shared Secret. Значение Shared Secret должно полностью совпадать в настройках RADIUS-клиента на NPS и на сетевом устройстве.
3. IP-адрес RADIUS-клиента. Проверьте, что устройство действительно отправляет запросы с IP-адреса, который зарегистрирован в NPS.
4. Сертификат NPS. При использовании PEAP или EAP-TLS сертификат должен быть действующим, доверенным клиентами и содержать Server Authentication (Проверка подлинности сервера) в EKU.
5. Network Policy. Проверьте членство пользователя в требуемой группе Active Directory, разрешенные методы аутентификации, дополнительные условия политики и Processing Order (Порядок обработки) политик NPS.
6. Network Access Permission. Убедитесь, что в свойствах пользователя Active Directory не установлен явный Deny access (Запретить доступ).
7. UDP 1812/1813. Проверьте прохождение RADIUS-трафика между сетевым устройством и NPS через локальные и промежуточные межсетевые экраны.

При возникновении отказа лучше начинать именно с события 6273 и указанного в нем Reason Code (Кода причины). Это позволяет не перебирать настройки вслепую, а сразу понять, на каком этапе NPS отклонил запрос.

Рекомендации по безопасности RADIUS

Для безопасной эксплуатации RADIUS-сервера NPS следует использовать уникальные Shared Secret для каждого RADIUS-клиента, ограничивать доступ к UDP-портам 1812 и 1813, управлять доступом через отдельные группы Active Directory и Network Policy, а для 802.1X по возможности использовать современные методы аутентификации PEAP или EAP-TLS.

Используйте уникальные Shared Secret. Для каждого RADIUS-клиента желательно задавать отдельный длинный случайно сгенерированный Shared Secret. Не следует использовать один и тот же секрет для всех коммутаторов, маршрутизаторов, VPN-серверов и точек доступа. В случае компрометации одного устройства это позволит ограничить последствия только конкретным RADIUS-клиентом.

Ограничивайте доступ к NPS по сети. UDP-порты 1812 и 1813 на сервере NPS должны быть доступны только с IP-адресов доверенных RADIUS-клиентов. Не разрешайте обращения к RADIUS-серверу из пользовательских сегментов сети и не публикуйте порты RADIUS непосредственно в Интернет.

Если между сетевым оборудованием и NPS установлены межсетевые экраны, разрешайте RADIUS-трафик только между конкретными IP-адресами устройств и серверов NPS.

Разделяйте доступ к RADIUS с помощью групп Active Directory. Вместо предоставления доступа всем доменным пользователям создавайте отдельные группы безопасности AD для разных сценариев RADIUS-аутентификации и используйте их в условиях Network Policy. Например:

Network-Admins — административный доступ к сетевому оборудованию;

VPN-Users — удаленное VPN-подключение;

WiFi-Users — доступ к корпоративной беспроводной сети.

Эти группы можно использовать в условиях Network Policy (Сетевой политики) и централизованно управлять доступом непосредственно через Active Directory.

Не предоставляйте максимальные привилегии без необходимости. В нашем примере для Cisco использовался атрибут:

shell:priv-lvl=15

Он предоставляет максимальный уровень привилегий Cisco IOS. В реальной инфраструктуре такой доступ следует назначать только администраторам, которым он действительно необходим.

Для разных уровней доступа лучше использовать отдельные группы Active Directory и политики NPS.

Используйте современные методы RADIUS-аутентификации. По возможности следует отказаться от устаревших механизмов, таких как PAP, SPAP и PPTP, и использовать более защищенные методы аутентификации, поддерживаемые NPS, например PEAP или EAP-TLS.

Для корпоративных сетей 802.1X можно использовать PEAP с обязательной проверкой сертификата NPS. В инфраструктуре с более высокими требованиями к безопасности предпочтительнее использовать EAP-TLS, где аутентификация выполняется с использованием сертификатов.

Контролируйте сертификаты NPS. При использовании PEAP или EAP-TLS сертификат сервера NPS должен быть действующим, доверенным клиентскими устройствами, иметь корректную цепочку сертификации и содержать назначение Server Authentication (Проверка подлинности сервера) в Enhanced Key Usage (EKU).

Истечение срока действия сертификата NPS может привести сразу к массовым проблемам с подключением пользователей к Wi-Fi или другим сервисам, использующим 802.1X.

Не отключайте проверку сертификата NPS на клиентах. Иногда при проблемах с PEAP проверку сертификата сервера отключают, чтобы быстро восстановить подключение. Для постоянной конфигурации такой вариант использовать не следует.

Проверка сертификата позволяет клиентскому устройству убедиться, что оно действительно подключается к доверенному корпоративному RADIUS-серверу, прежде чем передавать ему учетные данные.

Используйте резервирование NPS. Если через RADIUS выполняется аутентификация администраторов сетевого оборудования, пользователей VPN или корпоративной Wi-Fi-сети, рекомендуется использовать несколько серверов NPS, чтобы отказ одного RADIUS-сервера не привел к потере доступа пользователей и администраторов.

Для критичной инфраструктуры рекомендуется использовать как минимум два NPS-сервера и указывать их на сетевом оборудовании в качестве основного и резервного RADIUS-серверов.

При этом конфигурация политик и RADIUS-клиентов на обоих NPS должна поддерживаться в актуальном состоянии.

Сохраняйте резервную локальную учетную запись администратора. После перехода на RADIUS-аутентификацию через NPS не удаляйте локальные административные учетные записи на маршрутизаторах и коммутаторах — они необходимы для аварийного доступа при недоступности RADIUS.

Если NPS, Active Directory или сеть между ними окажутся недоступны, локальная учетная запись позволит получить аварийный доступ к устройству и восстановить работу инфраструктуры.

Контролируйте события NPS. Регулярно проверяйте события успешной и неудачной RADIUS-аутентификации в журнале Security. Большое количество событий 6273, повторяющиеся ошибки аутентификации одного пользователя или многочисленные запросы от одного RADIUS-клиента могут указывать на ошибку конфигурации или попытки несанкционированного доступа.

Для критичной инфраструктуры события NPS имеет смысл централизованно собирать в SIEM или другую систему мониторинга безопасности.

Таким образом, NPS не стоит рассматривать только как сервер проверки логина и пароля. В правильно построенной инфраструктуре RADIUS становится единой точкой управления сетевым доступом, поэтому к его отказоустойчивости, защите и контролю событий следует относиться так же внимательно, как к другим критичным компонентам Active Directory.

Часто задаваемые вопросы (FAQ)

Заключение

Network Policy Server позволяет развернуть полноценный RADIUS-сервер средствами Windows Server и связать аутентификацию сетевых устройств и сервисов с Active Directory. В результате вместо локальных учетных записей на каждом устройстве можно централизованно управлять доступом пользователей через доменные группы и политики NPS.

В этой статье мы установили роль NPS и зарегистрировали сервер в Active Directory, добавили RADIUS-клиентов и настроили Network Policy. Затем на практических примерах рассмотрели аутентификацию на оборудовании Cisco и MikroTik, а также настроили корпоративную Wi-Fi-сеть с 802.1X и централизованным распространением параметров подключения через Group Policy.

Отдельно разобрали диагностику NPS: включили аудит, рассмотрели события 6272, 6273 и 6279 в журнале Security и показали, как с помощью PowerShell найти успешные RADIUS-подключения определенного пользователя.

При использовании RADIUS в рабочей инфраструктуре особое внимание стоит уделить безопасности и отказоустойчивости: использовать уникальные Shared Secret, ограничивать доступ к UDP-портам 1812 и 1813, разделять права через группы Active Directory, контролировать сертификаты и по возможности использовать резервный сервер NPS.

В результате Network Policy Server (NPS) позволяет развернуть в Windows Server централизованный RADIUS-сервер, интегрированный с Active Directory, и использовать единую систему аутентификации для доступа к сетевому оборудованию, VPN и корпоративным Wi-Fi-сетям 802.1X.

Вам понравилась эта статья? Тогда вам, скорее всего, будет интересна другая полезная статья Как настроить источник времени NTP на контроллере домена.