Настройка radius сервера: RADIUS — немного о Mikrotik, NPS и не только / Хабр

Содержание

RADIUS — немного о Mikrotik, NPS и не только / Хабр

  • Цель статьи

  • Определение

  • Компоненты

  • Общие понятия

  • Сфера применения  

    • login  

    • VPN (ppp*)  

    • wifi

    • dot1x  

    • ipsec

  • диагностика

  • выводы

Цель

Цель данной статьи — объяснить логику работы радиуса в примерах, избавить от боязни и иллюзии сложности использования.

Changelog

24.01.2021 — Добавлено про Wifi +Vlan
21.10.2021 — Добавлено про ipsec eap

Определение, назначение, общие сведения

RADIUS — это протокол, для авторизации, аутентификации и учёта (AAA).

Позволяет повысить безопасность сети и централизованно управлять доступами.

Сервер RADIUS может иметь свою базу данных с учетными данными (например файлы или mysql) или работать в паре с другим сервером, например Active Directory.

Кроме AAA позволяет передать некоторые дополнительные данные (настройки) клиенту прошедшему аутентификацию, в том числе vendor-specific attributes (VSA). У Mikrotik такие тоже есть, позже пройдемся по самым интересным.

Существуют много популярных приложений радиус сервера, самый популярные: freeRADIUS и Служба NPS (Network Policy Server) Windows Server. Более подробно мы рассмотрим второй вариант.

Компоненты кейса

  • Суппликант — устройство которое намерено пройти процедуру авторизации и аутентификации.

  • Аутентификатор — устройство к которому подключается суппликант, которое получает у суппликанта данные авторизации и которое проверяет их на RADIUS сервере. NB! Является клиентом для радиус-сервера.

  • RADIUS сервер (он же радиус сервер, он же сервер аутентификации).

Настройка

Установку роли описывать не буду, существует 100500 статей в картинках, например: тыц

  1. Добавление радиус клиента на радиус-сервере. Нам нужно заполнить «понятное имя», IP адрес и придумать пароль (а.к.а. «секрет»), который понадиобится при настройке аутентификатора (mikrotik в нашем случае)

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

    Политики имеют порядок и обрабатываются по нему одна за другой. Если подключение не соответствует условиям политики, то проверяется следущая и так далее. К примеру, это поможет разделить правила обработки для проводных\беспроводных и впн клиентов. {.is-warning}

  1. Добавление политики запросов на подключение

  2. Добавление сетевой политики

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

  1. централизованная аутентификация на устройствах поддерживающих aaa

  2. аутентификация для vpn (pptp\l2tp)

  3. аутентификация в wifi

  4. аутентификация устройств при подключении к порту rj45 — dot802. 1x

 Итак подробнее, + некоторые плюшки.   Для всех наших пунктов нам нужно настроить радиус клиента в mikrotik

/radius add address=10.10.11.100 comment="PVE AD" secret=STRONG_SECRET_PASSWORD service=ppp,logi
n,hotspot,wireless,dhcp,ipsec,dot1x timeout=600ms

address —  Адрес радиус сервера secret — пароль, который мы совсем недавно настраивали для радиус клиента service — сервисы в mikrotik, которые могут использовать радиус для аутентификации.

Отдельно стоит отметить пункт timeout=600ms, если вы используете радиус через медленные каналы с большими задержками, стоит увеличить это значение.

Теперь можно начинать настраивать интересные вещи.

1. настроим вход на микротик

/user aaa
set accounting=yes default-group=read use-radius=yes

Стоит уделить внимание параметру default-group он означает группу по умолчанию, в которая применится к пользователю.

Теперь настроим NPS:

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

Обратимся к  Wiki mikrotik, мы можем заметить RADIUS атрибут, который позволяет определить доступы какой группы применятся к пользователю который аутентифицируется на устройстве через RADIUS. *Mikrotik-Group - Router local user group name (defines in /user group) for local users; HotSpot default profile for HotSpot users; PPP default profile name for PPP users. *  воспользовавшись промт'ом  мы понимаем что этот атрибут позволяет задать нам имя встроенной группы при авторизации , или задать имя профиля при аутентификации в сервисы vpn или hostspot. этот атрибут мы буем использовать и позже. что бы отделить мух от котлет при  авторизации для впн мы будем использовать дополнительные условия, но это позже.

итак, как мы этого добьемся … мы можем создать в System -> users -> group две группы со специфичными параметрами доступа, а можем и воспользоваться уже существующими, к примеру full и read.

Но все это ничего без второй части, нам необходимо настроить NPS. Давайте создадим в остнастке Пользователи и компьютеры Две группы пользователей admins-network и admins-junior. И два пользователя net-junior и net-admin,  добавим их в соответствующие группы.

Политику запроса на подключение мы уже создали, перейдем к сетевым политикам. в Оснастке NPS создадим две политики mikrotik-login-junior и mikrotik-admin-network , в условиях первой зададим :

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

 Сразу попробуем авторизоваться и видим что попали в нужную группу read  

В методах проверки подлинности указываем :

Политика mikrotik-admin-network будет отличаться тем что в условиях выберем группу admins-network а значение отрибута MIKROTIK_GROUP зададим как full Результат ожидаемый, мы залогинились в микротик под полными правами:

/user active print detail
Flags: R - RADIUS, M - by-romon
 0 R when=jan/05/2021 10:36:52 name="net-admin" address=10. 10.15.7 via=winbox
     group=full
 1 R when=jan/05/2021 10:37:04 name="net-admin" address=10.10.15.7 via=telnet
     group=full
Перейдем к впн, и к стразу более интересному сценарию.

Предположим мы хотим отделить админов, от остальных работников. Выдадим админам профиль с подсетью которая будет иметь доступ к management vlan и не только, и выдадим отстальным сотрудникам профиль с подсетью которая будет иметь ограниченый доступ только к 1c, RDP, etc.. . Предположим, мы используюем для впн l2tp\ipsec Для этого создадим в микротик два профиля в PPP -> profile

/ip pool add name=pool_l2tp_admin ranges=10.10.21.10-10.10.21.250
/ip pool add name=pool_l2tp_users ranges=10.10.22.10-10.10.22.250
/ppp profile add dns-server=10.10.21.1 local-address=10.10.21.1 name=l2tp-vpn-admin remote-address=pool_l2tp_admin use-compression=no use-encryption=yes
/ppp profile add dns-server=10.10.22.1 local-address=10.10.22.1 name=l2tp-vpn-users remote-address=pool_l2tp_users use-compression=no use-encryption=yes

В настройки правил форейвола для ограничения доступа подсетей я пожалуй не буду углубляться, подразумевается что вы понимаете как из одной подсети запретить доступ к ресурсу и как разрешить. (с)  предпологается, что вы немного сетевик. Касательно примера подсети 10.10.21.0/24 необходимо разрешить форвард в подсети серверов и management а подсети  10.10.22.0/24 необходимо разрешить только доступк корпоративным сервисам, но не к сетям управления.

