Настраиваем доменную аутентификацию на сетевом оборудовании
22.01.2015
itpro
Windows Server 2012 R2
комментариев 7
При обслуживании больших сетей системные администраторы часто сталкиваются с проблемами аутентификации на сетевом оборудовании. В частности, довольно сложно организовать нормальную работу нескольких сетевых администраторов под индивидуальными учетными записями на большом количестве оборудования (приходится вести и поддерживать в актуальном состоянии базу локальных учетных записей на каждом устройстве). Логичным решение было бы использовать для авторизации уже существующей базы учетных записей — 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. Нас интересуют три следующих раздела консоли:
- 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 и пароль на свои).
Совет. Если в целях безопасности вы запретили подключаться к сетевому оборудованию через telnet, эти строки нужно удалить из конфига:
Не закрывая консольное окно коммутатора (это важно!, иначе, если что-то пойдет не так, вы более не сможете подключиться к своему коммутатору), откройте вторую telnet-сессию. Должно появиться новое окно авторизации, в котором будет предложено указать имя и пароль учетной записи. Попробуйте указать данные своей учетной записи в AD (она должна входить в группу Network Admins ). Если подключение установлено – вы все сделали правильно!
Для коммутатора Cisco конфигурация, предполагающая использование доменных учетных записей для аутентификации и авторизации, может выглядеть так:
Для Cisco ASA конфигурация будет выглядеть так:
Совет. Если что то-не работает, проверьте:
- Совпадают ли секретные ключи на сервере 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:
Сделаем тоже самое и на втором сервере. Создадим папку для скрипта C:\Scripts на обоих серверах и сетевую папку на втором сервере \\SRV2\NPS-config$
На первом сервере создадим PowerShell скрипт C:\Scripts\Export-NPS-config.ps1 со следующим содержанием:
После этого настроим задание в Task Sheduler: “Export-NpsConfiguration”
Выполнять для всех пользователей — Выполнить с наивысшими правами
Ежедневно — Повторять задачу каждые 10 мин. в течении 8 ч.
На резервном NPS настроим импорт конфигурации (политик):
создадим скрипт PowerShell:
и задачу на его выполнение каждые 10 минут:
Выполнять для всех пользователей — Выполнить с наивысшими правами
Ежедневно — Повторять задачу каждые 10 мин. в течении 8 ч.
Теперь, для проверки, добавим в NPS на одном из серверов(!) пару коммутаторов в RADIUS-клиенты (IP и Shared Secret), две политики запросов на подключение: WIRED-Connect (Условие: “Тип порта NAS – Ethernet”) и WiFi-Enterprise (Условие: “Тип порта NAS – IEEE 802.11”), а также сетевую политику Access Cisco Network Devices (Network Admins):
После настройки, спустя 10 минут, все клиенты\политики\параметры должны появиться и на резервном NPS и мы сможем авторизоваться на коммутаторах с помощью учетной записи ActiveDirectory, члена группы domain\sg-network-admins (которую мы создали заранее).
Перейдем к настройке Active Directory – создадим групповую и парольную политики, создадим необходимые группы.
Групповая политика Computers-8021x-Settings:
Создадим группу безопасности sg-computers-8021x-vl100, куда мы будем добавлять компьютеры, которые мы хотим распределять в влан 100 и настроим фильтрацию для созданной ранее групповой политики на эту группу:
Убедиться в том, что политика успешно отработала можно открыв “Центр управления сетями и общим доступом (Параметры сети и Интернет) – Изменение параметров адаптера (Настройка параметров адаптера) – Свойства адаптера”, где мы сможем увидеть вкладку “Проверка подлинности”:
Когда убедились, что политика успешно применяется – можно переходить к настройке сетевой политики на NPS и портов коммутатора уровня доступа.
Создадим сетевую политику neag-computers-8021x-vl100:
Типовые настройки для порта коммутатора (обращаю внимание, что используется тип аутентификации “мультидомен” – Data & Voice, а также есть возможность аутентификации по mac адресу. на время “переходного периода” есть смысл использовать в параметрах:
влан id не “карантинного”, а того же, куда пользовательский компьютер должен попасть, успешно авторизовавшись – пока не убедимся, что все работает как следует. Эти же параметры могут быть использованы и в других сценариях, например, когда в этот порт воткнут неуправляемый коммутатор и вы хотите, чтобы все устройства, подключенные в него и не прошедшие аутентификацию, попадали в определенный влан (“карантинный”).
Убедиться, что компьютер\телефон успешно прошли аутентификацию можно командой:
Теперь создадим группу (например, 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
Теперь, как и обещал рассмотрим пару не совсем очевидных ситуаций. Например, нам требуется подключить компьютеры\устройства пользователей через неуправляемый коммутатор (свитч). В этом случае настройки порта для него будут выглядеть следующим образом:
P.S. замечен очень странный глюк – если устройство было подключено через такой свитч, а потом его воткнули в управляемый коммутатор, то оно НЕ заработает, пока мы не перезагрузим(!) свитч Пока других способов решения этой проблемы не нашел.
Еще один момент, связанный с DHCP (если используется ip dhcp snooping) – без таких вот опций:
почему-то корректно ip адрес не получить…хотя может это особенность нашего DHCP сервера
А еще Mac OS & Linux (в которых поддержка 802.1x нативная) пытаются пройти аутентификацию пользователем, даже если настроена аутентификация по мас-адресу.
В следующей части статьи рассмотрим применение 802.1x для Wireless (в зависимости от группы, в которую входит учетная запись пользователя, его будем “закидывать” в соответствующую сеть (влан), хотя подключаться они будут к одному SSID).
СиТ №7
Сеть имеет петли. Необходимо оставить один активный путь к каждому из коммутаторов.
Все прямые каналы к центральному коммутатору должны оставаться активными.
Следовательно, нужно работать с коммутаторами SW3, SW8.
Коммутаторы должны использовать путь с наименьшим количеством переходов к центральному коммутатору.
Коммутаторы, для которых количество переходов одинаково, должны использовать путь с максимальной общей полосой пропускания.
Найдем максимальную общую полосу пропускания:
Отключение портов между коммутаторами SW3-SW4 и SW8-SW4:
Общая полоса пропускания равна: Кбит
Отключение портов между коммутаторами SW3-SW9 и SW8-SW5:
Общая полоса пропускания равна: Кбит
Отключение портов между коммутаторами SW3-SW4 и SW8-SW5 или SW3-SW9 и SW8-SW4:
Общая полоса пропускания равна: Кбит
Итак, максимальная полоса пропускания во 2 пункте. Отключим необходимые порты.
Шаг 2. Проверка подключений
С помощью команды ipconfig узнали адреса компьютеров и отправили эхо-запрос с PC0 на все остальные PC.
Эхо запрос на PC1:
Эхо-запрос на PC2:
Эхо-запрос на PC3:
Эхо-запрос на PC4:
Эхо-запрос на PC5:
Итак, все эхо-запросы прошли успешно – все ПК коммутируют между собой.
Настройка домена VTP
Шаг 1. Настройка сервера VTP
Зададим имя для домена для VTP Server, установим серверный режим VTP и зададим пароль:
Шаг 2. Настройка коммутатора как клиента VTP
Проделаем то же самое с Client 1,2,3 с установкой клиентского режима.
Шаг 3. Настройка прозрачного режима VTP на коммутаторе
Проделаем то же самое для VTP Transparent.
Шаг 4. Настройка новой сети VLAN на сервере VTP
Шаг 5. Проверка настроек VTP
Проделали то же самое с клиентскими VTP – получили введенный результат.
Шаг 6. Добавление клиентских рабочих станций в новую сеть VLAN и проверка подключения
Для Client2 и Client3:
Добавление коммутатора в домен VTP
Шаг 1. Проверка номера текущей версии сервера VTP и нового коммутатора
Для 1 st _Floor1:
Шаг 2. Подключение нового коммутатора к сети
Подключили порт Fast Ethernet 0/24 коммутатора 1st_Floor3 к порту Fast Ethernet0/23 коммутатора 1st_Floor2.
Настроим их в качестве магистральных и сохраним конфигурацию wri mem
Шаг 3. Настройка домена, режима и пароля VTP
Настроили режим VTP:
Проверка vtp status’а прошла успешно.
Настройка беспроводных и голосовых VLAN
Шаг 1. Создание домена VTP
Настроили SW1 как сервер:
Шаг 2. Создание сетей VLANS
Создали 3 VLAN на SW1:
Шаг 3. Назначение устройств корректным портам
Назначили порты на VLAN для коммутаторов SW2, SW3:
Планирование и создание корпоративной сети
Шаг 1. Составление сети
Подключили первый интерфейс FastEthernet 0/0 маршрутизатора ISR к последнему интерфейсу FastEthernet 0/24 коммутатора Floor 1.
Подключили интерфейс GigabitEthernet 0/1 коммутатора Floor 1 к интерфейсу GigabitEthernet 0/1 коммутатора Floor 2.
Подключили интерфейс GigabitEthernet 0/2 коммутатора Floor 2 к интерфейсу GigabitEthernet 0/1 коммутатора Floor 3.
Шаг 2. Базовая настройка коммутатора и маршрутизатора
Задали имена узлов для всех четырех устройств.
Задали пароли привилегированного режима для всех четырех устройств.
Задали пароли vty для каналов 0 — 4 и разрешили вход на все четыре устройства.
На всех четырех устройствах задали пароль для консольной линии и активировали вход в систему.
Коммутатор Floor 1:
Коммутатор Floor 2:
Коммутатор Floor 3:
Шаг 3. Настройка интерфейсов, соединяющих маршрутизатор и коммутаторы
Настроили интерфейсы, соединяющие коммутаторы Floor 1, Floor 2 и Floor 3, в качестве магистральных портов.
Настроили в качестве магистрального порта интерфейс коммутатора Floor 1, подключенный к маршрутизатору ISR.
На маршрутизаторе ISR включили интерфейс, подключенный к коммутатору Floor 1.
Создали и настроили три подынтерфейса на интерфейсе Fast Ethernet 0/0 маршрутизатора ISR, воспользовавшись следующей таблицей:
Назад в прошлое. 802.1x на коммутаторах 3Com
Сегодня пришлось столкнуться с очень старым коммутатором от давно почтившей нас компании 3Сom. Было необходимо настроить на коммутаторе 802.1x а так же авторизацию средствами NAP сервера от компании Microsoft на базе Server 2012R2.
На просторах интернета оказалось практически не возможно найти информацию о настройке коммутаторов 3Com и я решил сделать небольшую заметку себе на память (вдруг когда нибудь пригодится).
Настройка политик NAP сервера
Итак: политику настройки доступа к сети и переключения на нужный VLAN после авторизации можно посмотреть тут.
Для настройки авторизации средствами NAP необходимо создать дополнительную политику в условиях которой надо указать группу пользователей которым разрешена авторизация. Метод проверки подлинности установить Проверка открытым текстом (PAP, SPAP) . В атрибутах RADIUS указать стандартный атрибут Service-Type с значением Login . Данная политика универсальна и может применяться для авторизации на коммутаторах Сisco.
Настройка коммутатора 3Com
Настраиваем схему RADIUS сервера
radius scheme ИМЯ
server-type standard
primary authentication IP-адрес первичного сервера
primary accounting IP-адрес первичного сервера
secondary authentication IP-адрес вторичного сервера
secondary accounting IP-адрес вторичного сервера
accounting optional
key authentication ключ RADIUS-клиента
key accounting ключ RADIUS-клиента
timer realtime-accounting 15
timer response-timeout 5
retry 5
user-name-format without-domain
nas-ip IP-адрес коммутатора
calling-station-id mode mode2 uppercase
Настройка домена
domain ИМЯ
scheme radius-scheme ИМЯ RADIUS СХЕМЫ local
scheme lan-access radius-scheme ИМЯ RADIUS СХЕМЫ
scheme login local
accounting lan-access radius-scheme ИМЯ RADIUS СХЕМЫ
authentication login radius-scheme ИМЯ RADIUS СХЕМЫ local
accounting login radius-scheme ИМЯ RADIUS СХЕМЫ local
vlan-assignment-mode string
access-limit enable 60
idle-cut enable 20 2000
После напишем Quite и укажем домен по умолчанию:
domain default enable ИМЯ ДОМЕНА
Настройка dot1x
Глобально применим настройки
dot1x
dot1x authentication-method eap
После этого настроим нужные нам порты коммутатора:
dot1x port-method portbased
dot1x guest-vlan НОМЕР VLAN
dot1x
dot1x re-authenticate
Нужные VLAN сети необходимо указать коммутатору.
Настройка авторизации
ssh authentication-type default password
ssh server authentication-retries 5
user-interface vty 0 15
authentication-mode scheme
Создать пароль на суперпользователя
super password level 3 ПАРОЛЬ
Отключить срок действия пароля
undo password-control aging enable
Поиск проблем
Для включения Debug на dot1x и RADIUS
debugging radius packet
debugging dot1x all