Добавить в корзинуПозвонить
Найти в Дзене
Linux | Network | DevOps

Аутентификация на сетевых устройствах Cisco средствами Active Directory

Наверняка многие системные администраторы рано или поздно сталкиваются с проблемой аутентификации на сетевых устройствах. Если руководствоваться best-practices, то учетные записи должны быть персонифицированными, пароли должны отвечать критериям устойчивости, время жизни паролей должно быть ограничено. Также не будем забывать о разграничении уровней доступа в соответствии с выполняемыми задачами и поддержке актуальности базы пользователей, связанной с изменениями в штате сотрудников. При соблюдении этих требований ведении базы пользователей на каждом устройстве становится трудоемкой и нетривиальной задачей, а на практике часто просто игнорируется, администраторы ограничиваются заданием паролей на физическую и виртуальную консоль и заданием пароля суперпользователя (enable). Логичным решением этой проблемы является ведение единой базы пользователей с контролем выдвигаемых к учетным записям требований. Если у нас есть Active Directory, почему бы не использовать его? Все не так просто –
Оглавление

Интеграция CISCO AAA и Microsoft Active Directory

Наверняка многие системные администраторы рано или поздно сталкиваются с проблемой аутентификации на сетевых устройствах. Если руководствоваться best-practices, то учетные записи должны быть персонифицированными, пароли должны отвечать критериям устойчивости, время жизни паролей должно быть ограничено. Также не будем забывать о разграничении уровней доступа в соответствии с выполняемыми задачами и поддержке актуальности базы пользователей, связанной с изменениями в штате сотрудников. При соблюдении этих требований ведении базы пользователей на каждом устройстве становится трудоемкой и нетривиальной задачей, а на практике часто просто игнорируется, администраторы ограничиваются заданием паролей на физическую и виртуальную консоль и заданием пароля суперпользователя (enable). Логичным решением этой проблемы является ведение единой базы пользователей с контролем выдвигаемых к учетным записям требований. Если у нас есть Active Directory, почему бы не использовать его?



Рис.1 Топология системы
Рис.1 Топология системы

Все не так просто – устройства Cisco не предоставляют механизма для
аутентификации средствами LDAP, коим является MS ActiveDirectory,
напрямую. Для решения этой задачи CISCO в своих решениях предоставляет
механизм
AAA(Authentication Authorization Accounting). Дабы не
растягивать статью, за деталями отсылаю к первоисточнику [1], также вот
неплохая статья описывает основные возможности [2]. Вкратце, клиент AAA
отправляет ученые данные к серверу аутентификации, и основываясь на его
ответе (либо отсутствии ответа) принимает решении об отказе или
предоставлении запрашиваемого доступа.
В качестве сервера аутентификации AAA позволяет использовать RADIUS либо TACAS+ сервер. На первый взгляд по описанию возможностей
предпочтительней TACAS+, но основной его недостаток в том, что это
закрытое решение от CISCO и его реализация существует только для *nix
систем [3]. Протокол же RADIUS является открытым промышленным
стандартом, для которого существует множество реализаций, в том числе и
встроенная в Windows Server 2000/2003 служба
IAS (Internet Authentication Service). В Windows Server 2008 вместо службы IAS поставляется служба Network Policy Server [4].

Топология

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

Аутентификация пользователей на сетевом оборудовании будет происходить
средствами ActiveDirectory посредством RADIUS, авторизация доступа — на
основе принадлежности к одной из двух групп, соответственно разрешающих
непривилегированный (User exec mode) и привилегированный (Privilege exec
mode) доступ к устройству. В дальнейшем, можно разделить доступ по
ролям, сконфигурировав на устройствах профили с разрешением запускать
необходимые команды и связав каждый профиль с соответствующей группой
AD.

Настройка MS ActiveDirectory

Предполагаем, что политики безопасности для длины, сложности паролей,
времени их жизни и пр. уже внедрены. И так, для начала создадим две
группы безопасности (Security group)
gsgrCiscoUserEXEC и gsgrCiscoPrivEXEC:

Теперь создадим учетные записи администраторов
PetrovI и IvanovP, сделав их членами групп gsgrCiscoUserEXEC и gsgrCiscoPrivEXEC соответственно. Таким образом видим что PetrovI будет непривилигированным пользователем, а IvanovP — привилегированным.

На этом с AD все.

Настройка MS Internet Authentication Service