Настроим NPS. В остнастке Пользователи и компьютеры создадим 2 группы пользователей vpn-admins и vpn-users, знакомого нам net-admin включим в 1ю группу, а net-buh во вторую. Политика запросов на подключение у нас будет использоваться та же. А политики сети созадим. В Условиях важно не только задать группу пользователей, но и тип порта NAS

Знакомым нам образом добавим атрибут указывающий какой профиль микротика использовать.

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

На вскидку полезными так же могут отказаться атрибуты : Mikrotik-Rate-Limit — для ограничения скорости vpn клиентов

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

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

Результат — пользователь получил ip из нужной подсети

Wifi и Dot1x

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

  • настроить службу центра сертификации Windows тыц, актуально и для следующего пункта

  • настроить GPO для распространения CA сертификата домена тыц

  • GPO  автоматического получения сертификата компьютера docs.microsoft

  • GPO включение службы dot1X (проводная автонастройка) и создать Политики проводных сетей (802.3) для выбора способа проверки подлинности тыц

  • GPO Автоматическое подключение к Wifi до логина пользователя тыц

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

wifi

Настройку WiFi каждый настраивает как ему удобно. Я к примеру, предпочитаю CapsMan, даже  если это будет единственная AP в сети. В любом случае нас интересует только Security Profile/Security Cfg.

Создадим политику сети: В условиях выберем Тип порта NAS = Беспроводная - IEEE 802.11

А в методах проверки подлинности следующее.

Если вы используете CapsMan + Bridge Vlan Filtering и хотите что бы при подключении пользователи попадали в указанный вами VLAN — нужно указать атрибут: Mikrotik-Wireless-VLANID.

Как понять что все получилось или что то идет не так )? — все просто в первую очередь идем в логи. Видим событие с подробной информацией кто куда и когда ходил и согласно какой политике получил  разрешение или отказ в доступе.

Какие радиус атрибуты могут быть нам полезны:

  • Framed-Pool — можем для отдельных групп пользователей использовать свой ip пул и выполнять какие то манипуляции на основе этого в форейволе

  • Filter-Id — применять какое то правило форейвола сразу к клиенту

  • Mikrotik-Wireless-VLANID — указать в какой vlan должен попасть клиент (Возможно, однажды,  по заявкам    пользователей я дополню статью примером с ипользованием vlan  в wifi) …

  • устанавливать лимиты по обьему или/и скорости трафика

  • и многие другие параметры из вики, либо их комбинации с условиями сетевой политики, смотря сколько у вас фантазии 🙂

dot1x

 Зачем нужен dot1X и как его настроить. . очень много интересных слов можно было бы тут написать, но все сказано до нас. Например на канале одного прекрасного тренера или wiki

Половина смысла с саркальной точки зрения в dot1x в том, что в случае успешной проверки подлинности наше устройство попадет в влан указанный нами в микротике или в влан который мы поличим в качестве атрибута у радиуса. Если проверка подлинности пройдет с отказом или ответ не будет получен от радиуса (например в случае его недоступности), то порт перейдет в изолироованный режим (будет заблокирован любой трафик на порту) или в случае если указан Reject VLAN ID то попадет в влан, для которого мы настроили(я надеюсь все таки настроили) максимально безопасные правила форейвола для чужеродных устройств .

Начнем с микротика:

Настроим политики сети: В условиях необходимо отобрать проводные клиенты

Параметры аутентификации:

В настройках атрибутами выдадим рабочий влан

К примеру вот так выглядит отказ в авторизации:

А вот так успешное подключение:

IPSEC

С недавнего времени стало популярно настраивать vpn через ipsec ikev2, но многих пугает морока с клиентскими сертификатами. В этом плане использовать учетные данные из AD гораздо удобнее.

Для начала включим в настроках добавленного радиус клиента что он будет использоваться для ipsec

Дефолтные конфиги в ipsec не принято трогать. поэтому будем создавать свои.

Создадим «группу конфигов»

/ip ipsec policy group add name=ipsec

Настроим Profile (фаза 1)

/ip ipsec profile add dh-group=modp1024 enc-algorithm=aes-192,3des name=ipsec

Создадим пир для входящих подключений

/ip ipsec peer add exchange-mode=ike2 name=ipsec passive=yes profile=ipsec send-initial-contact=no

Создадим настройки proposals (фаза 2)

/ip ipsec proposal add name=ipsec

Добавим пулл ip адресов которые будут выдаваться клиентам

/ip pool add name=pool1 ranges=10.20.0.10-10.20.0.250

Добавим Mod config, из которого клиенты получают префиксы подсетей за впн и dns

/ip ipsec mode-config add address-pool=pool1 name=ipsec split-include=0.0.0.0/0,10.20.0.0/16

Создадим шаблонную политику шифрования трафика

/ip ipsec policy add group=ipsec proposal=ipsec template=yes

Настроим аутентификацию vpn клиентов
Важный момент. нам все таки прийдется использовать сертификат.
Данный сертификат используется только для шифрования трафика между клиентом и впн сервером, и его нужно указать обязательно иначе будет появляться ошибка EAP neeeds certificate if EAP-only is not used.

Если планируете подключаться из windows машин в домене, то можете импортировать сертификат из своего CA и разлить его политикой на ноутбуки\компьютеры.
Если нет своего CA то можно сгенерировать сертификат на микротике. но тогда прийдется опять таки его импортировать на клиентах вручную или через GPO.
И на мой взгляд самый удобный способ, воспользоваться сертификатом letsecrypt, кстати в ros7 есть команда для автоматического получения сертификата.
Или приобрести коммерческий сертификат. У меня в примере Letsencrypt, обратите внимание что необходимо добавить так же все промежуточные сертификаты.

/ip ipsec identity add auth-method=eap-radius certificate=lefull,lefull_1,lefull_2 generate-policy=port-strict mode-config=ipsec peer=ipsec policy-template-group=ipsec

Добавляем политику на NPS сервере

В методах проверки подлинности разрешаем аутентификацию по паролю используюя ms-chap v2

После этого можно подключаться клиентом, все должно работать )
Если желательно расписать как настраивать клиента на mikrotik дайте знать )

Диагностика

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

  • логи mikrotik

    Идем в system logging add topics=radius,debug action=memory disabled=no и пробуем что то делать, в log print появятся записи связанные с радиусом. — логи Службы

  • политики сети и доступа  

    я уже приводил пример, еще раз — искать здесь, и читать внимательно сообщения  

  • возможны проблемы из за windows брандмауера починить можно

Get-NetFirewallRule -DisplayGroup "Сервер политики сети" | where DisplayName -like "*RADIUS*" | Set-NetFirewallRule -Service Any

или для англоязычной версии:

