Настройка radius windows server 2020 r2: Настройка двухфакторной аутентификации на сервере Network Policy Server

Содержание

Настройка двухфакторной аутентификации на сервере Network Policy Server · Мультифактор

Общая информация

В статье описывается настройка Microsoft Network Policy Server для включения двухфакторной аутентификации с одноразовым кодом доступа или PUSH уведомлением при подключении VPN клиентов, таких как Cisco AnyConnect, FortiClient VPN и других.

Network Policy Server (NPS) — компонент Windows сервера, позволяющий подключаться сетевым устройствам по протоколу RADIUS с контролем доступа и аутентификацией в Active Directory.

Применимо к версиям:

Windows Server 2012 R2
Windows Server 2016
Windows Server 2019

Возможные способы аутентификации:

СМС
Аппаратные OTP токены
Приложения OTP: Google Authenticator или Яндекс.Ключ
Telegram
Мобильное приложение (скоро)

Видео-презентация

Схема работы

Сервер NPS может удостоверять пользователя локально или переадресовывать на внешний RADIUS сервер аутентификации, выступая, как RADIUS PROXY.

Для одновременной проверки логина и пароля локально в Active Directory и второго фактора в Мультифакторе, необходимо установить компонент MultiFactor Radius Adapter и настроить NPS для переадресации запросов доступа компоненту, как стороннему сервису аутентификации.

Компонент устанавливается внутри периметра вашей сети и служит для проверки второго фактора. Компонент не передает пароли пользователей за периметр сети.

Схема потоков данных

Последовательность

Пользователь подключается к VPN через сетевое устройство доступа, вводит логин и пароль.
Устройство обращается к NPS по протоколу RADIUS, передает логин и пароль.
Сервер NPS использует RADIUS сервер аутентификации и проксирует запрос в компонент Multifactor Radius Adapter
Компонент делает два запроса:
- к серверу NPS для проверки логина и пароля пользователя, выступая как RADIUS Client
- к API Мультифактор для создания запроса на второй фактор доступа и отправляет пользователю код или PUSH
Пользователь вводит одноразовый код или подтверждает PUSH запрос
Компонент возвращает в NPS ответ с подтверждением доступа
NPS предоставляет доступ сетевому устройству

Настройка Мультифактора

Pайдите в систему управления Мультифактором, зайдите в раздел «Ресурсы» и создайте новый ресурс Network Policy Server.
После создания вам будут доступны параметры NAS-Identifier и Shared Secret, они потребуются для последующих шагов.

Настройка компонента MultiFactor Radius Adapter

Компонент необходимо запускать на сервере NPS.
Конфигурация компонета хранится в файле MultiFactor.Radius.Adapter.exe.config.

Параметры:

adapter-server-endpoint: IP и порт на котором компонент будет принимать запросы от NPS, например: 192.168.0.1:1814
adapter-client-endpoint: IP и порт с которого компонент будет отправлять запросы к NPS, например: 127.0.0.1:56129
nps-server-endpoint: IP и порт NPS сервера, например: 192.168.0.1:1812
multifactor-api-url: Адрес API Мультифактора — https://api.multifactor.ru
multifactor-nas-identifier: параметр из ресурса Мультифактора
multifactor-shared-secret: параметр из ресурса Мультифактора
logging-level: уровень логов

Компонент может работать в консольном режиме или в режиме службы.
Для установки, как Windows Service, запустите с ключом /i от имени Администратора

MultiFactor.Radius.Adapter.exe /i

Компонент устанавливается в режиме автоматического запуска от имени Network Service.

Для удаление Windows Service запустите с ключом /u от имени Администратора

MultiFactor.Radius.Adapter.exe /u

Журналы

Отладочные журналы компонента находятся в папке Logs. Если их нет, удостоверьтесь, что папка доступна для записи пользователю Network Service.

Настройка NPS

Radius Server

Для того, чтоб NPS переадресовывал запросы компоненту:

В разделе «Remote RADIUS Server Groups» создайте новую группу «MultiFactor Radius Adapters».
Добавьте в группу сервер с адресом из параметра adapter-server-endpoint.
На вкладке «Authentication/Accounting» скопируйте Shared Secret из настроек ресурса Мультифактора.
Поставьте флажок «Request must contains message authenticator attribute».
На вкладке «Load Balancing» поставьте таймауты в 30 секунд.

Radus Client

Для того, чтоб компонент обращался к NPS

В разделе «RADIUS Clients» создайте нового клиента
- Friendly Name: Radius Adapter
- Address: из параметра adapter-client-endpoint
- Shared Secret: из настроек ресурса Мультифактора

Политики подключений

У вас должно быть создано две политики в разделе «Connection Request Policies»:

Политика обработки запроса от VPN устройства:
- на вкладке «Settings» в разделе «Authentication» выберите пункт «Forward requests to the following remote RADIUS server group for authentication» и укажите группу «MultiFactor Radius Adapters».
Политика обработки запроса от компонента:
- на вкладке «Conditions» добавьте условие NAS Identifier и поставьте значение из настроек ресурса Мультифактора
- на вкладке «Settings» в разделе «Authentication» выберите пункт «Authenticate requests on this server».

Смотрите также:

Настраиваем доменную аутентификацию на сетевом оборудовании

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

Не все сетевое оборудование популярных вендоров (CISCO, HP, Huawei) поддерживает функционал для непосредственного обращения к каталогу LDAP, и такое решение не будет универсальным. Для решения нашей задачи подойдет протокол AAA (Authentication Authorization and Accounting), фактически ставший стандартом де-факто для сетевого оборудования. Клиент AAA (сетевое устройство) отправляет данные авторизующегося пользователя на сервер RADIUS и на основе его ответа принимает решение о предоставлении / отказе доступа.

Протокол Remote Authentication Dial In User Service (RADIUS) в Windows Server 2012 R2 включен в роль NPS (Network Policy Server). В первой части статьи мы установим и настроим роль Network Policy Server, а во второй покажем типовые конфигурации сетевого устройств с поддержкой RADUIS на примере коммутаторов HP Procurve и оборудования Cisco.

Установка и настройка сервера с ролью Network Policy Server
Настройка сетевого оборудования для работы с сервером RADUIS

Установка и настройка сервера с ролью Network Policy Server

Как правило, сервер с ролью NPS рекомендуется устанавливать на выделенном сервере (не рекомендуется размещать эту роль на контроллере домена). В данном примере роль NPS мы будем устанавливать на сервере с Windows Server 2012 R2.

Откройте консоль Server Manager и установите роль Network Policy Server (находится в разделе Network Policy and Access Services).

После окончания установки запустите mmc-консоль управления Network Policy Server. Нас интересуют три следующих раздела консоли:

RADIUS Clients — содержит список устройств, которые могут аутентифицироваться на сервере
Connection Request Policies – определяет типы устройств, которые могут аутентифицироваться
Network Polices – правила аутентификации

Добавим нового клиента RADIUS (это будет коммутатор HP ProCurve Switch 5400zl), щелкнув ПКМ по разделу RADIUS Clients и выбрав New. Укажем:

Friendly Name:sw-HP-5400-1
Address (IP or DNS): 10.10.10.2
Shared secret (пароль/секретный ключ): пароль можно указать вручную (он должен быть достаточно сложным), либо сгенерировать с помощью специальной кнопки (сгенерированный пароль необходимо скопировать, т.к. в дальнейшем его придется указать на сетевом устройстве).

Отключим стандартную политику (Use Windows authentication for all users) в разделе Connection Request Policies, щелкнув по ней ПКМ и выбрав Disable.

Создадим новую политику с именем Network-Switches-AAA и нажимаем далее. В разделе Сondition создадим новое условие. Ищем раздел RADIUS Client Properites и выбираем Client Friendly Name.

В качестве значения укажем sw-?. Т.е. условие будет применяться для всех клиентов RADIUS, начинающийся с символов :”sw-“. Жмем Next->Next-> Next, соглашаясь со всеми стандартными настройками.

Далее в разделе Network Policies создадим новую политику аутентификации. Укажите ее имя, например Network Switch Auth Policy for Network Admins. Создадим два условия: в первом условии Windows Groups, укажем доменную группу, члены которой могут аутентифицироваться (учетные записи сетевых администраторов в нашем примере включены в группу AD Network Admins) Второе условие Authentication Type, выбрав в качестве протокола аутентификации PAP.

Далее в окне Configure Authentication Methods снимаем галки со всех типов аутентификации, кроме Unencrypted authentication (PAP. SPAP).

В окне Configure Settings изменим значение атрибута Service-Type на Administrative.

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

И, напоследок, переместим новую политику на первое место в списке политик.

Настройка сетевого оборудования для работы с сервером RADUIS

Осталось настроить наше сетевое оборудование для работы с сервером Radius. Подключимся к нашему коммутатору HP ProCurve Switch 5400 и внесем следующе изменение в его конфигурацию (измените ip адрес сервера Raduis и пароль на свои).

aaa authentication console enable radius localaaa authentication telnet login radius localaaa authentication telnet enable radius localaaa authentication ssh login radius localaaa authentication ssh enable radius localaaa authentication login privilege-moderadius-server key YOUR-SECRET-KEYradius-server host 10.10.10.44 YOUR-SECRET-KEY auth-port 1645 acct-port 1646radius-server host 10.10.10.44 auth-port 1645radius-server host 10.10.10.44 acct-port 1646

Совет. Если в целях безопасности вы запретили подключаться к сетевому оборудованию через telnet, эти строки нужно удалить из конфига:

aaa authentication telnet login radius localaaa authentication telnet enable radius local

Не закрывая консольное окно коммутатора (это важно!, иначе, если что-то пойдет не так, вы более не сможете подключиться к своему коммутатору), откройте вторую telnet-сессию. Должно появиться новое окно авторизации, в котором будет предложено указать имя и пароль учетной записи. Попробуйте указать данные своей учетной записи в AD (она должна входить в группу Network Admins ). Если подключение установлено – вы все сделали правильно!