Если на сервере еще не установлена служба IAS, то ее необходимо
установить. Для этого необходимо в панели управления выбрать “Add/remove
programs” -> “Add/remove Windows components”, выбрать пункт “Network
Services”, нажать кнопку Details (Дополнительно), выбрать пункт
“Internet Information Service (IIS)” и еще раз нажать Details
(Дополнительно), выбрать Internet Authentication Service.

Открываем оснастку Internet Authentication Service и создаем новую
политику удаленного доступа (Remote Access Policies -> RClick ->
New Remote Access Policy) с названием CiscoAAA_AD. В открывшемся окне
Select Attribute выбираем Authentication Type и добавляем CHAP,

критерий – принадлежность пользователей к ранее созданной группе
gsgrCiscoUserEXEC. Выбираем пункт Windows-Groups, добавляем gsgrCiscoUserEXEC.

И самое главное – выбираем атрибут
“Service-Type” = Login для пользовательского и Administrative – для привилегированного доступа:

 Рис.2. Выбираем атрибут Service Type
Рис.2. Выбираем атрибут Service Type

В завершение мастера, выбираем пункт “Grant remote access permission”

Теперь необходимо создать учетные записи для устройств, к которым будет выдаваться доступ. Для этого в оснастке
IAS выбираем пункт RADIUS Clients -> RClick -> New RADIUS Client,

 Рис.3. Создаем учетную запись устройства

Рис.3. Создаем учетную запись устройства
Рис.3. Создаем учетную запись устройства Рис.3. Создаем учетную запись устройства

в появившемся окне вводим дружественное имя, например Switch1 и IP адрес устройства, жмем Next, выбираем “Client-Vendor” = “Cisco”, вводим ключ для аутентификации RADIUS сервера и клиента (рис. 4).

 Рис. 4. Данные для аутентификации RADUIS сесии 

Рис. 4. Данные для аутентификации RADUIS сесии
Рис. 4. Данные для аутентификации RADUIS сесии Рис. 4. Данные для аутентификации RADUIS сесии

Настройка со стороны IAS завершена, переходим к настройке сетевых устройств.

Настройка сетевого устройства Cisco на примере коммутатора Catalyst 2960

!включаем шифрование паролей

service password-encryption

!задаем пароль для привилегированного режима

enable secret *******

!!! ВНИМАНИЕ!!!

! AAA работает таким образом, что если не получен ответ от сервера, клиент

! предполагает аутентификацию неуспешной

! Обязательно создаем локального пользователя на случай

! если RADIUS сервер недоступен по какой-либо причине,

! печатаем на листике, заворачиваем в конверт и прячем в сейф.

username recover password *********

! Включаем ААА

aaa new-model

!Необязательно. Баннер о том, что это закрытая система и делать здесь нечего

aaa authentication banner ^ Access only for persons explicitly authorized. All rights reserved.

^

!Сообщение на случай неуспешной аутентификации. Полезно при отладке

aaa authentication fail-message ^ Authentication failed

^

!Создаем профиль аутентификации

!Не забываем как резервный указать локальный способ аутентификации

aaa authentication login login-RADIUS group radius local

!Создаем профиль авторизации.

aaa authorization exec auth-RADIUS-exec group radius local

!По умолчанию клиент ААА трижды пытается авторизоваться через RADIUS.

!Дабы не блокировать учетные записи в AD, ставим 1 попытку

radius-server retransmit 1

!Указываем наш RADUIS сервер

radius-server host 10.0.0.2

!Задаем ключ для шифрования

radius-server key SupErkEy

!

! Включаем созданные профили для виртуальных консолей

line vty 0 15

exec-timeout 15 0

login authentication login-RADIUS

authorization exec auth-RADIUS-exec

timeout login response 180

no password

Настройка завершена, перехолим к тестированию.

Проверяем работу



Рис. 5. Проверка работы
Рис. 5. Проверка работы

Отладка

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

# debug radius events

# debug aaa authentication

# debug aaa authorization

# debug aaa protocols

# debug radius [authentication | elog | verbose]

А так же не забываем смотреть в Event log AD и IAS.

Заключение

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

Источники

1) Authentication, Authorization, and Accounting Overview [http://www.cisco.com/en/US/products/ps6638/products_data_sheet09186a00804fe332.html]

2)
Настройка AAA на CISCO — краткий обзор [http://faq-cisco.ru/index.php?option=com_content&task=view&id=26&Itemid=30]

3)
Remote Authentication Dial In User Service (RADIUS) [http://en.wikipedia.org/wiki/RADIUS]

4)
Understanding the new Windows Server 2008 Network Policy Server http://www.windowsnetworking.com/articles_tutorials/Understanding-new-Windows-Server-2008-Network-Policy-Server.html]