Get-NetFirewallRule -DisplayGroup "Network Policy Server" | where DisplayName -like "*RADIUS*" | Set-NetFirewallRule -Service Any

Тест:

echo "User-Name = USER,User-Password=PASSWORD,NAS-Port-Type=Virtual" | radclient -s 10.10.11.100:1812 auth SHARE_NPS_SECRET -x

Вывод программы:

Sent Access-Request Id 177 from 0. 0.0.0:42354 to 10.10.11.100:1812 length 56
       User-Name = "USER"
       User-Password = "PASSWORD"
       NAS-Port-Type = Virtual
       Framed-Protocol = PPP
       Cleartext-Password = "PASSWORD"
Received Access-Accept Id 177 from 10.10.11.100:1812 to 10.10.15.7:42354 length 94
       Mikrotik-Group = "pptp-nps"
       Framed-Protocol = PPP
       Service-Type = Framed-User
       Class = 0xa1cd098c00000137000102000a0a0b6400000000ec967e14be8346ce01d6d63b3e2ca9d70000000000000092
Packet summary:
       Accepted     : 1
       Rejected     : 0
       Lost         : 0
       Passed filter : 1
       Failed filter : 0

Выводы

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

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

Если в статье нашли ошибки, неточности или знаете как сделать лучше тоже пишите.

Благодарности:

Спасибо @aslancherkesov за злого редактора и свежий взгляд на буквы.

RADIUS сервера для аутентификации | Juniper Networks

Juniper Networks Ethernet-коммутаторы используют аутентификацию 802.1X, MAC-RADIUS или Captive Portal для обеспечения контроля доступа к устройствам или пользователям. Когда аутентификации 802.1X, MAC-RADIUS или Captive Portal настроены на коммутаторе, конечные устройства оцениваются при начальном подключении с помощью сервера аутентификации (RADIUS). Чтобы использовать аутентификацию 802.1X или MAC RADIUS, необходимо указать соединения на коммутаторе для каждого RADIUS сервера, к которому необходимо подключиться. Дополнительные сведения об этом разделе.

Указание RADIUS серверных подключений на коммутаторах (интерфейс командной строки процедура)

IEEE аутентификация 802.1X и MAC-RADIUS обеспечивает безопасность сети и защищает сети Ethernet LANs от несанкционированного доступа пользователя, блокируя весь трафик на интерфейсе и с устройств на интерфейсе до тех пор, пока учетные данные или MAC-адрес приложения не будут представлены и не будут совпаны на сервере аутентификации (RADIUS сервер). После аутентификации необходимого пользователя коммутатор прекращает блокирование доступа и открывает интерфейс для него.

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

Для настройки нескольких RADIUS, включив в себя radius-server несколько еконфигурирований. При настройке нескольких серверов доступ к серверам происходит в порядке настройки по умолчанию. Первый настроенный сервер является основным. Если основной сервер недостижим, маршрутизатор пытается достичь второго настроенного сервера и так далее. Можно загрузить баланс между запросами, сконфигурив метод round-robin. Серверы стараются по порядку и в порядке круговой проверки до получения допустимого ответа от одного из серверов или до тех пор, пока не будут достигнуты все настроенные пределы повторного запроса.

Прим.:

Метод кругового доступа не рекомендуется использовать с коммутаторами серии EX.

Можно также настроить полное доменное имя (FQDN), которое будет разрешать один или несколько IP-адресов. См. Указание RADIUS серверных подключений на коммутаторах (интерфейс командной строки процедура) .

Настройка сервера RADIUS на коммутаторе:

  1. Настройте IP-адрес сервера RADIUS, номер порта аутентификации RADIUS сервера и секретный пароль. Секретный пароль коммутатора должен совпадать с секретным паролем на сервере.

  2. (Необязательно) Укажите IP-адрес, по которому коммутатор идентифицирован RADIUS сервером. Если IP-адрес не указан, сервер RADIUS использует адрес интерфейса, который RADIUS запрос. Мы рекомендуем указать этот IP-адрес, поскольку, если запрос перенаправляется на альтернативный маршрут к серверу RADIUS, интерфейс, передающий запрос, может не быть интерфейсом на коммутаторе.

  3. Настройте порядок аутентификации, чтобы radius сделать первый метод аутентификации:

  4. (Необязательно) Настройте метод, который маршрутизатор использует для доступа RADIUS серверов аутентификации и учета при настройке нескольких серверов:

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

  6. Укажите группу серверов, которая будет использоваться для аутентификации 802.1X или MAC RADIUS путем идентификации имени профиля:

  7. Настройте IP-адрес коммутатора в списке клиентов на RADIUS сервере. Для получения сведений о настройке RADIUS сервера, обратитесь к документации для сервера.

Настройка сервера RADIUS с помощью FQDN

Можно настроить полное доменное имя (FQDN), которое будет разрешать один или несколько IP-адресов. Настройте сервер RADIUS, используя FQDN на уровне edit access radius-server-name hostname [] иерархии. Если FQDN обращается к нескольким адресам, доступ к серверам происходит в порядке настройки по умолчанию. Первый разрешенный адрес является основным сервером. Если первичный сервер недостижим, маршрутизатор пытается получить доступ к второму серверу и так далее. Можно загрузить баланс между запросами, сконфигурив метод round-robin. Серверы стараются по порядку и в порядке круговой проверки до получения допустимого ответа от одного из серверов или до тех пор, пока не будут достигнуты все настроенные пределы повторного запроса.

  1. Настройте FQDN сервера RADIUS, номер RADIUS аутентификации сервера и секретный пароль. Секретный пароль коммутатора должен совпадать с секретным паролем на сервере.

  2. (Необязательно) Настройте интервал для разрешения проблемы FQDN в качестве адреса сервера. FQDN динамически решается через фиксированные интервалы в зависимости от настроенного значения.

  3. (Необязательно) Укажите IP-адрес, по которому коммутатор идентифицирован RADIUS сервером. Если IP-адрес не указан, сервер RADIUS использует адрес интерфейса, который RADIUS запрос. Мы рекомендуем указать этот IP-адрес, поскольку, если запрос перенаправляется на альтернативный маршрут к серверу RADIUS, интерфейс, передающий запрос, может не быть интерфейсом на коммутаторе.

  4. Настройте порядок аутентификации, чтобы radius сделать первый метод аутентификации:

  5. (Необязательно) Настройте метод, который коммутатор использует для доступа RADIUS серверов аутентификации и учета при настройке нескольких серверов:

  6. Создайте профиль и укажите список RADIUS серверов, которые будут связаны с профилем. Например, можно выбрать группу серверов RADIUS географически по городу. Эта функция позволяет легко вносить изменения при изменении другого набора серверов аутентификации.

  7. Укажите группу серверов, которая будет использоваться для аутентификации 802. 1X или MAC RADIUS путем идентификации имени профиля:

  8. Настройте IP-адрес коммутатора в списке клиентов на RADIUS сервере. Для получения сведений о настройке RADIUS сервера, обратитесь к документации для сервера.

  • Настройка параметров интерфейса 802.1X (интерфейс командной строки процедуры)

  • Настройка аутентификации 802.1X (процедура J-Web)

  • Настройка аутентификации RADIUS MAC-интерфейс командной строки MAC-интерфейс командной строки)

  • Настройка учета 802.1X RADIUS (интерфейс командной строки)