Для коммутатора Cisco конфигурация, предполагающая использование доменных учетных записей для аутентификации и авторизации, может выглядеть так:

Примечание. В зависимости от модели сетевого оборудования Cisco и версии IOS конфигурация может несколько отличаться.

aaa new-modelradius-server host 10.10.10.44 auth-port 1645 acct-port 1646 key YOUR-SECRET-KEYaaa authentication login default group radius localaaa authorization exec default group radius localip radius source-interface Vlan421line con 0line vty 0 4line vty 5 15

Примечание. В такой конфигурации для аутентификации сначала используется сервер RADIUS, а если он не доступен – локальная учетная запись.

Для Cisco ASA конфигурация будет выглядеть так:

aaa-server RADIUS protocol radiusaaa-server RADIUS host 10.10.10.44 key YOUR-SECRET-KEYradius-common-pw YOUR-SECRET-KEYaaa authentication telnet console RADIUS LOCALaaa authentication ssh console RADIUS LOCALaaa authentication http console RADIUS LOCALaaa authentication http console RADIUS LOCAL

Совет. Если что то-не работает, проверьте:

Совпадают ли секретные ключи на сервере NPS и коммутаторе (для теста можно использоваться простой пароль).
Указан ли правильный адрес NPS сервера в конфигурации. Пингуется ли он?
Не блокируют ли межсетевые экраны порты 1645 и 1646 между коммутатором и сервером?
Внимательно изучите логи NPS сервера

Настройка 802.1X на коммутаторах Cisco с помощью отказоустойчивого NPS (Windows RADIUS with AD)

Рассмотрим на практике использование Windows Active Directory + NPS (2 сервера для обеспечения отказоустойчивости) + стандарт 802.1x для контроля доступа и аутентификации пользователей – доменных компьютеров – устройств. Ознакомиться с теорией по стандарту можно в Wikipedia, по ссылке: IEEE 802.1X

Так как “лаборатория” у меня ограничена по ресурсам, совместим роли NPS и контроллера домена, но вам я рекомендую такие критичные сервисы все же разделять.

Стандартных способов синхронизации конфигураций (политик) Windows NPS я не знаю, поэтому будем использовать скрипты PowerShell, запускаемые планировщиком заданий (автор мой бывший коллега). Для аутентификации компьютеров домена и для устройств, не умеющих в 802.1x (телефоны, принтеры и пр), будет настроена групповая политика и созданы группы безопасности.

В конце статьи расскажу о некоторых тонкостях работы с 802.1x – как можно использовать неуправляемые коммутаторы, dynamic ACL и пр. Поделюсь информацией об отловленных “глюках”…

Начнем с установки и настройки failover NPS on Windows Server 2012R2 (на 2016-м все аналогично): через Server Manager -> Add Roles and Features Wizard выбираем лишь Network Policy Server.

или с помощью PowerShell:

Install-WindowsFeature NPAS -IncludeManagementTools

Небольшое уточнение – так как для Protected EAP (PEAP) вам обязательно потребуется сертификат, подтверждающий подлинность сервера (с соответствующими правами на использование), который будет в доверенных на клиентских компьютерах, то вам скорее всего потребуется установить еще и роль Certification Authority. Но будем считать, что CA у вас уже установлен…

Сделаем тоже самое и на втором сервере. Создадим папку для скрипта C:\Scripts на обоих серверах и сетевую папку на втором сервере \\SRV2\NPS-config$

На первом сервере создадим PowerShell скрипт C:\Scripts\Export-NPS-config.ps1 со следующим содержанием:

Export-NpsConfiguration -Path "\\SRV2\NPS-config$\NPS.xml"

После этого настроим задание в Task Sheduler: “Export-NpsConfiguration”

powershell -executionpolicy unrestricted -f "C:\Scripts\Export-NPS-config.ps1"

Выполнять для всех пользователей — Выполнить с наивысшими правами

Ежедневно — Повторять задачу каждые 10 мин. в течении 8 ч.

На резервном NPS настроим импорт конфигурации (политик):

создадим скрипт PowerShell:

echo Import-NpsConfiguration -Path "c:\NPS-config\NPS.xml" >> C:\Scripts\Import-NPS-config.ps1

и задачу на его выполнение каждые 10 минут:

powershell -executionpolicy unrestricted -f "C:\Scripts\Import-NPS-config.ps1"

Теперь, для проверки, добавим в NPS на одном из серверов(!) пару коммутаторов в RADIUS-клиенты (IP и Shared Secret), две политики запросов на подключение: WIRED-Connect (Условие: “Тип порта NAS – Ethernet”) и WiFi-Enterprise (Условие: “Тип порта NAS – IEEE 802.11”), а также сетевую политику Access Cisco Network Devices (Network Admins):

Условия:
Группы Windows - domain\sg-network-admins
Ограничения:
Методы проверки подлинности - Проверка открытым текстом (PAP, SPAP)
Параметры:
Атрибуты RADIUS: Стандарт - Service-Type - Login
Зависящие от поставщика - Cisco-AV-Pair - Cisco - shell:priv-lvl=15

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

aaa new-model
aaa local authentication attempts max-fail 5
!
!
aaa group server radius NPS
 server-private 192.168.38.151 auth-port 1812 acct-port 1813 key %shared_secret%
 server-private 192.168.10.151 auth-port 1812 acct-port 1813 key %shared_secret%
!
aaa authentication login default group NPS local
aaa authentication dot1x default group NPS
aaa authorization console
aaa authorization exec default group NPS local if-authenticated
aaa authorization network default group NPS
!
aaa session-id common
!
identity profile default
!
dot1x system-auth-control
!
!
line vty 0 4
 exec-timeout 5 0
 transport input ssh
 escape-character 99
line vty 5 15
 exec-timeout 5 0
 logging synchronous
 transport input ssh
 escape-character 99

После настройки, спустя 10 минут, все клиенты\политики\параметры должны появиться и на резервном NPS и мы сможем авторизоваться на коммутаторах с помощью учетной записи ActiveDirectory, члена группы domain\sg-network-admins (которую мы создали заранее).

Перейдем к настройке Active Directory – создадим групповую и парольную политики, создадим необходимые группы.

Групповая политика Computers-8021x-Settings:

Computer Configuration (Enabled)
   Policies
     Windows Settings
        Security Settings
          System Services
     Wired AutoConfig (Startup Mode: Automatic)
Wired Network (802.3) Policies

NPS-802-1x

Name	NPS-802-1x
Description	802.1x
Global Settings
SETTING	VALUE
Use Windows wired LAN network services for clients	Enabled
Shared user credentials for network authentication	Enabled
Network Profile
Security Settings
Enable use of IEEE 802.1X authentication for network access	Enabled
Enforce use of IEEE 802.1X authentication for network access	Disabled
IEEE 802.1X Settings
Computer Authentication	Computer only
Maximum Authentication Failures	10
Maximum EAPOL-Start Messages Sent	 
Held Period (seconds)	 
Start Period (seconds)	 
Authentication Period (seconds)	 
Network Authentication Method Properties
Authentication method	Protected EAP (PEAP)
Validate server certificate	Enabled
Connect to these servers	 
Do not prompt user to authorize new servers or trusted certification authorities	Disabled
Enable fast reconnect	Enabled
Disconnect if server does not present cryptobinding TLV	Disabled
Enforce network access protection	Disabled
Authentication Method Configuration
Authentication method	Secured password (EAP-MSCHAP v2)
Automatically use my Windows logon name and password(and domain if any)	Enabled

Создадим группу безопасности sg-computers-8021x-vl100, куда мы будем добавлять компьютеры, которые мы хотим распределять в влан 100 и настроим фильтрацию для созданной ранее групповой политики на эту группу:

Убедиться в том, что политика успешно отработала можно открыв “Центр управления сетями и общим доступом (Параметры сети и Интернет) – Изменение параметров адаптера (Настройка параметров адаптера) – Свойства адаптера”, где мы сможем увидеть вкладку “Проверка подлинности”:

Когда убедились, что политика успешно применяется – можно переходить к настройке сетевой политики на NPS и портов коммутатора уровня доступа.

Создадим сетевую политику neag-computers-8021x-vl100:

Conditions:
  Windows Groups - sg-computers-8021x-vl100
  NAS Port Type - Ethernet
Constraints:
  Authentication Methods - Microsoft: Protected EAP (PEAP) - Unencrypted authentication (PAP, SPAP)
  NAS Port Type - Ethernet
Settings:
  Standard:
   Framed-MTU 1344
   TunnelMediumType 802 (includes all 802 media plus Ethernet canonical format)
   TunnelPrivateGroupId  100
   TunnelType  Virtual LANs (VLAN)

