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

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


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

image
Рис.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 – для привилегированного доступа:

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

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

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

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

image
Рис. 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

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

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


image
Рис. 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]
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 18

    +1
    Задумывался над настройкой доменной аутентификации для сетевого оборудования, останавливает вероятность возникновения ситуации, когда контроллер домена будет недоступен с циски.
    Пришел к выводу, что в моей ситуации (мало устройств и два равноправных админа) — смысла настраивать нет. При аварии причины можно установить по сислогу (в том числе время авторизации админа, ip адрес с которого она происходила и изменения конфигурации).
      0
      пару раз теряли доступ к цискам в такой ситуации, благо консольный доступ был на внутренней авторизации
        0
        Паследнее слово 'local' в строчке конфигурации у автора 'aaa authetication… local' — в случае недоступности сервера позволяет аутентифицироваться пользователям настроенным локально на устройстве. Об этом автор также упоминает в коменте.
          0
          Если паролем не пользоваться — его забудешь. Хранить его в сейфе на бумажке можно, но опять таки специфика: час простоя телемеханики приводит к разбирательствам на уровне ростехнадзора, сейчас в случае аварии достаточно одного из админов (возможно хватит удалённого входа), а если пароль в сейфе — потребуется ещё и человек с ключом от сейфа, да и с доступом из дома ничего не получается.

          Я не хочу сказать, что данный метод плох, при большом количестве устройств и/или администраторов — единой базы необходима, но в моих условиях работы это не лучший вариант.
            0
            Резервирование никто не отменил
            AAA позволяет настроить группу RADIUS серверов, ну а то что контроллеров AD должно быть быть как минимум два считаю само собой разумеющимся.

            Насчет паролей в конверте — это же на случай «забывания».
      0
      Хм, вроде читал в описании 15.1 версии — что там есть возможность аутентикации напрямую в AD, без радиус сервера. Я что-то неверное прочитал или такое таки-да, возможно?
        0
        Поддержка Kerberos появилась задолго до версии 15.1, но мне тоже было бы интересно почитать про его настройку с примерами.
          0
          Ниже отписал, насколько мне известно с текущей версии софта это невозможно сделать «Kerberos-way» без ввода пароля. И к слову говоря код, в IOS очень старый насколько я знаю еще написанный CyberSafe и там поддержка была только DES. Возможно недавно чтото и изменилось, но я не слышал об этом.
          0
          Там речь шла только про LDAP сервер судя по описанию. А вобще ситуация там такая SSH через Kerberos есть, но совсем не Kerberos-way. Ты можешь залогинься на роутер, с помощью пароля, но нельзя допустим получить доступ без ввода пароля когда у тебя уже есть тикет, например: kinit nshopik/admin и потом ssh nshopik/admin@switch без ввода пароля
            0
            А.
            Любопытно.
            А для впн можно керберос таки пользовать? Мне бы для этого LDAP бы пользовать, и вроде именно об этом я читал в релиз нотисах… я уже не помню =)
              +1
              www.cisco.com/en/US/docs/ios/15_1/release/notes/151TNEWF.html#wp42593 — вот эту строку вы читали скорее всего.
              LDAP этож хранилище лишь, оно не управляет выдачей паролей тикетов. Да и я как-то слабо представляю себе ваш кейс, обычно VPN устанавливают чтобы получить доступ к домен контролеру, т.е. вы никак не можете получить Kerberos Тикет прежде чем установите VPN :)
              Если в вашем понимании просто использовать единую базу паролей, то я думаю тут нет никаких паролей чтобы использовать AD, чтобы пользователь использова свой логин и пароль. Тут и правда не нужен Kerberos достаточно RADIUS, мне так кажеться.
                0
                Да, именно ее и читал =) Как раз полез искать, чтобы указать.

                По логике — действительно, тикет не получить до VPN, а значит впн не будет без тикета.

                Просто для VPN тогда надо прикручивать RADIUS сервер, я думал попробовать обойтись без этого. А оно никак оказывается, на Microsoft AD то.
                  0
                  Не забывайте Kerberos — это authentication, а вам еще надо чтобы ктото делал authorization, техническии для этого подходит LDAP. Если он позволит сделать authorization тогда я думаю это возможно, а иначе без RADIUS никак нельзя ведь это AAA.
          0
          Друзья, а никто не занимался скрешиванием Cisco ASA и Cisco AD Agent для аутентификации и авторизации пользователей ломящихся в интернет? Нет людей успешно реализовавших эту схему?
            0
            Ага, и мне было бы интересно.
            0
            Однозначно — в избранное. Спасибо за статью.
              0
              Прочитал эту статью в журнале «Системный администратор», хорошая статья, добро пожаловать )))
                0
                Да, собственно это она и есть
                Спасибо

              Only users with full accounts can post comments. Log in, please.