Настройка MS-CHAPv2 для поддержки изменения пароля (интерфейс командной строки процедуры)

Junos OS для коммутаторов серии EX позволяет настроить microsoft Corporation реализацию протокола аутентификации challenge handshake version 2 (MS-CHAPv2) на коммутаторе для поддержки изменения пароля. Настройка MS-CHAPv2 на коммутаторе предоставляет пользователям доступ к коммутатору с возможностью изменения пароля по истечении срока действия пароля, при сбросе или изменении при следующем входе.

Информацию о MS-CHAP см. в RFC 2433, расширения CHAP Microsoft PPP.

Прежде чем настраивать MS-CHAPv2 для поддержки изменения пароля, убедитесь, что у вас есть:

Для настройки MS-CHAPv2 укажите следующее:

[edit system radius-options]
user@switch# set password-protocol mschap-v2

Для изменения пароля на коммутаторе необходимо иметь необходимое разрешение на доступ.

Настройка MS-CHAPv2 для поддержки изменения пароля

Прежде чем настраивать MS-CHAPv2 для поддержки изменения пароля, убедитесь, что вы сделали следующее:

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

Чтобы настроить MS-CHAP-v2, включим следующие утверждения на [edit system radius-options] уровне иерархии:

[edit system radius-options]
password-protocol mschap-v2;

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

[edit]
system {
    authentication-order [ radius password ];
    radius-server {
        192. 168.69.149 secret "$9$G-j.5Qz6tpBk.1hrlXxUjiq5Qn/C"; ## SECRET-DATA
    }
    radius-options {
        password-protocol mschap-v2;
    }
    login {
        user bob {
            class operator;
        }
    }
}

  • Настройка профилей доступа для параметров L2TP или PPP

Понимание переключения при сбойе сервера и аутентификации на коммутаторах

Juniper Networks Ethernet-коммутаторы используют аутентификацию для реализации контроля доступа в корпоративной сети. Если аутентификация 802.1X, MAC-RADIUS или Captive Portal настроена на коммутаторе, конечные устройства при начальном подключении оцениваются сервером аутентификации (RADIUS). Если конечное устройство настроено на сервере аутентификации, устройству предоставляется доступ к LAN, и коммутатор серии EX открывает интерфейс для разрешения доступа.

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

При выходе из строя сервера можно указать одно из четырех действий, которые необходимо принять для конечных устройств в ожидании аутентификации по и времени ожидания сервера. Коммутатор может принимать или отключать доступ кпроцентантам или поддерживать доступ, уже предоставленныйпротопросантам, до RADIUS и по иллюминатору. Можно также настроить коммутатор для перемещения запроцентов в определенную VLAN. VLAN уже должна быть настроена на коммутаторе. Настроенное имя VLAN переопределит все атрибуты, отправленные сервером.

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

  • Запретить аутентификацию, предотвращая поток трафика от о конечных устройств через интерфейс. Это значение по умолчанию.

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

  • Поддерживать аутентификацию конечных устройств, которые уже имеют доступ к ЛВС и отказывают в аутентификации конечных устройств. Если RADIUS серверы не могут выйти из времени во время повторной аутентификации, предварительно аутентификация конечных устройств будет повторно аутентификацией, и новым пользователям будет отказано в доступе к ЛОКАЛЬНОй сети.

  • Обзор 802.1X для коммутаторов

  • Примере: Настройка параметров аутентификации 802.1X, когда сервер RADIUS недоступен коммутатору серии EX

  • Примере: Настройка 802.1X для однопротофаксных или многопротофаксных конфигураций на коммутаторе серии EX

  • Настройка параметров интерфейса 802.1X (интерфейс командной строки процедуры)

Настройка RADIUS при сбойе сервера (интерфейс командной строки настройки)

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

После того, как на коммутаторе была настроена аутентификация 802.1X или MAC RADIUS, необходимо указать первичный сервер аутентификации и один или несколько серверов аутентификации. Если коммутатор не может получить доступ к основному серверу аутентификации, а вторичные серверы аутентификации также недоступны, RADIUS время простоя сервера. Если это происходит, поскольку сервер аутентификации предоставляет или отключает доступ к конечным устройствам в ожидании аутентификации, коммутатор не получает инструкций доступа для конечных устройств, пытающихся получить доступ к LAN, и обычная аутентификация не может быть завершена.

Функцию переключения при сном сервера можно настроить так, чтобы указать действие, которое коммутатор применяет к конечным устройствам в случае недоступности серверов аутентификации. Коммутатор может принимать или отключать доступ кпроцентантам или поддерживать доступ, уже предоставленныйпротопросантам, до RADIUS и по иллюминатору. Можно также настроить коммутатор для перемещения запроцентов в определенную VLAN.

Можно также настроить функцию отказа от сервера для конечных устройств, которые получают RADIUS доступа от сервера аутентификации. Функция отказа от сервера предоставляет ограниченный доступ к локальной сети (обычно только к Интернету) для адаптивных конечных устройств с поддержкой 802.1X и отправленных неверных учетных данных.

Сбой сервера поддерживается для голосового трафика, начиная с 14.1X53-D40 и 15.1R4. Для настройки действий по перепаду при сбойе сервера для клиентов VoIP, посылаемых голосовым трафиком, используйте server-fail-voip утверждение. Для всего трафика данных используйте server-fail утверждение. Метод перехода в другой коммутатор определяется типом трафика, отосланного клиентом. Необитируемые фреймы данных подвержены действию, настраиваемому с их помощью, даже если они server-fail посылаются клиентом VoIP. Маркируемые кадры VLAN VoIP подвержены действию, настроенном с server-fail-voip . Если server-fail-voip конфигурация не настроена, голосовой трафик отброшен.

Прим.:

Отказ от отказа сервера не поддерживается для трафика с тегами VoIP VLAN. Если клиент VoIP начинает аутентификацию с отправки непотагного трафика данных в VLAN, в то время как отказ от сервера действует, клиент VoIP получает доступ к сети VLAN, которая находится в непригодном для обработки сообщении. Если впоследствии тот же клиент отправляет маркированную голосовую трафик, голосовой трафик отброшен.

Если клиент VoIP начинает аутентификацию с отправки меченого голосового трафика, в то время как отказ от сервера действует, voIP-клиенту отказано в доступе к сети VLAN, которая находится в отказе.