Типовые настройки для порта коммутатора (обращаю внимание, что используется тип аутентификации “мультидомен” – Data & Voice, а также есть возможность аутентификации по mac адресу. на время “переходного периода” есть смысл использовать в параметрах:


authentication event fail action authorize vlan 100
authentication event no-response action authorize vlan 100

влан id не “карантинного”, а того же, куда пользовательский компьютер должен попасть, успешно авторизовавшись – пока не убедимся, что все работает как следует. Эти же параметры могут быть использованы и в других сценариях, например, когда в этот порт воткнут неуправляемый коммутатор и вы хотите, чтобы все устройства, подключенные в него и не прошедшие аутентификацию, попадали в определенный влан (“карантинный”).настройки порта коммутатора в режиме 802.1x host-mode multi-domain

default int range Gi1/0/39-41
int range Gi1/0/39-41
shu
des PC-IPhone_802.1x
switchport mode access
switchport nonegotiate
switchport voice vlan 55
switchport port-security maximum 2
authentication event fail action authorize vlan 100
authentication event no-response action authorize vlan 100
authentication host-mode multi-domain
authentication port-control auto
authentication violation restrict
mab
dot1x pae authenticator
dot1x timeout quiet-period 15
dot1x timeout tx-period 3
storm-control broadcast level pps 100
storm-control multicast level pps 110
no vtp
lldp receive
lldp transmit
spanning-tree portfast
no shu
exit

Убедиться, что компьютер\телефон успешно прошли аутентификацию можно командой:

sh authentication sessions int Gi1/0/39 det

Теперь создадим группу (например, sg-fgpp-mab ) в Active Directory для телефонов и добавим в нее один аппарат для тестов (в моем случае это Grandstream GXP2160 с мас-адресом 000b.82ba.a7b1 и соотв. учетной записью domain\000b82baa7b1).

Для созданной группы понизим требования парольной политики (используя Fine-Grained Password Policies через Active Directory Administrative Center -> domain -> System -> Password Settings Container) с такими параметрами Password-Settings-for-MAB:

тем самым разрешим использовать мас-адрес устройств в качестве паролей. После этого мы сможем создать сетевую политику для аутентификации 802.1x method mab, назовем ее neag-devices-8021x-voice. Параметры следующие:

NAS Port Type – Ethernet

Windows Groups – sg-fgpp-mab

EAP Types: Unencrypted authentication (PAP, SPAP)

RADIUS Attributes – Vendor Specific: Cisco – Cisco-AV-Pair – Attribute value: device-traffic-class=voice

после успешной аутентификации (не забываем настроить порт коммутатора), посмотрим информацию с порта:sh authentication se int Gi1/0/34

----------------------------------------
            Interface:  GigabitEthernet1/0/34
          MAC Address:  000b.82ba.a7b1
           IP Address:  172.29.31.89
            User-Name:  000b82baa7b1
               Status:  Authz Success
               Domain:  VOICE
       Oper host mode:  multi-domain
     Oper control dir:  both
        Authorized By:  Authentication Server
      Session timeout:  N/A
         Idle timeout:  N/A
    Common Session ID:  0000000000000EB2000B8C5E
      Acct Session ID:  0x00000134
               Handle:  0xCE000EB3

Runnable methods list:
       Method   State
       dot1x    Failed over
       mab      Authc Success

Теперь, как и обещал рассмотрим пару не совсем очевидных ситуаций. Например, нам требуется подключить компьютеры\устройства пользователей через неуправляемый коммутатор (свитч). В этом случае настройки порта для него будут выглядеть следующим образом:настройки порта коммутатора в режиме 802.1x host-mode multi-auth

interface GigabitEthernet1/0/1
description *SW – 802.1x – 8 mac*
shu
switchport mode access
switchport nonegotiate
switchport voice vlan 55
switchport port-security maximum 8  ! увеличиваем кол-во допустимых мас-адресов
authentication event fail action authorize vlan 100
authentication event no-response action authorize vlan 100
authentication host-mode multi-auth  ! – режим аутентификации
authentication port-control auto
authentication violation restrict
mab
dot1x pae authenticator
dot1x timeout quiet-period 15
dot1x timeout tx-period 3
storm-control broadcast level pps 100
storm-control multicast level pps 110
no vtp
spanning-tree portfast
no shu

P.S. замечен очень странный глюк – если устройство было подключено через такой свитч, а потом его воткнули в управляемый коммутатор, то оно НЕ заработает, пока мы не перезагрузим(!) свитч Пока других способов решения этой проблемы не нашел.

Еще один момент, связанный с DHCP (если используется ip dhcp snooping) – без таких вот опций:

ip dhcp snooping vlan 1-100
no ip dhcp snooping information option

почему-то корректно ip адрес не получить…хотя может это особенность нашего DHCP сервера

А еще Mac OS & Linux (в которых поддержка 802.1x нативная) пытаются пройти аутентификацию пользователем, даже если настроена аутентификация по мас-адресу.

В следующей части статьи рассмотрим применение 802.1x для Wireless (в зависимости от группы, в которую входит учетная запись пользователя, его будем “закидывать” в соответствующую сеть (влан), хотя подключаться они будут к одному SSID).

WiFi Enterprise. FreeRadius + FreeIPA + Ubiquiti / Хабр

Уже были описаны некоторые примеры организации корпоративного WiFi. Здесь я распишу как реализовал подобное решение и проблемы с которыми пришлось столкнуться при подключении на разных устройствах. Будем использовать уже имеющийся LDAP с заведенными пользователями, поднимем FreeRadius и настроим WPA2-Enterprise на контроллере Ubnt. Вроде все просто. Посмотрим…

Немного о методах EAP

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

Из википедии:

EAP — фреймворк аутентификации, который часто используется в беспроводных сетях и соединениях точка-точка. Формат был впервые описан в RFC 3748 и обновлён в RFC 5247.

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

Сами методы:

LEAP — проприетарный протокол, разработан CISCO. Найдены уязвимости. В настоящее время не рекомендуется использовать

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

EAP-TTLS — широко поддерживается во многих системах, предлагает хорошую безопасность, используя PKI сертификаты только на сервере аутентификации

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

EAP-IKEv2 — основан на Internet Key Exchange Protocol version 2. Обеспечивает взаимную аутентификацию и установление сеансового ключа между клиентом и сервером

PEAP — совместное решение CISCO, Microsoft и RSA Security как открытый стандарт. Широко доступен в продуктах, обеспечивает очень хорошую безопасность. Схож с EAP-TTLS, требуя только сертификат на серверной стороне

PEAPv0/EAP-MSCHAPv2 — после EAP-TLS, это второй широко используемый стандарт в мире. Используется клиент-серверная взаимосвязь в Microsoft, Cisco, Apple, Linux

PEAPv1/EAP-GTC — создан Cisco как альтернатива PEAPv0/EAP-MSCHAPv2. Не защищает аутентификационные данные в любом случае. Не поддерживаются в Windows OS

EAP-FAST — метод, разработанный Cisco для исправления недостатков LEAP. Использует Protected Access Credential (PAC). Полностью не доработан

Из всего этого разнообразия, выбор все таки не велик. От метода аутентификации требовалось: хорошая безопасность, поддержка на всех устройствах (Windows 10, macOS, Linux, Android, iOS) и, собственно, чем проще, тем лучше. Поэтому выбор пал на EAP-TTLS в связке с протоколом PAP.
Возможно возникнет вопрос — Зачем же использовать PAP? ведь он передает пароли в открытом виде?

Да, все верно. Общение между FreeRadius и FreeIPA будет проходить именно в так. В режиме дебага можно отследить как отправляются username и password. Да и пусть отправляются, только у вас есть доступ к серверу FreeRadius.

Подробнее о работе EAP-TTLS можно почитать тут

FreeRADIUS

FreeRadius будем поднимать на CentOS 7.6. Здесь ничего сложного, ставим обычным способом.

yum install freeradius freeradius-utils freeradius-ldap -y

Из пакетов ставится версия 3.0.13. Последнюю можно взять на https://freeradius.org/

После этого FreeRadius уже работает. Можно в /etc/raddb/users расскоментировать строчку

steve   Cleartext-Password := "testing"

Запустить в сервер в режиме дебага

freeradius -X

И делаем тестовое подключение с localhost

radtest steve testing 127.0.0.1 1812 testing123

Получили ответ Received Access-Accept Id 115 from 127.0.0.1:1812 to 127.0.0.1:56081 length 20, значит все хорошо. Идем дальше.

Подключаем модуль ldap.

ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldap

И сразу его изменим. Нам нужно, чтобы FreeRadius мог обращаться к FreeIPAmods-enabled/ldap

ldap {
server="ldap://ldap.server.com"
port=636
start_tls=yes
identity="uid=admin,cn=users,dc=server,dc=com"
password=**********
base_dn="cn=users,dc=server,dc=com"
set_auth_type=yes
...
user {
base_dn="${..base_dn}"
filter="(uid=%{%{Stripped-User-Name}:-%{User-Name}})"
}
...

Перезапускаем radius-сервер и проверяем синхронизацию пользователей LDAP:

radtest user_ldap password_ldap localhost 1812 testing123

Редактируем eap в mods-enabled/eap
Здесь добавим два экземпляра eap. Они будут отличаться только сертификатами и ключами. Чуть ниже объясню, почему именно такmods-enabled/eap

eap eap-client {                                                                                                                                                                                                                           default_eap_type = ttls                                                                                                                                                                                                                 timer_expire = 60                                                                                                                                                                                                                       ignore_unknown_eap_types = no                                                                                                                                                                                                          cisco_accounting_username_bug = no                                                                                                                                                                                                      max_sessions = ${max_requests}
           tls-config tls-common {
           private_key_file = ${certdir}/fisrt.key
           certificate_file = ${certdir}/first.crt
           dh_file = ${certdir}/dh
           ca_path = ${cadir}
           cipher_list = "HIGH"
           cipher_server_preference = no
           ecdh_curve = "prime256v1"
           check_crl = no
           }
                                                                                                                                                                                                                                                                                                                                                                                                                                                 
           ttls {
           tls = tls-common
           default_eap_type = md5
           copy_request_to_tunnel = no
           use_tunneled_reply = yes
           virtual_server = "inner-tunnel"
           }
}
eap eap-guest {
default_eap_type = ttls                                                                                                                                                                                                                 timer_expire = 60                                                                                                                                                                                                                       ignore_unknown_eap_types = no                                                                                                                                                                                                          cisco_accounting_username_bug = no                                                                                                                                                                                                      max_sessions = ${max_requests}
           tls-config tls-common {
           private_key_password=blablabla
           private_key_file = ${certdir}/server.key
           certificate_file = ${certdir}/server.crt
           dh_file = ${certdir}/dh
           ca_path = ${cadir}
           cipher_list = "HIGH"
           cipher_server_preference = no
           ecdh_curve = "prime256v1"
           check_crl = no
           }
                                                                                                                                                                                                                                                                                                                                                                                                                                                 
           ttls {
           tls = tls-common
           default_eap_type = md5
           copy_request_to_tunnel = no
           use_tunneled_reply = yes
           virtual_server = "inner-tunnel"
           }
}

Далее редактируем site-enabled/default. Интересуют разделы authorize и authenticate.site-enabled/default

authorize {
  filter_username
  preprocess
  if (&User-Name == "guest") {
   eap-guest {
       ok = return
   }
  }
  elsif (&User-Name == "client") {
    eap-client {
       ok = return 
    }
  }
  else {
    eap-guest {
       ok = return
    }
  }
  ldap
  if ((ok || updated) && User-Password) {
    update {
        control:Auth-Type := ldap
    }
  }
  expiration
  logintime
  pap
  }

authenticate {
  Auth-Type LDAP {
    ldap
  }
  Auth-Type eap-guest {
    eap-guest
  }
  Auth-Type eap-client {
    eap-client
  }
  pap
}

В секции authorize убираем все модули, которые нам не нужны. Оставляем только ldap. Добавляем проверку клиента по username. Именно для этого мы добавляли выше два экземпляра eap.Multi EAP

Дело в том, что подключая некоторые устройства мы будем использовать системные сертификаты и указывать домен. У нас есть сертификат и ключ от доверенного центра сертификации. Лично по моему мнению такая процедура подключения проще, чем кидать на каждое устройство самоподписанный сертификат. Но и без самоподписанных сертификатов все же не получилось уйти. Samsung девайсы и Android =< 6 версии не умеют использовать системные сертификаты. Поэтому для них создаем отдельный экземпляр eap-guest с самоподписанными сертификатами. Для всех других устройств будем использовать eap-client c доверенным сертификатом. User-Name определяется по полю Anonymous при подключении устройства. Разрешено использовать только 3 значения: Guest, Client и пустое поле. Остальное все отбрасывается. Это настраиватся в политиках. Пример приведу чуть позже

Отредактируем секции authorize и authenticate в site-enabled/inner-tunnelsite-enabled/inner-tunnel

authorize {
  filter_username
  filter_inner_identity
  update control {
   &Proxy-To-Realm := LOCAL
  }
  ldap
  if ((ok || updated) && User-Password) {
    update {
        control:Auth-Type := ldap
    }
  }
  expiration
  digest
  logintime
  pap
  }

authenticate {
  Auth-Type eap-guest {
    eap-guest
  }
  Auth-Type eap-client {
    eap-client
  }
  Auth-Type PAP {
    pap
  }
  ldap
}

Далее нужно прописать в политиках, какие имена можно использовать для анонимного входа. Редактируем policy.d/filter.

Нужно найти строчки похожие на это:

if (&outer.request:User-Name !~ /^(anon|@)/) {
  update request {
    Module-Failure-Message = "User-Name is not anonymized"
  }
  reject
}

И ниже в elsif добавить нужные значения:

elsif (&outer.request:User-Name !~ /^(guest|client|@)/) {
  update request {
    Module-Failure-Message = "User-Name is not anonymized"
  }
  reject
}

Теперь нам нужно переместиться в директорию certs. Сюда нужно положить ключ и сертификат от доверенного центра сертификации, который у нас уже есть и нужно сгенерировать самоподписанные сертификаты для eap-guest.

Изменяем параметры в файле ca.cnf.

ca.cnf


...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = RU
stateOrProvinceNmae = State
localityNmae = City
organizationName = NONAME
emailAddress = [email protected]
commonName = "CA FreeRadius"

Такие же значения прописываем в файле server.cnf. Меняем только
commonName:server.cnf


...
default_days = 3650
default_md = sha256
...
input_password = blablabla
output_password = blablabla
...
countryName = RU
stateOrProvinceNmae = State
localityNmae = City
organizationName = NONAME
emailAddress = [email protected]
commonName = "Server Certificate FreeRadius"

Создаем:

make

Готово. Полученные server.crt и server.key у нас уже прописаны выше в eap-guest.

И последнее, добавим наши точки доступа в файл client.conf. У меня их 7. Чтобы не добавлять каждую точку отдельно, пропишем только сеть в которой они находятся (у меня точки доступа находятся в отдельном VLAN).

client APs {
ipaddr = 192.168.100.0/24
password = password_AP
}

Контроллер Ubiquiti

На контроллере поднимаем отдельную сеть. Пусть будет 192.168.2.0/24
Идем в настройки -> профиль. Cоздаем новый:

Прописываем адрес и порт radius-сервера и пароль, который прописывали в файле clients.conf:

Создаем новое имя беспроводной сети. В качестве метода аутентификации выбираем WPA-EAP (Enterprise) и указываем созданный radius-профиль:

Все сохраняем, применяем и идем дальше.

Настройка клиентов

Начнем с самого сложного!

Windows 10

Сложность сводится к тому, что Windows пока еще не умеет подключаться к корпоративному WiFi по домену. Поэтому приходится вручную закидывать наш сертификат в хранилище доверенных сертификатов. Здесь можно использовать как самоподписанный так и от центра сертификации. Я буду использовать второй.

Далее нужно создать новое подключение. Для этого идем в параметры сети и Интернет -> Центр управления сетями и общим доступом -> Создание и настройка нового подключения или сети:

Вручную прописываем имя сети и меняем тип безопасности. После нажимаем на изменить параметры подключения и во владке Безопасность выбираем проверку подлинности сети — EAP-TTLS.

Заходим в параметры, прописываем конфиденциальность аутентификации — client. В качестве доверенного центра сертификации выбираем добавленный нами сертификат, ставим галочку «Не выдавать пользователю приглашение, если не удается авторизовать сервер» и метод проверки подлинности выбираем — незашифрованный пароль (PAP).

Далее заходим в дополнительные параметры, ставим галочку на «Укажите режим проверки подлинности». Выбираем пункт «Проверка подлинности пользователя» и нажимаем на сохранить учетные данные. Здесь надо будет ввести username_ldap и password_ldap

Все сохраняем, применяем, закрываем. Можно подключаться к новой сети.

Linux

Я проверял на Ubuntu 18.04, 18.10, Fedora 29, 30.

Для начала, скачиваем себе сертификат. Я не нашел в Linux, есть ли возможность использовать системные сертификаты и есть ли там вообще такое хранилище.

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

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

anonymous — client

domain — домен, на который выпущен сертификат

Android

non-Samsung

C 7 версии при подключении WiFi можно использовать системные сертификаты, указав только домен:

domain — домен, на который выпущен сертификат

anonymous — client

Samsung

Как уже писал выше, Samsung-устройства не умеют использовать системные сертификаты при подключении WiFi, и у них нет возможности подключаться по домену. Поэтому надо вручную добавить корневой сертификат центра сертификации (ca.pem, берем на Radius сервере). Вот здесь будет использовать самоподписанный.

Скачиваем сертификат себе на устройство и устанавливаем его.

Установка сертификата

При этом, надо будет установить рисунок разблокировки экрана, пин-код или пароль, если он еще не установлен:

Я показал сложный вариант установки сертификата. На большинстве устройств достаточно просто нажать на скаченный сертификат.

Когда сертификат установлен, можно переходить к подключению:

сертификат — указываем тот, который устанавливали

анонимный пользователь — guest

macOS

Яблочные устройства из коробки могут подключаться только к EAP-TLS, но все равно нужно закидывать им сертификат. Чтобы указать другой метод подключения, нужно воспользоваться Apple Configurator 2. Соответственно нужно предварительно скачать его на мак, создать новый профиль и добавить все необходимые настройки WiFi.Apple Configurator

Здесь указываем имя своей сети

Security Type — WPA2 Enterprise

Accepted EAP Types — TTLS

User Name и Password — оставляем пустыми

Inner Authentication — PAP

Outer Identity — client

Вкладка Trust. Здесь указываем наш домен

Все. Профиль можно сохранять, подписывать и распространять на устройства

После того, как профиль готов, его нужно скачать на мак и установить. В процессе установки нужно будет указать usernmae_ldap и password_ldap пользователя:

iOS

Процесс аналогичен macOS. Нужно использовать профиль (можно прям такой же как для macOS. Как создавать профиль в Apple Configurator, смотреть выше).

Скачиваем профиль, устанавливаем, вводим учетные данные, подключаемся:

На этом все. Мы настроили Radius сервер, синхронизировали его с FreeIPA и указали точкам доступа Ubiquiti использовать WPA2-EAP.

Возможные вопросы

В: как передавать профиль/сертификат сотруднику?

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

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

В: почему не использовать схему с MSCHAPv2? она же более безопасная!

О: во-первых, такая схема хорошо работает на NPS (Windows Network Policy System), в нашей реализации необходимо дополнительно настраивать LDAP (FreeIpa) и хранить хэши паролей на сервере. Доп. настройки делать не желательно, т.к. это может привести к различным проблемам сихронизации УЗ. Во-вторых, хеш представляет собой MD4, так что это не особо повышает безопасность

В: можно ли авторизовывать устройтсва по mac-адресам?

О: НЕТ, это не безопасно, злоумышленник может подменить мак-адреса, и тем более авторизация по мак-адресам не поддерживается на многих устройствах

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

О: сертификаты используются, чтобы авторизовать сервер. Т.е. устройство при подключении проверяет тот ли это сервер, которому можно доверять или нет. Если тот, то аутентификация проходит дальше, если нет, соединение закрывается. Можно подключаться без сертификатов, но если злоумышленик или сосед поднимет у себя дома radius-сервер и точку доступа с таким же именем как у нас, он сможет легко перехватить учетные данные пользователя (не забываем, что они передаются в открытом виде). А когда используется сертификат, враг увидит у себя в логах только наши вымышленные User-Name — guest или client и ошибку типа — Unknown CA Certificate

еще немного про macOS

Обычно на macOS переустановка системы делается через интернет. В режиме восстановления мак надо подключить к WiFi, и здесь не сработает ни наш корпоративный WiFi, ни гостевая сеть. Лично я поднял еще одну сеть, обычную по WPA2-PSK, скрытую, только для технических операций. Либо еще можно заранее сделать загрузочную флешку с системой. Но если мак после 2015 года, надо будет еще найдит адаптер для это флешки)

Бесшовный роуминг и встроенный RADIUS-сервер: настройка!

Как известно, ключевым преимуществом Wi-Fi решения EdimaxPRO является не только поддержка бесшовного роуминга, который есть практически у всех, но и встроенный RADIUS-сервер, которого нет у многих дешевых и даже ряда дорогих производителей.

Решения EdimaxPRO удобно ещё и потому, что при создании небольшой WiFi сети (до 8 точек доступа) не нужно покупать дополнительный дорогой контроллер. Одна из точек сама может выступать в роли контроллера, обеспечивая незаметный хэндовер и групповое конфигурирование через NMS систему Edimax.

В единой сети поддерживается до 32 SSID (16 в диапазоне 2,4 ГГц + 16 в диапазоне 5 ГГц – 802.3ac), каждая из которых может быть привязана к отдельному VLAN. Существует возможность настройки гостевой сети с ограничением скорости доступа (шагом в 1 Мбит).

Все точки настраиваются из одного места (NMS – система точки-контроллера). Возможно применение групповых политик безопасности с использование встроенного RADIUS-сервера (WPA-EAP) на 256 пользователей (завести пользователей в явном виде или воспользоваться сертификатом для групповой политики).

Следующие рекомендации применимы к WiFi точкам доступа серии EdimaxPro: CAP300, CAP1200, CAP1750, WAP1200, WAP1750, OAP900, OAP1750.

Также в инструкции рассмотрено как создавать профиль гостевой сети с ограничением входящего/исходящего трафика.

Настройка бесшовного роуминга и встроенный RADIUS-сервер на оборудовании EdimaxPRO

ШАГ 1. Подключить точки в единую локальную сеть.

ШАГ 2. Настроить роли точек.

Зайти в Web-интерфейс каждой точки.

Для точек доступа определить роль «Managed AP mode» (Management -> Operation Mode)

Одной из точек назначить роль контроллера «AP Controller Mode». После применения параметра web-интерфейс контроллера будет выглядеть так:

ШАГ 3. Настройка групповой политики в режиме NMS

Создать идентификаторы сети SSID: NMS Settings –> WLAN. Допустимо создать до 32 SSID с различными методами шифрования и аутентификации.

В диалоговом окне надо указать название сети (SSID), к какому VLANу относится (SSID жёстко привязан к одному VLANу), тип аутентификации и способ шифрования.

3.2. Создать группу WLAN, в которую включить все SSID, созданные до этого

Для каждого SSID можно изменить настройки VLAN (заменить номер VLAN), к которому данный SSID относится.

3.3. При необходимости создать групповые настройки для гостевой сети (аналогично предыдущему пункту)

NMS Settings –> Guest Network

В групповой политике гостевой сети имеется возможность ограничить скорость (Shaping) для входящего и исходящего трафика.

3.4. Настроить внутренний RADIUS-сервер (для режима WPA-EAP).

NMS Settings -> RADIUS -> Internal RADIUS Server -> Добавить

При необходимости доступа для большого количества пользователей рекомендуется использовать PKCS сертификат.

Или, если необходимо открыть доступ небольшому количеству пользователей, их можно указать вручную в закладке RADIUS Account. NMS Settings -> RADIUS -> Internal RADIUS Account -> Добавить

Применить RADIUS-сервер к групповой политике.

NMS Settings -> RADIUS -> Internal RADIUS Group -> Добавить

3.6. Применить настройки SSID и RADIUS-сервера к групповой политике ко всем точкам

NMS Settings -> Access Point -> Access Point Group -> Редактировать политику System Default

Необходимо указать к каким радио-интерфейсам мы применяем групповые настройки WLAN (рекомендуется применять одновременно к 2,4 ГГц и 5 ГГц). Указать политику для гостевого доступа. Указать используемую политику RADIUS – сервера. Указать MAC-адреса точек, используемых в групповой настройке (которые были обнажены через Autodiscovering).

Точки синхронизируются через небольшой промежуток времени (1-2 минуты). Для ускорения можно синхронизировать настройки вручную в меню «Dashboard».

Как видите, бесшовный роуминг и встроенный RADIUS-сервер настраиваются очень легко, если вы используете профессиональное WiFi оборудование, такое как EdimaxPRO!

См. также:

Настройка Radius аутентификации с Windows Server 2012 NPS (Network Policy Server) на Cisco IOS

Содержание статьи:

Рассмотрим настройку Radius аутентификации на Cisco устройствах, посредством службы Политики сети и доступа (Network Policy Server) на Windows Server 2012 R2.

Добавление роли, настройка Active Directory

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

Выбираем роль (Службы политики сети и доступа):

Выбираем службу ролей (Сервер политики сети):

Для завершения установки роли, нажимаем Установить и дожидаемся установки компонента, после чего нажимаем Завершить.

В Active Directory необходимо создать группу безопасности (прим. NPS_Cisco) и включить в нее пользователей кому будет разрешена аутентификации на маршрутизаторах и коммутаторах Cisco.

Настройка Network Policy Server

Открываем оснастку Сервер политики сети (Network Policy Server).

Для полноценного использования функций NPS-сервера в домене, выполним регистрацию его в Active Directory. В оснастке на NPS (Локально), нажимаем правой кнопкой мыши и выбираем Зарегистрировать сервер в Active Directory (Register server in Active Directory):

Подтверждаем регистрацию сервера в Active Directory:

После регистрации NPS в Active Directory, добавим клиента RADIUS. На строке RADIUS-клиенты и серверы (RADIUS Clients and Servers) щелкаем правой кнопкой мыши и выбираем Новый документ (NEW):

Во вкладке «Параметры» вводим Понятное имя (Friendly name), IP-адрес (Address) и Общий секрет (Shared Secret). Во вкладке «Дополнительно» указываем Имя поставщика (Vendor name) — Cisco

Значение в поле Понятное имя (Friendly name) может отличаться от DNS имени. Оно потребуется нам в дальнейшем для идентификации конкретного сетевого устройства при создании политик доступа. Опираясь на это имя мы сможем задавать например маску по которой будут обрабатываться определённой политикой доступа несколько разных RADIUS клиентов.

Раскрываем ветку Политики (Policies) — Сетевые политики (Network Policies) и щелкаем правой кнопкой мыши и выбираем Новый документ (NEW):

Задаем Имя политики (Policy name), Тип сервера доступа к сети (Type of network access server) оставляем без изменения:

Задаем условия, которые должны соответствовать для успешной аутентификации. Создадим два условия:

Группы пользователей (указываем ранее созданную в Active Directory группу безопастности)
Понятное имя клиента (указываем дружественные имена, начинающиеся с префикса CISCO_)

Результат добавления условий:

Указываем разрешение доступа, оставляем значение Доступ разрешен (Access Granted).

Cisco поддерживает только методы Проверка открытым текстом (PAP, SPAP) (Unencrypted authentication (PAP, SPAP)). Снимите все флажки и отмечаем только Проверка открытым текстом (PAP, SPAP):

После настройки методов проверки подлинности вам будет предложено настроить Ограничения (Constraints), пропускаем этот раздел и переходим к следующему шагу.

Настройка параметров (Configure Settings), переходим в Атрибуты RADIUS (RADIUS Attributes) — Стандарт (Standard). Удаляем имеющиеся там атрибуты и нажимаем Добавить… (Add…)

Тип доступа выбираем Service-Type, нажимаем Добавить, выставляем значение атрибута Login

переходим в Атрибуты RADIUS (RADIUS Attributes) — Зависящие от поставщика (Vendor Specific), добавляем новый атрибут, и нажимаем Добавить… (Add…)

В пункте Поставщик (Vendor), указываем Cisco и нажимаем Добавить… (Add…). Будет предложено добавить сведения об атрибуте, нажимаем Добавить… (Add…) и устанавливаем значение атрибута:

В итоге должно получится как изображено ниже. Нажимаем Далее (Next).

Представление сводки новой политики, которая была сформирована. Нажимаем Готово (Finish):

После создания политики, можно переходить к настройке маршрутизаторов и коммутаторов Cisco для аутентификации на сервере Radius NPS.

Настройка Cisco IOS AAA

Сперва настроим локальную учетную запись (прим. admin), на случай выхода из строя RADIUS-сервера, выполняем команды:

cisco>enable

cisco#config terminal

cisco(config)#username admin priv 15 secret Aa1234567

Выполняем последовательность действий по добавлению RADIUS-сервера:

Включаем режим AAA
Добавляем RADIUS-сервер
Настраиваем профиль аутентификации (сперва RADIUS-сервер, если он не доступен, то тогда локальные учетные записи)
Настраиваем профиль авторизации (сперва RADIUS-сервер, если он не доступен, то тогда локальные учетные записи)
Включаем аутентификацию на интерфейсах

Пример настройки на Cisco 2911/K9 15.0(1r)M12

cisco(config)#aaa new-model

cisco(config)#radius server NPS

cisco(config-radius-server)#address ipv4 10.10.10.1 auth-port 1645 acct-port 1646

cisco(config-radius-server)#key CISCO

cisco(config-radius-server)#exit

cisco(config)#aaa group server radius NPS

cisco(config-sg-radius)#server name NPS

cisco(config-sg-radius)#exit

cisco(config)#aaa authentication login NPS group NPS local

cisco(config)#aaa authorization exec NPS group NPS local

cisco(config)#aaa authorization console

cisco(config)#line console 0

cisco(config-line)#authorization exec NPS

cisco(config-line)#login authentication NPS

cisco(config)#line vty 0 4

cisco(config-line)#session-timeout 30

cisco(config-line)#authorization exec NPS

cisco(config-line)#login authentication NPS

cisco(config-line)#transport input ssh

cisco(config)#line vty 5 15

cisco(config-line)#session-timeout 30

cisco(config-line)#authorization exec NPS

cisco(config-line)#login authentication NPS

cisco(config-line)#transport input none

Пример настройки на Cisco WS-C3750V2-48TS 12.2(55)SE5

cisco(config)#aaa new-model

cisco(config)#radius-server host 192.168.0.1 key Aa1234567

cisco(config)#aaa authentication login NPS group radius local

cisco(config)#aaa authorization exec NPS group radius local

cisco(config)#aaa authorization console

cisco(config)#line console 0

cisco(config-line)#authorization exec NPS

cisco(config-line)#login authentication NPS

cisco(config)#line vty 0 4

cisco(config-line)#session-timeout 30

cisco(config-line)#authorization exec NPS

cisco(config-line)#login authentication NPS

cisco(config-line)#transport input ssh

cisco(config)#line vty 5 15

cisco(config-line)#session-timeout 30

cisco(config-line)#authorization exec NPS

cisco(config-line)#login authentication NPS

cisco(config-line)#transport input none

Это минимальная настройка аутентификации/авторизации на маршрутизаторах/коммутаторов Cisco.

Понравилась или оказалась полезной статья, поблагодари автора

Тест стандарта Wi-Fi 802.11r в реальных условиях. Работа с протоколом RADIUS

Технологии развиваются и высокоскоростным интернетом уже никого не
удивишь. 4G-сети уже предоставляют среднюю скорость передачи данных до 100
Мбит в секунду, а после 2020 года мировые производители
телекоммуникационного оборудования начнут внедрять стандарты,
поддерживающие скорость передачи данных до 1Гбит в секунду.

Wi-Fi-сети не исключение. Стандарт 802.11 AC предполагает скорость
передачи данных (пропускная способность сети)
до 6,77 Гбит в секунду, при определенных условиях и оборудовании,
естественно.

Коммерческий и потребительский сектор при относительно небольших вложениях
уже может получить скорость сети около 1 Гбит в секунду, чего достаточно
для большинства задач.

В связи с этим логично, что все больше наших клиентов обращаются к нам с
задачей «организовать Wi-Fi сеть для…». А вот далее варианты различны.
Беспроводная сеть может быть для систем автоматизации склада, для работы в
терминальной среде или клиент хочет полностью отказаться от стационарных
ПК в пользу мобильности. Каждая задача решается по-разному и требуется
различный тип оборудования, но есть несколько критериев, идентичных для
всех запросов – «бесшовный роуминг» и безопасность. Эти критерии мы
и хотели обсудить в данной статье.

Бесшовный роуминг

Роумингом называется процесс перемещения клиентского устройства от
одной точки доступа до другой в пространстве. Чем больше мы отдаляемся от
точки доступа, тем больше ослабевает уровень сигнала и растут канальные
ошибки — вплоть до потери связи.

Бесшовный роуминг подразумевает наличие в сети нескольких Wi-Fi
точек доступа с одним SSID. При соблюдении этих требований произойдет
автоматическое переключение. Но вот будет ли оно бесшовным? Остановится ли
закачка файла при переключении? Прервется ли голос при разговоре по IP
телефонии?

Безопасность

На текущий момент существует два основных стандарта безопасности
беспроводных сетей — WPA2 + AES и WPA2 Enterprise + EAP. Сам протокол EAP
имеет несколько типов (EAP-TLS, EAP-FAST и т.д.).
Мы в своем тестированиии используем метод PEAP. Устаревшие
стандарты WPA и WEP, а также метод шифрования TKIP описывать не будем. Все
больше производителей оборудования отказываются от данных стандартов, так
как они сильнее всего подтверждены взлому.

WPA2 – personal (WPA2-PSK) + AES. При применении данного режима,
необходимо вводить один пароль для каждого сегмента сети (точки доступа,
беспроводные мосты и т.д). В октябре 2017 года был подвержен уязвимости
KRACK.

WPA2 – enterprise. Стандарт безопасности корпоративного сектора.
Подразумевает наличие в сети сервера авторизации. Почти всегда это
RADIUS сервер. Основная суть стандарта заключается в том, что для
каждого отдельного устройства или пользователя используется свой ключ
авторизации или сертификат. Этот ключ может обновляться с течением
времени без разрыва соединения, а за его генерацию отвечает RADIUS. При
успешной авторизации радиус сервер способен передать точке доступа такие
параметры как: IP адрес абонента, номер VLAN, и т.д.)

