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

При обслуживании больших сетей системные администраторы часто сталкиваются с проблемами аутентификации на сетевом оборудовании. В частности, довольно сложно организовать нормальную работу нескольких сетевых администраторов под индивидуальными учетными записями на большом количестве оборудования (приходится вести и поддерживать в актуальном состоянии базу локальных учетных записей на каждом устройстве). Логичным решение было бы использовать для авторизации уже существующей базы учетных записей — 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

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

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

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

1. RADIUS Clients — содержит список устройств, которые могут аутентифицироваться на сервере
2. Connection Request Policies – определяет типы устройств, которые могут аутентифицироваться
3. 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 и пароль на свои).

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

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

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

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

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

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

Windows 2012 R2 NPS log files location configuration

After a bit of frustration working on a project recently with a Windows 2012 R2 NPS RADIUS server, I had a bit of a refresher on Windows 2012 R2 NPS log files location configuration, administration and what I have experienced with logging behavior.

windows 2012 R2 NPS log files location configuration

Logging with Network Policy Server is a bit more convoluted than in the old days with plain IAS server. I guess one of the main reasons is that NPS does so much more than just RADIUS. However, when you need to find information about successful and failed logins, where do you look and where are things stored?

Let’s take a look at some of the logging configuration within NPS. If you right click on NPS (Local) click properties, then General tab and make sure Rejected authentication requests and Successful authentication requests are selected.

Under Accounting you can also configure settings related to your log file format, location, and other information. If you click Configure Accounting it launches a wizard that will allow the configuration of most of the log file properties.

Otherwise, you can simply click the Change Log File Properties link and you will have access to most of the options there as well.

I have found on my RADIUS server, the events are not logged to the System Log like NPS service related messages are logged. However, in Server Manager >> NAP I see all the events as they relate to the logins and policy application. Also, the low level logging can be found in c:widowssystem32logfilesIN*.log which you can configure in the wizard and the settings mentioned above.

Some have mentioned having issues seeing anything logged. If so, check your audit policy as it relates to NPS to make sure events are being audited correctly.

If enabled, the output should be:

System audit policy

Category/Subcategory Setting
Logon/Logoff
Network Policy Server Success and Failure

If it shows ‘No auditing’ run the following:

Final Thoughts

Hopefully this Windows 2012 R2 NPS log files location configuration post will help any who are struggling trying to make sense of where things are presented from NPS as to login successes and failures. If you have any other tricks up your sleeve you would like to share as to NPS and logging, please comment below.

RADIUS — немного о Mikrotik, NPS и не только

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

Changelog

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

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

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

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

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

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

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

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

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

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

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

Настройка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Стоит уделить внимание параметру 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 Результат ожидаемый, мы залогинились в микротик под полными правами:

Перейдем к впн, и к стразу более интересному сценарию.

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

В настройки правил форейвола для ограничения доступа подсетей я пожалуй не буду углубляться, подразумевается что вы понимаете как из одной подсети запретить доступ к ресурсу и как разрешить. (с) предпологается, что вы немного сетевик. Касательно примера подсети 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 каждый настраивает как ему удобно. Я к примеру, предпочитаю 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 то попадет в влан, для которого мы настроили(я надеюсь все таки настроили) максимально безопасные правила форейвола для чужеродных устройств .

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

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

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

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

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

Диагностика

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

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

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

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

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

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

radclient из пакета freeradius-utils. Позволяет из командной строки проверить некоторые типы авторизации, к примеру подключение к vpn

Выводы

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

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

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

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

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