Для настройки действий по обработке сбойов сервера для клиентов данных можно использовать следующую процедуру. Для настройки перепада при сбойе сервера для клиентов VoIP, отправляемых голосовым трафиком, используйте server-fail-voip утверждение, а не server-fail утверждение.

Для настройки действий по перепаду после сбойов сервера:

Можно настроить интерфейс, который получает от RADIUS доступа сообщение об отказе от аутентификации, для перемещения конечных устройств, пытающихся получить доступ к LAN на интерфейсе, в VLAN, отклоненную сервером, — заданную VLAN, уже настроенную на коммутаторе.

Для настройки сервера reject fallback VLAN:

  • Примере: Настройка параметров аутентификации 802.1X, когда сервер RADIUS недоступен коммутатору серии EX

  • Настройка параметров интерфейса 802.1X (интерфейс командной строки процедуры)

  • Мониторинг аутентификации 802.1X

Таблица истории выпусков

Версия

Описание

14.1X53-D40

Сбой сервера поддерживается для голосового трафика, начиная с 14.1X53-D40 и 15.1R4.

 

Настройка аутентификации RADIUS с помощью WPA2-Enterprise

  1. Последнее обновление
  2. Сохранить как PDF

Точки доступа Cisco Meraki MR предлагают ряд методов аутентификации для беспроводной связи, включая использование внешних серверов аутентификации для поддержки WPA2-Enterprise. В этой статье описывается конфигурация панели мониторинга для использования сервера RADIUS для проверки подлинности WPA2-Enterprise, требования к серверу RADIUS и пример конфигурации сервера с использованием Windows NPS.

Обзор

WPA2-Enterprise с аутентификацией 802.1X можно использовать для аутентификации пользователей или компьютеров в домене. Запрашивающая сторона (беспроводной клиент) проходит проверку подлинности на сервере RADIUS (сервере проверки подлинности) с использованием метода EAP, настроенного на сервере RADIUS. Роль точки доступа шлюза (аутентификатора) заключается в отправке сообщений аутентификации между запрашивающей стороной и сервером аутентификации. Это означает, что сервер RADIUS отвечает за аутентификацию пользователей.

Точки доступа выполняют обмены EAPOL между запрашивающей стороной и преобразуют их в сообщения RADIUS Access-requests, которые отправляются на IP-адрес сервера RADIUS и порт UDP, указанные в Dashboard. Точки доступа шлюза должны получить сообщение о принятии доступа RADIUS от сервера RADIUS, чтобы предоставить запрашивающей стороне доступ к сети.

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

На следующем изображении представлена ​​подробная разбивка процесса ассоциации PEAP с MSCHAPv2:

Поддерживаемые атрибуты RADIUS

При настройке WPA2-Enterprise с аутентификацией 802.1X в сообщениях Access-Request, отправляемых с точки доступа Cisco Meraki на клиентский RADIUS-сервер, присутствуют следующие атрибуты.

Примечание:  Подробнее об этих атрибутах см. в RFC 2865. Дополнительные примечания для некоторых атрибутов приведены ниже.

  • Имя пользователя
  • NAS-IP-адрес
  • NAS-порт
  • Идентификатор вызываемой станции: Содержит (1) BSSID точки доступа Meraki (все заглавные буквы, октеты разделены дефисами) и (2) SSID, к которому подключается беспроводное устройство. Эти 2 поля разделены двоеточием. Пример: «AA-BB-CC-DD-EE-FF:SSID_NAME».
  • Calling-Station-ID: Содержит MAC-адрес беспроводного устройства (все заглавные буквы, октеты разделены дефисами). Пример: «AA-BB-CC-DD-EE-FF».
  • Рамка-MTU
  • NAS-порт типа
  • Connect-Info
  • Meraki-Device-Name: имя устройства Meraki, настроенное на панели управления

    • .

 

Следующие атрибуты учитываются Cisco Meraki при получении сообщения Access-Accept от сервера RADIUS клиента к точке доступа Cisco Meraki:

  • Tunnel-Private-Group-ID: Содержит идентификатор VLAN, который должны применяться к беспроводному пользователю или устройству. (Это можно настроить для переопределения параметров VLAN, настроенных администратором для определенного SSID в облачном контроллере Cisco Meraki Cloud Controller.)
  • Tunnel-Type: Указывает протокол туннелирования. Пример: ВЛАН.
  • Tunnel-Medium-Type: Задает тип транспортного носителя, используемый для создания туннеля. Пример: 802 (включая 802.11).
  • Filter-Id / Reply-Message / Airespace-ACL-Name / Aruba-User-Role: Любой из этих атрибутов можно использовать для передачи политики, которая должна применяться к беспроводному пользователю или устройству. (Тип атрибута должен соответствовать типу, настроенному на вкладке «Настройка» > странице «Групповые политики» в облачном контроллере Cisco Meraki. Значение атрибута должно соответствовать имени группы политик, настроенной на этой странице.)

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

Наиболее распространенной конфигурацией EAP является PEAP с MSCHAPv2, который запрашивает у пользователей учетные данные (проверку подлинности пользователя или компьютера).

Примечание. Проверка подлинности на основе сертификата с использованием EAP-TLS также поддерживается платформой Meraki, но выходит за рамки этого документа. Дополнительные сведения о WPA2-Enterprise с использованием EAP-TLS см. в нашей документации.

Требования к серверу RADIUS

Для RADIUS доступно множество вариантов сервера, который при правильной настройке должен работать с точками доступа MR. Дополнительные сведения см. в документации к вашему RADIUS-серверу, но ключевые требования для WPA2-Enterprise с Meraki следующие:

  • На сервере должен быть размещен сертификат центра сертификации (ЦС), которому доверяют клиенты в сети.
  • Все точки доступа шлюза, транслирующие SSID WPA2-Enterprise, должны быть настроены как клиенты/аутентификаторы RADIUS на сервере с общим секретом.
  • Сервер RADIUS должен иметь базу пользователей для аутентификации.

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

Проверка подлинности пользователя и компьютера

Наиболее распространенным методом проверки подлинности с помощью PEAP-MSCHAPv2 является проверка подлинности пользователя, при которой клиентам предлагается ввести учетные данные своего домена. Также можно настроить RADIUS для проверки подлинности компьютеров, при которой сами компьютеры аутентифицируются с помощью RADIUS, поэтому пользователю не нужно предоставлять какие-либо учетные данные для получения доступа. Аутентификация компьютера обычно выполняется с помощью EAP-TLS, хотя некоторые параметры сервера RADIUS упрощают выполнение аутентификации компьютера с помощью PEAP-MSCHAPv2 (включая Windows NPS, как показано в приведенном ниже примере конфигурации).

Примечание. «Машинная аутентификация» — это , а не , то же самое, что и аутентификация на основе MAC-адреса, которая является еще одним параметром конфигурации на панели инструментов в разделе «Беспроводная связь» > «Настроить» > «Контроль доступа» . Проверка подлинности компьютера, в частности, относится к устройствам, проходящим проверку подлинности с помощью RADIUS 