802.11r

Компания Ubiquity внедрила в свой Unifi-контроллер поддержку стандарта
802.11r, на момент написания материала поддержка в статусе beta. Этот
стандарт призван минимизировать потери данных (по сути является бесшовным
роумингом) при переключении клиента с точки на точку. Основные
преимущества нового стандарта получат независимые устройства без
контроллера.

Цель испытаний

Произвести испытания стандарта 802.11r в полевых условиях используя
оборудование Unifi со следующими параметрами:

WPA2 PSK + AES + 802.11r.
Цель — выяснить есть ли
практический смысл использования стандарта для сетей с общим ключом.

WPA2 — Enterprise + EAP + RADIUS.
Цель — выяснить каково
время переключения клиента без 802.11r.

WPA2 — Enterprise + EAP + 802.11.r
Цель — выяснить каково
время переключения клиента с активированным 802.11r.

В данном тестировании мы не затрагиваем вопросы безопасности
технологии, не используем сертификат выданный ЦС.

Состав тестового стенда

Оборудование Unifi:
- Unifi Cloud Key
- Unifi AP-AC-In Wall – 3 шт.

Windows Server 2016 Standard со службами:
- AD
- NPS
- Служба сертификации AD

Ноутбук c ОС WIN 10. Сетевая карта Intel AC 8260