Пример конфигурации RADIUS (Windows NPS + AD)

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

  1. Добавьте роль сервера политики сети (NPS) в Windows Server.
  2. Добавьте доверенный сертификат в NPS.
  3. Добавьте точки доступа в качестве клиентов RADIUS на сервере политики сети.
  4. Настройте политику в NPS для поддержки PEAP-MSCHAPv2.
  5. (необязательно для машинной аутентификации) Разверните параметры беспроводной сети PEAP-MSCHAPv2 на компьютерах-членах домена с помощью групповой политики.
Добавление роли сервера политики сети (NPS) в Windows Server

Сервер RADIUS от Microsoft для Windows Server 2008 и более поздних версий — это сервер политики сети (NPS). Обратитесь к следующим двум документам Microsoft за инструкциями по добавлению роли NPS в Windows Server и регистрации нового сервера NPS в Active Directory (что позволит ему использовать AD в качестве базы пользователей):

  • Установка NPS.
  • Регистрация NPS в AD.
Добавление доверенного сертификата в NPS

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

  • Получить сертификат от доверенного центра сертификации
    Если используемый ЦС является доверенным для клиентов в сети, сертификат можно приобрести и загрузить в NPS для выполнения идентификации сервера. верификация (требуется клиентами). Типичными примерами доверенных ЦС являются GoDaddy и VeriSign.
  • Внедрить инфраструктуру открытых ключей и создать сертификат (дополнительно)
    PKI можно использовать в сети для выдачи сертификатов, которым доверяют клиенты в сети. Для этого варианта рекомендуется хорошее понимание PKI.
  • Создание самозаверяющего сертификата и отключение проверки клиент-сервера (небезопасно)
    Самозаверяющий сертификат может быть создан для тестовых/лабораторных целей, хотя клиенты не будут доверять самозаверяющему сертификату и должны будут пройти проверку сервера отключен для подключения.
    Этот вариант , а не  рекомендуется для производственного развертывания из-за значительного снижения безопасности.

После получения сертификата обратитесь к документации Microsoft за инструкциями по импорту сертификата.

Добавить точки доступа в качестве клиентов RADIUS на сервере NPS

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

Чтобы быстро собрать IP-адреса локальной сети всех точек доступа шлюза, перейдите к Беспроводная связь > Монитор > Точки доступа  на панели управления, убедитесь, что столбец «IP-адрес локальной сети» добавлен в таблицу, и запишите все перечисленные IP-адреса локальной сети. Точки доступа с IP-адресом в локальной сети «Н/Д» являются ретрансляторами, их не нужно добавлять в качестве клиентов RADIUS:

 

После того, как список IP-адресов в локальной сети точек доступа шлюза будет собран, обратитесь к документации Microsoft. инструкции по добавлению каждой точки доступа в качестве клиента в NPS. Обратите внимание на общий секрет, настроенный в NPS, он будет указан на панели мониторинга.

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

Во многих случаях каждый аутентификатор RADIUS должен быть добавлен на сервер аутентификации RADIUS, такой как Microsoft NPS или Cisco ISE. Для концентрации VPN и концентрированных перемещаемых SSID уровня 3 на сервер аутентификации RADIUS необходимо добавить только концентраторы.

Настройте политику в NPS для поддержки PEAP-MSCHAPv2

Сервер политики сети должен быть настроен для поддержки PEAP-MSCHAPv2 в качестве метода аутентификации.

Это выполняется в три шага, описанных ниже для NPS в Windows Server 2008:

  1. Создание политики NPS
  2. Изменить порядок обработки политики
  3. Отключить автоматическое исправление

Создание политики NPS

  1. Откройте консоль сервера политики сети.
  2. Выберите NPS (локальный), , чтобы отобразить панель Начало работы .
  3. Выберите сервер RADIUS для беспроводных или проводных подключений 802.1X  в раскрывающемся списке Стандартная конфигурация .
  4. Нажмите Настроить 802. 1X , чтобы запустить Мастер настройки 802.1X.
  5. Когда появится окно Select 802.1X Connections Type , выберите переключатель Secure Wireless Connections и введите Имя: для вашей политики или используйте значение по умолчанию. Щелкните Далее .
  6. Проверьте точки доступа, которые вы добавили в качестве клиентов RADIUS, в окне Укажите коммутаторы 802.1X . Щелкните Далее .
  7. Для  Настройка метода аутентификации выберите Microsoft: Protected EAP (PEAP) .
  8. Щелкните Настроить , чтобы просмотреть Изменить защищенные свойства EAP . Сертификат сервера должен быть в сертификате , выпущенном раскрывающийся список. Убедитесь, что установлен флажок Включить быстрое переподключение , а Тип EAP — Безопасный пароль (EAP-MSCHAPv2) . Нажмите OK . Щелкните Далее .
  9. Когда появится окно Указать группы пользователей , нажмите Добавить .
  10. Введите или найдите группу пользователей домена . Эта группа должна находиться в том же домене, что и ваш сервер RADIUS.
    Примечание.  Если для аутентификации компьютера используется RADIUS, найдите  Компьютеры домена вместо группы.
  11. Когда группа будет добавлена, нажмите OK . Щелкните Далее.
  12. Нажмите Далее  в окне Настройка виртуальной локальной сети (VLAN).
  13. Когда появится Завершение создания новых защищенных проводных и беспроводных подключений IEEE 802.1X и клиентов RADIUS , нажмите Готово .

Изменить порядок обработки политики

  1. Перейдите к Политики > Политики запроса на подключение . Щелкните правой кнопкой мыши политику беспроводной сети и Move Up , чтобы она обрабатывалась первой.
  2. Перейдите к Policies>Network Policies . Щелкните правой кнопкой мыши политику беспроводной сети и выберите Move Up , чтобы она обрабатывалась первой.

Отключить автоматическое исправление

  1. Перейдите к Политики>Сетевые политики . Щелкните правой кнопкой мыши политику беспроводной сети и выберите Properties .
  2. На вкладке Настройка для политики снимите флажок Включите автоматическое исправление клиентских компьютеров и нажмите OK .

 

На следующем изображении показан пример политики NPS, которая поддерживает проверку подлинности пользователей с помощью PEAP-MSCHAPv2:

(необязательно) Разверните профиль беспроводной сети PEAP с помощью групповой политики.

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

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

  1. Откройте оснастку домена Управление групповой политикой .
  2. Создайте новый объект групповой политики или используйте существующий объект групповой политики.
  3. Отредактируйте объект групповой политики и перейдите к Конфигурация компьютера > Политики > Параметры Windows > Параметры безопасности > Политики открытого ключа > Политики беспроводной сети (IEEE 801.X).
  4. Щелкните правой кнопкой мыши Политики беспроводной сети (IEEE 801. X) и выберите Создать новую политику Windows Vista.
  5. Укажите Имя политики Vista.
  6. Нажмите Добавить для Подключиться к доступным сетям.
  7. Выберите  Инфраструктура.
  8. На вкладке Connection укажите имя профиля и введите SSID беспроводной сети для Network 9.0035 Имя(а). Нажмите  Добавить.
  9. Перейдите на вкладку  Безопасность  . Настройте следующее:
    • Аутентификация:  WPA2-Enterprise или WPA-Enterprise
    • Шифрование: AES или TKIP
    • Метод сетевой аутентификации:  Microsoft: защищенный EAP (PEAP)
    • Режим аутентификации: Компьютерная аутентификация (для машинной аутентификации)

 

  1. Нажмите  Свойства.

  2. Для  Доверенные корневые центры сертификации установите флажок рядом с соответствующими центрами сертификации и нажмите  ОК.

 

  1. Нажмите OK, чтобы закрыть , и нажмите Применить на странице политики беспроводной сети, чтобы сохранить настройки .

  2. Примените объект групповой политики к домену или подразделению, содержащему компьютеры-члены домена (подробности см. в документации Microsoft).

Конфигурация панели управления

После настройки сервера RADIUS с соответствующими требованиями для поддержки аутентификации в следующих инструкциях объясняется, как настроить SSID для поддержки WPA2-Enterprise и аутентификации на сервере RADIUS:

  1. В панели управления перейдите к Wireless >  Настройка > Контроль доступа .
  2. Выберите нужный SSID из раскрывающегося списка SSID (или перейдите к Wireless > Configure > SSID , чтобы сначала создать новый SSID).
  3. Для Security выберите Enterprise с моим сервером RADIUS .
  4. Под RADIUS нажмите Добавить сервер
  5. Введите Host IP или FQDN* (IP-адрес или FQDN вашего RADIUS-сервера, доступный из точек доступа), Порт (UDP-порт, который сервер RADIUS прослушивает для запросов доступа; по умолчанию 1812) и Секрет (общий секрет клиента RADIUS):

     

  6. Нажмите кнопку Сохранить .

* Сеть и все точки доступа должны работать под управлением MR28.0+ для поддержки полного доменного имени.

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

Параметры тегирования VLAN

Dashboard предлагает ряд параметров для тегирования клиентского трафика с определенного SSID с помощью определенного тега VLAN. Чаще всего SSID будет связан с идентификатором VLAN, поэтому весь клиентский трафик с этого SSID будет отправляться в эту VLAN.

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

Тестирование RADIUS из Dashboard

Dashboard имеет встроенную утилиту тестирования RADIUS, чтобы убедиться, что все точки доступа (по крайней мере те, которые передают SSID с использованием RADIUS) могут связаться с сервером RADIUS:

  1. Перейдите к Wireless >  Настройка > Контроль доступа .
  2. Убедитесь, что WPA2-Enterprise уже настроен в соответствии с инструкциями в этой статье.
  3. В разделе RADIUS-серверов нажмите кнопку Test 9.0035  для нужного сервера.
  4. Введите учетные данные учетной записи пользователя в поля Имя пользователя и Пароль  .
  5. Щелкните Начать тест .
  6. В окне будет показан ход тестирования каждой точки доступа (AP) в сети, а в конце будет представлена ​​сводка результатов.
    AP прошли : Точки доступа, которые были в сети и смогли успешно пройти аутентификацию с использованием предоставленных учетных данных.
    Сбой точек доступа : Точки доступа, которые были в сети, но не смогли пройти аутентификацию с использованием предоставленных учетных данных. Убедитесь, что сервер доступен с точек доступа, точки доступа добавляются в качестве клиентов на сервере RADIUS.
    Точки доступа недоступны : Точки доступа, которые не были подключены к сети и поэтому не могли быть протестированы.

 

Учет RADIUS

При необходимости учет RADIUS можно включить для SSID, использующего WPA2-Enterprise с проверкой подлинности RADIUS. Если этот параметр включен, сообщения учета «запуск» и «остановка» отправляются с точки доступа на указанный сервер учета RADIUS.

В следующих инструкциях объясняется, как включить учет RADIUS для SSID:

  1. Перейдите к Wireless >   Configure > Access control  и выберите нужный SSID из раскрывающегося меню.
  2. В разделе Учет RADIUS выберите Учет RADIUS включен.
  3. В разделе Серверы учета RADIUS нажмите Добавить сервер.
    Примечание. Можно добавить несколько серверов для отработки отказа, сообщения RADIUS будут отправляться на эти серверы в порядке сверху вниз.
  4. Введите данные для:
    • Хост  (IP-адрес, на который точки доступа будут отправлять учетные сообщения RADIUS)
    • Порт  (порт на сервере RADIUS, который прослушивает сообщения учета; 1813 по умолчанию)
    • Секрет  (общий ключ, используемый для аутентификации сообщений между точками доступа и сервером RADIUS)
  5. Нажмите  Сохранить изменения .

В этот момент учетные сообщения «Старт» и «Стоп» будут отправляться с точек доступа на сервер RADIUS всякий раз, когда клиент успешно подключается или отключается от SSID соответственно.

Настройка WPA2-Enterprise с RADIUS с помощью Cisco ISE

Точки доступа Cisco Meraki можно настроить для обеспечения корпоративной аутентификации WPA2 для беспроводных сетей с использованием Cisco Identity Services Engine (ISE) в качестве сервера RADIUS. В этой статье будут описаны инструкции по базовой интеграции с этой платформой. Дополнительные сведения о настройке Cisco ISE см. в Руководстве пользователя Cisco Identity Services Engine.

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

После установки Cisco ISE по умолчанию создает самозаверяющий локальный сертификат и закрытый ключ и сохраняет их на сервере. Этот сертификат будет использоваться по умолчанию для WPA2-Enterprise. В самозаверяющем сертификате имя хоста Cisco ISE используется в качестве общего имени (CN), поскольку оно требуется для связи по протоколу HTTPS.

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

Добавление управляемых сетевых устройств

  1. В Cisco ISE выберите Администрирование > Сетевые ресурсы > Сетевые устройства .
  2. На панели навигации «Сетевые устройства» слева нажмите  Сетевые устройства .
  3. Нажмите  Добавить или установите флажок рядом с устройством и нажмите  Изменить  , чтобы изменить его, или нажмите  Дублировать , чтобы создать дубликат записи. Вы также можете нажать Добавить новое устройство на значке действия на панели навигации «Сетевые устройства» или щелкнуть имя устройства в списке, чтобы изменить его.
  4. На правой панели введите Имя и IP-адрес .
  5. Установите флажок Настройки аутентификации и определите Общий секрет для аутентификации RADIUS. Это должно соответствовать Секрет  вводится для сервера RADIUS при настройке SSID в Dashboard.
  6. Нажмите  Отправить .

Включение наборов политик