ПО для радиообследоания Tamograph Site Surway

Трафик создаем командой ping -t -l 1000

Методика испытаний

Производим радиочастотное обследование с помощью Tamograph Site Surway.
Убеждаемся, что проблем с построением Wi-Fi-сети нет.

Производим настройку RADIUS-сервера. Сервер авторизации базируется на
Windows. Выбор обусловлен относительной простотой развертывания и
популярности ОС на рынке. В настройках центра сертификации используем
корневой самоподписанный сертификат. Авторизация в RADIUS происходит,
используя доменные учетные записи. Учетных записей две.

Конфигурируем Unifi-контроллер. Добавляем данные RADIUS в настройки
SSID. Создаем несколько SSID для тестирования:
- ent r – WPA – Enterprise + 802.11r
- ent no r — WPA – Enterprise
- wpa r – WPA2 PSK + 802.11r
- wpa no r — WPA2 PSK

IP-телефония. В данном случае тест субъективный. Мы используем мобильный
телефон и ПО для IP-телефонии. «На том конце» включаем удержание вызова
и «слушая музыку» перемещаемся по помещению. Далее повторяем тест, но
уже передвигаясь и общаясь по телефону.

RDP-соединение. На ноутбуке запускаем удаленный сервер и перемещаемся по
помещению.

Производим замеры. Начинаем генерировать трафик ping -t -l
1000.Тестировать заголовки объемом до 50 байт не представляет интереса.
Будем считать , что 1000 байт условно средний размер пакета. Испытания
проводим 4 раза. Результаты фиксируем.

Испытания по этапам

Этап 1. Проведение радио обследования объекта

Для проведения обследования используем ПО Tamograph Site Surway.

Схема 1. Обследование

На плане изображены три точки доступа с разными уровнями сигнала. Данное
помещение является многоуровневым, потому одна точка может обслуживать два
этажа. Из данного графика мы видим, что помещение полностью покрывается
сетью, проблемные зоны отсутствуют.

Этап 2. Подготовка RADIUS

Создаем двух пользователей и группу Wi-Fi, куда добавляем пользователей.
Повышаем роль сервера до КД.

Схема 2. Роли

Схема 3. Active directory

Схема 4.NPS (Сервер сетевых политик)

В данном окне необходимо добавить все ТД, которые будут общаться с Radius
сервером. Можно задать шаблон из общего секретного ключа.

Схема 5. Политики подключения.

Здесь стоит обратить внимание на то, что метод авторизации EAP в нашем
случае по паролю. При добавлении пункта авторизации по «смарт-карте или
иному сертификату» вам потребуется сертификат ЦС.

Этап 3. Подготовка Unifi-контроллера

Схема 6. Создаем профиль Radius

В поле IP указываем адрес нашего сервера, порт не меняем, пароль – общий
ключ который мы указывали для ТД на схеме 4.

Схема 7. Настройка SSID

Выбираем пункт WPA enterprise, ранее созданный профиль RADIUS и активируем
маркер fast roaming.

Подготовительные работы завершены.

Этап 4. Тестирование

Тестирование «ent r – WPA – Enterprise + 802.11r»

Схема 8. Момент переключения на вторую точку доступа

Видео 1. Демонстрация тестирования «ent r – WPA – Enterprise +
802.11r»

Тестирование «ent no r — WPA – Enterprise»

Схема 9. Момент переключения на вторую точку доступа

Схема 10. Момент переключения на третью точку доступа

Видео 2. Демонстрация тестирования «ent no r — WPA – Enterprise»

Тестирование «wpa r – WPA2 PSK + 802.11r»

Схема 11. Момент переключения на вторую точку доступа

Видео 3. Демонстрация тестирования «wpa r – WPA2 PSK + 802.11r»

Тестирование «wpa no r — WPA2 PSK + 802.11r»

Схема 12. Момент переключения на вторую точку доступа

Схема 13. Момент переключения на третью точку доступа

Видео 4. Демонстрация тестирования «wpa no r — WPA2 PSK + 802.11r»

Тестирование голосовых вызовов

Испытания проводились уже после всех основных замеров. Мы использовали
все четыре ранее созданных SSID. При следовании по маршруту (как
показано на видео) в момент потери пакета происходила деформация
слова. Сказать, что при этом теряется смысл нельзя. При активированном
режиме ожидании, проигрываемая музыка так же искажалась на доли
секунды.

Тестирование RDP-соединения