Cisco ISE поддерживает наборы политик, что позволяет группировать наборы политик аутентификации и авторизации, в отличие от базовой модели политик аутентификации и авторизации, которая представляет собой плоский список правил аутентификации и авторизации. Наборы политик позволяют логически определить варианты использования ИТ-бизнеса организации в группы политик или службы, такие как VPN и 802.1X. Это значительно упрощает настройку, развертывание и устранение неполадок.

  1. В Cisco ISE выберите  Администрирование > Система > Развертывание > Настройки > Наборы политик .
  2. Выберите политику Default . Политика по умолчанию отображается справа.
  3. Нажмите значок плюса ( + ) вверху и выберите  Создать выше .
  4. Введите Имя , Описание и условие для этой групповой политики.
  5. Определите  Политику аутентификации .
  6. Нажмите  Отправить . После настройки набора политик Cisco ISE отключит всех администраторов. Войдите еще раз, чтобы получить доступ к порталу администрирования.

Настройка политики аутентификации 

  1. В Cisco ISE выберите меню  Действия  и нажмите  Вставить новое правило выше .
  2. Присвойте подправилу Имя (пример: Dot1X).
  3. Щелкните значок маленького окна, чтобы открыть меню  Условия  .
  4. Выберите  Создать новое условие  (дополнительный параметр).
  5. Выберите  Доступ к сети > Аутентификация EAP .
  6. Оставьте поле оператора равным EQUALS .
  7. В последнем поле выберите EAP-MSCHAPv2 .
  8. В поле Использовать выберите Active Directory в качестве хранилища удостоверений. Настройте интеграцию с Active Directory в соответствии с желаемым развертыванием.
  1. Наверх
    • Была ли эта статья полезной?
    1. Тип изделия
      Тема
      Стадия
      Финал
    2. Теги
      1. бухгалтерия
      2. Исе

        3. сиско

      3. is_translated
      4. ис
      5. РАДИУС
      6. wpa2 предприятие

    Как настроить Windows RADIUS Server

    Секрет раскрыт: сети с предварительным общим ключом не обеспечивают достаточную защиту от хакеров и похитителей данных. Опрос показал, что 74% лиц, принимающих решения в области ИТ, чьи данные были взломаны в прошлом, говорят, что взлом был связан со злоупотреблением учетными данными привилегированного доступа. Даже сложные учетные данные подвержены краже учетных данных по радиоканалу.

    Поддержка вашей сети с помощью сервера RADIUS может помочь устранить эти пробелы в безопасности. Если вы используете Windows, NPS является распространенным решением RADIUS.

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

    RADIUS-сервер проверяет подлинность пользователей и авторизует их для использования в сети. Пользователь получает авторизацию для доступа к сети после регистрации сертификата из PKI (инфраструктуры открытых ключей) или подтверждения своих учетных данных. Каждый раз, когда пользователь подключается, RADIUS подтверждает наличие у него правильного сертификата или учетных данных и предотвращает доступ к сети любых неутвержденных пользователей. Узнайте, как клиент SecureW2 обновил свою сетевую инфраструктуру, чтобы устранить любой риск атак MITM в сети с поддержкой RADIUS.

    Если вы используете Windows, серверы RADIUS обычно реализуются через NPS (сервер политики сети). Первоначально созданный для обеспечения соблюдения политик доступа к сети, NPS часто используется как сервер RADIUS.

    NPS позволяет аутентифицировать клиентов с помощью Active Directory (AD) через множество точек доступа, включая следующие:

    • Коммутаторы 802.1x
    • Wi-Fi
    • VPN
    • Коммутируемый номер
    • Маршрутизатор-маршрутизатор

    Хотя интеграция между NPS и AD более или менее управляема, это устаревшая технология, которую трудно интегрировать в более современные инфраструктуры. Это особенно важно, если вы работаете в облаке, для которого Microsoft не предлагает решение RADIUS.

    Как настроить Windows RADIUS с NPS

    Это пошаговое руководство поможет вам установить роли сервера RADIUS в Windows Server 2019. .

    1. Настройте группу безопасности

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

    2. Добавить сетевую политику и роль служб доступа

    Консоль диспетчера серверов содержит мастер добавления ролей и компонентов. Этот мастер управляет установкой и настройкой всех дополнительных функций Windows Server, включая NPS. Выберите роль «Сетевая политика и службы доступа».

    После завершения установки роли откройте сервер политики сети (nps.msc) в меню «Инструменты».

    3. Snap-In NPS для AD

    Найдите корень с надписью «NPS (локальный)» и щелкните его правой кнопкой мыши. Выберите «Зарегистрировать сервер в Active Directory».

    Выберите OK в появившемся диалоговом окне подтверждения.

    4. Добавьте клиент RADIUS к NPS

    .

    В дереве консоли NPS должна быть папка RADIUS Clients and Servers. Чтобы добавить новый клиент RADIUS, разверните раздел «Клиенты и серверы RADIUS» в дереве консоли NPS и выберите «Создать» в элементе «Клиенты RADIUS».

    На вкладке Настройки заполните следующие поля. «Дружественное имя» — это псевдоним вашего клиента, «Адрес» может быть IP- или DNS-именем, а «Общий секрет» должен быть определен при настройке точки доступа.

    Примечание. Общие секреты — это слабая форма безопасности аутентификации. Цифровые сертификаты обеспечивают наилучшую безопасность. Сертификаты также легко авторизуются. Добавьте сертификат точки доступа в личное хранилище сертификатов на локальном компьютере, затем запросите и импортируйте сертификат на сервер политики сети.

    SecureW2 позволяет легко создать собственный частный ЦС и экспортировать файл .p12 для последующего импорта в NPS. Или вы можете импортировать свои сертификаты AD CS и использовать SecureW2 для регистрации устройств конечных пользователей для самообслуживания для клиентских сертификатов для вашего центра сертификации AD CS.

    Если вы используете точку доступа крупного поставщика, такого как Aruba или Cisco, перейдите на вкладку «Дополнительно» и выберите поставщика из списка «Имя поставщика».

    Теперь ваш Windows Server RADIUS готов к работе! Пользователей нужно будет вручную добавлять и удалять из группы безопасности, если вы не используете решение для адаптации, подобное тому, которое предлагает SecureW2. Нажмите здесь, чтобы ознакомиться с нашим пакетом автоматической регистрации мирового класса JoinNow.

    Cloud RADIUS + Windows: лучшее решение

    Основная проблема с NPS заключается в том, что его использование по существу ограничивает вас в использовании Windows в качестве поставщика. NPS совместим с Active Directory только через протокол LDAP. Хотя вы можете использовать сторонних поставщиков для преодоления этого препятствия, это создает ненужные сложности для вашей инфраструктуры, подвергая вашу сеть риску.

    Кроме того, NPS был разработан для использования в качестве локального решения с AD, поскольку он был создан задолго до того, как облачные решения стали настолько распространены.