При перемещении по маршруту соединение не прерывалось. В теории, можно
было заметить микрофриз в момент переключения. На работу это не
влияет.

Заключение и выводы

Таблица 1. Выводы

	Потери пакетов ping -t -l 1000	Прерывание скачивания	Отключение RDP	Голосовые вызовы
WPA – Enterprise + 802.11r	1	не произойдет	не произойдет	Присутствует деформация слова при переключении с точки на точку.
WPA – Enterprise	2
WPA2 PSK + 802.11r	1
WPA2 PSK	2

Сегодняшнее тестирование дало неоднозначные результаты:

При использовании оборудования Unifi, роуминг между точками доступа
работает и без включения стандарта 802.11r. Как в случае с WPA2, так и
WPA2 — Enterprise. Переключение клиентов происходит с минимальной
потерей пакетов, в нашем случае один при включенном стандарте, и два
пакета при выключенном 802.11r.

RDP-соединение не переподключается при переключении, что ожидаемо
(переподключения происходят при потерях от 5 — 8 пакетов).

Голосовые вызовы переключаются без ощутимого дискомфорта. Звонок не
прерывается как при включенном стандарте, так и при выключенном.

Стоит ли внедрять новый стандарт?

Если ваша инфраструктура состоит из независимых точек доступа, то
рекомендуем обновить ПО оборудования до последней версии. При активации
802.11r, вы заметите ощутимые улучшения. Тестирование компании Zyxel это
подтверждает.

Если вы строите систему с нуля, и вы точно знаете, что будет больше
одной точки доступа, стоит присмотреться к оборудованию Ubiqity, учитывая, что ценник весьма
гуманный.

сервер сетевой политики (NPS) | Документы Microsoft

20.06.2018
Читать 12 минут

В этой статье

Применимо к: Windows Server (полугодовой канал), Windows Server 2016, Windows Server 2019

Этот раздел можно использовать для обзора сервера сетевой политики в Windows Server 2016 и Windows Server 2019.Сервер политики сети устанавливается при установке функции сетевой политики и доступа (NPAS) в Windows Server 2016 и Server 2019.

Примечание

Помимо этого раздела доступна следующая документация NPS.

Сервер политики сети

(NPS) позволяет создавать и применять политики доступа к сети в масштабах всей организации для проверки подлинности и авторизации запросов на подключение.

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

NPS позволяет централизованно настраивать и управлять проверкой подлинности, авторизации и учета сетевого доступа со следующими функциями:

Сервер RADIUS . NPS выполняет централизованную проверку подлинности, авторизацию и учет для беспроводных подключений, коммутаторов с проверкой подлинности, удаленного доступа и подключений к виртуальной частной сети (VPN). При использовании NPS в качестве сервера RADIUS вы настраиваете серверы доступа к сети, такие как точки беспроводного доступа и серверы VPN, в качестве клиентов RADIUS в NPS.Вы также настраиваете сетевые политики, которые NPS использует для авторизации запросов на подключение, и вы можете настроить учет RADIUS так, чтобы NPS регистрировал учетную информацию для файлов журнала на локальном жестком диске или в базе данных Microsoft SQL Server. Для получения дополнительной информации см. RADIUS-сервер.
RADIUS прокси . При использовании NPS в качестве прокси-сервера RADIUS вы настраиваете политики запросов на подключение, которые сообщают NPS, какие запросы на подключение перенаправлять на другие серверы RADIUS и на какие серверы RADIUS вы хотите пересылать запросы на подключение.Вы также можете настроить NPS для пересылки учетных данных, которые будут регистрироваться одним или несколькими компьютерами в группе удаленных серверов RADIUS. Чтобы настроить NPS в качестве прокси-сервера RADIUS, см. Следующие разделы. Дополнительные сведения см. В разделе Прокси-сервер RADIUS.
Учет RADIUS . Вы можете настроить NPS для регистрации событий в локальном файле журнала или в локальном или удаленном экземпляре Microsoft SQL Server. Дополнительные сведения см. В разделе Ведение журнала NPS.

Важно

Защита доступа к сети (NAP), Центр регистрации работоспособности (HRA) и Протокол авторизации учетных данных узла (HCAP) устарели в Windows Server 2012 R2 и недоступны в Windows Server 2016.Если у вас есть развертывание NAP с использованием операционных систем более ранних версий, чем Windows Server 2016, вы не можете перенести развертывание NAP на Windows Server 2016.

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

Windows Server Editions и NPS

Сервер политики сети

предоставляет различные функции в зависимости от устанавливаемого выпуска Windows Server.

Windows Server 2016 или Windows Server 2019 Standard / Datacenter Edition

С помощью NPS в Windows Server 2016 Standard или Datacenter вы можете настроить неограниченное количество клиентов RADIUS и удаленных групп серверов RADIUS. Кроме того, вы можете настроить клиентов RADIUS, указав диапазон IP-адресов.

Примечание

Функция WIndows Network Policy and Access Services недоступна в системах, установленных с опцией установки Server Core.

В следующих разделах представлена более подробная информация о NPS как сервере RADIUS и прокси-сервере.

RADIUS-сервер и прокси

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

RADIUS-сервер

NPS — это реализация Microsoft стандарта RADIUS, указанного Инженерной группой Интернета (IETF) в RFC 2865 и 2866. В качестве сервера RADIUS NPS выполняет централизованную аутентификацию соединения, авторизацию и учет для многих типов доступа к сети, включая беспроводной , коммутатор с проверкой подлинности, удаленный доступ по телефонной линии и виртуальной частной сети (VPN), а также соединения между маршрутизаторами.

NPS позволяет использовать разнородный набор оборудования для беспроводной связи, коммутатора, удаленного доступа или VPN. Вы можете использовать NPS со службой удаленного доступа, которая доступна в Windows Server 2016.

NPS использует домен доменных служб Active Directory (AD DS) или локальную базу данных учетных записей пользователей Security Accounts Manager (SAM) для проверки подлинности учетных данных пользователя при попытках подключения. Когда сервер, на котором работает NPS, является членом домена AD DS, NPS использует службу каталогов в качестве своей базы данных учетных записей пользователей и является частью решения для единого входа.Тот же набор учетных данных используется для управления доступом к сети (проверка подлинности и авторизация доступа к сети) и для входа в домен AD DS.

Примечание

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

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

Сервер RADIUS имеет доступ к информации учетной записи пользователя и может проверять учетные данные для аутентификации сетевого доступа. Если учетные данные пользователя аутентифицированы и попытка подключения авторизована, сервер RADIUS разрешает доступ пользователей на основе указанных условий, а затем регистрирует подключение для доступа к сети в журнале учета.Использование RADIUS позволяет собирать и хранить данные аутентификации, авторизации и учета пользователей сетевого доступа в центральном месте, а не на каждом сервере доступа.

Использование NPS в качестве сервера RADIUS

NPS можно использовать в качестве сервера RADIUS, когда:

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

На следующем рисунке NPS показан как сервер RADIUS для различных клиентов доступа.

RADIUS прокси

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

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

Использование NPS в качестве прокси-сервера RADIUS

Вы можете использовать NPS в качестве прокси-сервера RADIUS, когда:

Вы — поставщик услуг, который предлагает услуги удаленного доступа к телефонной линии, VPN или беспроводной сети нескольким клиентам.Ваши NAS отправляют запросы на соединение прокси-серверу NPS RADIUS. На основе части области имени пользователя в запросе на подключение прокси-сервер NPS RADIUS перенаправляет запрос на подключение на сервер RADIUS, который обслуживается клиентом и может аутентифицировать и авторизовать попытку подключения.
Вы хотите обеспечить проверку подлинности и авторизацию для учетных записей пользователей, которые не являются членами домена, членом которого является NPS, или другого домена, имеющего двустороннее доверие с доменом, участником которого является NPS.Сюда входят учетные записи в ненадежных доменах, односторонних доверенных доменах и других лесах. Вместо того, чтобы настраивать серверы доступа для отправки запросов на подключение к серверу NPS RADIUS, вы можете настроить их на отправку запросов на подключение прокси-серверу NPS RADIUS. Прокси-сервер NPS RADIUS использует часть имени области, относящуюся к имени пользователя, и перенаправляет запрос на NPS в правильном домене или лесу. Попытки подключения для учетных записей пользователей в одном домене или лесу могут быть аутентифицированы для NAS в другом домене или лесу.
Вы хотите выполнить аутентификацию и авторизацию, используя базу данных, которая не является базой данных учетной записи Windows. В этом случае запросы на подключение, соответствующие указанному имени области, перенаправляются на сервер RADIUS, который имеет доступ к другой базе данных учетных записей пользователей и данных авторизации. Примеры других пользовательских баз данных включают базы данных Novell Directory Services (NDS) и языка структурированных запросов (SQL).
Вы хотите обработать большое количество запросов на подключение.В этом случае вместо настройки клиентов RADIUS для попытки сбалансировать их запросы на соединение и учет между несколькими серверами RADIUS, вы можете настроить их для отправки запросов на подключение и учет на прокси-сервер NPS RADIUS. Прокси-сервер NPS RADIUS динамически балансирует нагрузку запросов на соединение и учет между несколькими серверами RADIUS и увеличивает обработку большого количества клиентов RADIUS и аутентификации в секунду.
Вы хотите обеспечить аутентификацию и авторизацию RADIUS для внешних поставщиков услуг и минимизировать конфигурацию межсетевого экрана в интрасети.Брандмауэр интрасети находится между сетью периметра (сеть между интрасетью и Интернетом) и интрасетью. Размещая NPS в сети периметра, брандмауэр между сетью периметра и интрасетью должен разрешать поток трафика между NPS и несколькими контроллерами домена. При замене NPS прокси-сервером NPS брандмауэр должен разрешать только трафик RADIUS между прокси-сервером NPS и одним или несколькими NPS в вашей интрасети.

На следующем рисунке показан сервер политики сети как прокси-сервер RADIUS между клиентами RADIUS и серверами RADIUS.

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

Конфигурации

NPS можно создать для следующих сценариев:

Беспроводной доступ
Организация удаленного доступа по телефонной линии или виртуальной частной сети (VPN)
Внешний коммутируемый или беспроводной доступ
Доступ в Интернет
Доступ с аутентификацией к ресурсам экстрасети для деловых партнеров

Примеры конфигурации RADIUS-сервера и RADIUS-прокси

В следующих примерах конфигурации показано, как настроить NPS как сервер RADIUS и прокси-сервер RADIUS.

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

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

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

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

NPS с удаленным сопоставлением пользователей RADIUS с Windows . В этом примере NPS действует как сервер RADIUS и как прокси-сервер RADIUS для каждого отдельного запроса на подключение, перенаправляя запрос проверки подлинности на удаленный сервер RADIUS, используя локальную учетную запись пользователя Windows для авторизации. Эта конфигурация реализуется путем настройки атрибута Remote RADIUS to Windows User Mapping в качестве условия политики запросов на подключение. (Кроме того, учетная запись пользователя должна быть создана локально на сервере RADIUS с тем же именем, что и учетная запись удаленного пользователя, для которой выполняется проверка подлинности удаленным сервером RADIUS.)

Конфигурация

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

Стандартная конфигурация

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

Сервер RADIUS для коммутируемого доступа или VPN-подключений
RADIUS-сервер для 802.1X беспроводное или проводное соединение

Чтобы настроить NPS с помощью мастера, откройте консоль NPS, выберите один из предыдущих сценариев, а затем щелкните ссылку, открывающую мастер.

Расширенная конфигурация

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

Чтобы настроить NPS с помощью расширенной конфигурации, откройте консоль NPS, а затем щелкните стрелку рядом с Advanced Configuration , чтобы развернуть этот раздел.

Предоставляются следующие элементы расширенной конфигурации.

Настроить сервер RADIUS

Чтобы настроить NPS в качестве сервера RADIUS, необходимо настроить клиентов RADIUS, сетевую политику и учет RADIUS.

Инструкции по созданию этих конфигураций см. В следующих разделах.

Настроить прокси RADIUS

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

Инструкции по созданию этих конфигураций см. В следующих разделах.

Регистрация NPS

Ведение журнала

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

Чтобы настроить ведение журнала NPS, вы должны настроить, какие события вы хотите регистрировать и просматривать с помощью средства просмотра событий, а затем определить, какую другую информацию вы хотите регистрировать. Кроме того, вы должны решить, хотите ли вы регистрировать информацию об аутентификации и учете пользователей в текстовых файлах журнала, хранящихся на локальном компьютере, или в базе данных SQL Server на локальном или удаленном компьютере.

Для получения дополнительной информации см. Настройка учета сервера сетевой политики.

Windows Server 2008 R2 — настройка RADIUS для аутентификации Cisco ASA 5500

КБ ID 0000688

Проблема

На прошлой неделе я настраивал RADIUS-аутентификацию 2008 R2 для аутентификации удаленных VPN-клиентов на брандмауэре Cisco ASA.

Я скажу, что аутентификация Kerberos — это более простой в настройке LOT , так что вы можете сначала проверить это.

Решение

Шаг 1 Настройте ASA для аутентификации AAA RADIUS

1.Подключитесь к ASDM,> Конфигурация> VPN с удаленным доступом. > Локальные пользователи AAA> Группы серверов AAA.

2. В разделе Группа Сервер> Добавить.

3. Дайте группе имя и примите значения по умолчанию> ОК.

4. Теперь (с выбранной группой)> В нижнем разделе (Сервер)> Добавить.

5. Укажите IP-адрес и общий секрет, который ASA будет использовать с Сервером 2008 R2, выполняющим RADIUS> OK.

6. Применить.

Настройте AAA RADIUS из командной строки;

 aaa-server радиус протокола PNL-RADIUS
aaa-сервер PNL-RADIUS (внутренний) хост 172.16.254.223
  ключ 123456
  радиус-общий-pw 123456
  выход

Шаг 2 Настройте Windows 2012 Server, чтобы разрешить RADIUS

7. В Windows 2008 Server> Запустить диспетчер сервера> Роли> Добавить роль.

8. Если откроется страница приветствия> Далее> Выберите сервер сетевой политики и доступа> Далее> Далее.

9. Выберите «Сервер сетевой политики»> «Далее»> «Установить».

10. Закройте, когда закончите.

11. Пока все еще находится в Диспетчере серверов> Сетевая политика и сервер доступа> NPS (локальный).

12. Зарегистрируйте сервер в Active Directory> ОК> ОК.

13. Разверните «Клиенты и серверы RADIUS»> щелкните правой кнопкой мыши «Клиенты RADIUS»> «Создать».

14. Дайте брандмауэру понятное имя (запомните, что это такое, оно вам понадобится снова)> Укажите его IP> Введите общий секрет, который вы установили выше (номер 5)> ОК.

15. Разверните политики> щелкните правой кнопкой мыши «Политики запросов на подключение»> «Создать»> дайте политике имя> «Далее».

16. Добавьте условие> Задайте для условия «Удобное для клиента имя»> Добавить.

17. Укажите имя, которое вы установили выше (номер 14)> ОК> Далее> Далее> Далее.

18. Измените атрибут на «Имя пользователя»> «Далее»> «Готово».

19. Теперь щелкните правой кнопкой мыши «Сетевые политики»> «Создать»> «Дайте политике имя»> «Далее».

20. Добавьте условие> Группы пользователей> Добавить.

21. Добавьте группу безопасности AD, к которой вы хотите разрешить доступ> OK> Далее> Далее.

22. Выберите « Незашифрованная аутентификация PAP SPAP »> Далее> Нет> Далее> Далее> Готово.

Шаг 3 Проверка аутентификации RADIUS

23. Вернувшись в ASDM, на той же странице, на которой вы были ранее, выберите свой сервер и нажмите «Test».

24. Измените выбор на Аутентификация> Введите учетные данные домена> ОК.

25. Вы ждете успешного исхода.

Примечание : если не удается проверить наличие физического соединения между двумя устройствами, общие секреты совпадают. Также убедитесь, что порты UDP 1645 и 1646 не заблокированы.

Для проверки аутентификации AAA RADIUS из командной строки

 проверка аутентификации aaa-сервера Хост PNL-RADIUS 172.16.254.223 имя пользователя petelong пароль пароль123

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

Статьи по теме, ссылки, источники или внешние ссылки

Windows Server 2003 — настройка RADIUS для аутентификации Cisco ASA 5500

Windows Server 2012 — настройка RADIUS для аутентификации Cisco ASA 5500

Апрель 2024
Пн	Вт	Ср	Чт	Пт	Сб	Вс
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

Настройка radius windows server 2020 r2: Настройка двухфакторной аутентификации на сервере Network Policy Server · Мультифактор

Настройка двухфакторной аутентификации на сервере Network Policy Server · Мультифактор

Общая информация

Видео-презентация

Схема работы

Схема потоков данных

Последовательность

Настройка Мультифактора

Настройка компонента MultiFactor Radius Adapter

Журналы

Настройка NPS

Radius Server

Radus Client

Политики подключений

Настраиваем доменную аутентификацию на сетевом оборудовании

Установка и настройка сервера с ролью Network Policy Server

Настройка сетевого оборудования для работы с сервером RADUIS

Настройка 802.1X на коммутаторах Cisco с помощью отказоустойчивого NPS (Windows RADIUS with AD)

WiFi Enterprise. FreeRadius + FreeIPA + Ubiquiti / Хабр

Немного о методах EAP

FreeRADIUS

Контроллер Ubiquiti

Настройка клиентов

Windows 10

Linux

Android

non-Samsung

Samsung

macOS

iOS

Возможные вопросы

Бесшовный роуминг и встроенный RADIUS-сервер: настройка!

Настройка бесшовного роуминга и встроенный RADIUS-сервер на оборудовании EdimaxPRO

См. также:

Настройка Radius аутентификации с Windows Server 2012 NPS (Network Policy Server) на Cisco IOS

Добавление роли, настройка Active Directory

Настройка Network Policy Server

Настройка Cisco IOS AAA

Пример настройки на Cisco 2911/K9 15.0(1r)M12

Пример настройки на Cisco WS-C3750V2-48TS 12.2(55)SE5

Понравилась или оказалась полезной статья, поблагодари автора

Тест стандарта Wi-Fi 802.11r в реальных условиях. Работа с протоколом RADIUS

Бесшовный роуминг

Безопасность

802.11r

Цель испытаний

Состав тестового стенда

Методика испытаний

Испытания по этапам

Этап 1. Проведение радио обследования объекта

Этап 2. Подготовка RADIUS

Этап 3. Подготовка Unifi-контроллера

Этап 4. Тестирование

Заключение и выводы

Сегодняшнее тестирование дало неоднозначные результаты:

Стоит ли внедрять новый стандарт?

сервер сетевой политики (NPS) | Документы Microsoft

В этой статье

Windows Server Editions и NPS

Windows Server 2016 или Windows Server 2019 Standard / Datacenter Edition

RADIUS-сервер и прокси

RADIUS-сервер

Использование NPS в качестве сервера RADIUS

RADIUS прокси

Использование NPS в качестве прокси-сервера RADIUS

Примеры конфигурации RADIUS-сервера и RADIUS-прокси

Конфигурация

Стандартная конфигурация

Расширенная конфигурация

Настроить сервер RADIUS

Настроить прокси RADIUS

Регистрация NPS

Windows Server 2008 R2 — настройка RADIUS для аутентификации Cisco ASA 5500

Проблема

Решение

Шаг 1 Настройте ASA для аутентификации AAA RADIUS

Шаг 2 Настройте Windows 2012 Server, чтобы разрешить RADIUS

Шаг 3 Проверка аутентификации RADIUS

Для проверки аутентификации AAA RADIUS из командной строки

Статьи по теме, ссылки, источники или внешние ссылки