Pull to refresh

Настройка Cisco ACS 5.3 в связке с Active Directory

Reading time 6 min
Views 47K
Cisco ACS (Access Control Server) — система для централизованной аутентификации, авторизации и аккаутинга пользователей на всякого рода оборудовании, в частности на активном сетевом оборудовании различных производителей.

Имея достаточно небольшой опыт работы системным администратором в крупной компании enterprise сегмента пришёл к выводу, что каждый системный администратор в идеале должен иметь одну учётную запись для авторизации на всех необходимых ему ресурсах: сетевое оборудование, серверы, рабочие станции и т. д. Это связано как с удобством администрирования, так и с безопасностью. В случае увольнения человека можно залочить всего одну учёту в одном хранилище и пропадёт доступ абсолютно ко всему. Но идеальных случаев, как известно, не бывает. В статье мы попробуем приблизиться к идеалу и настроим авторизацию пользователей на активном сетевом оборудовании с использованием учётной записи Active Directory.

Итак, в нашей сети 3 кампуса: два пользовательских и серверная ферма.
В соответствие с кампусной структурой построения сети устройства подразделяются на группы: access layer, distribution layer, core layer. Отдельно существует группа border для управления пограничным железом: пограничные маршрутизаторы, сетевые экраны, VPN шлюзы, etc.

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



Каждая прямоугольная область — полномочия на оборудование, которые предоставлены определённой группе администраторов

Настройка сервера ACS


После скачивания с торрент-трекера покупки новой железки Cisco 1120 и первоначальной инсталляции мы попадаем на страницу ввода логина и пароля:



Вводим логин и пароль, вбитые при инсталляции и попадаем на стартовую страницу:



Network Resources


В секции Network Resources описываются местоположения, типы устройств и, собственно, сами устройства.
Для начала нам необходимо описать устройства, которые будут подключены к серверу. Заходим в секцию Network Resources → Location и создаём как минимум 3 местоположения устройств: Кампус 1, Кампус 2, Серверная ферма:



В секции Device Type создаём 3 типа устройств: AccessLayerSwitches, DistributionLayerSwitches, CoreLayerSwitches.

Далее в секции Network Devices and AAA Clients описываем ip адреса устройств и привязываем их к местоположениям и типам. Cisco ACS может использовать проколы tacacs+ и radius. Наши устройства будут работать по протоколу Tacacs+, ставим галочку напротив Tacacs+. В поле Shared Secret вбиваем ключ.



Настройки секции Network Resources закончены.

Users and Identity Stores


Переходим к настройке связки с Active Directory. Открываем секцию Users and Identity Stores → External Identity Stores → Active Directory. Заполняем поля. Для соединения с AD необходима учётка доменного администратора. Зачем — не знаю. С учёткой обычного пользователя не работает.



Во вкладке Directory Groups осуществляется привязка к группам Active Directory



Вкладка Directory Attributes нужна для настройки политик для конкретного пользователя.

Настройка связки с AD на этом закончена.

Policy Elements


Переходим к конфигурированию элементов политик. Создадим профиль полного доступа к устройству. Для этого в секции Policy Elements переходим в группу Authorization and Permissions → Device Administration → Shell Profiles. Создаём профиль FullAccess. Во вкладке Common Tasks задаём максимальные привилегии:



Нажимаем Submit. Всё, настройки профилей закончены.

Access Policies


Непосредственно сами политики доступа настраиваются в секции Access Policies.

Для начала необходимо создать политику для работы с Active Directory. Нажимаем на ссылку Access Services и создаём новую политику доступа:



Ставим 2 галочки Identity и Authorization.

Далее необходимо указать по какой политике доступа будут работать устройства. Нажимаем на ссылку Service Selection Rules. Создаём правило по которому будут матчиться устройства, работающие по протоколу tacacs+:



По этому правилу все устройства, запрашивающие данные по протоколу tacacs+ будут обрабатываться политикой, созданной выше.

Переходим непосредственно к настройке политик доступа. В пункте Identity настраивается источник учётных записей. Выбираем Active Directory. В пункте Authorization прописываются правила для авторизации пользователей. По-умолчанию нужные нам столбцы недоступны, их необходимо принудительно активировать нажав кнопочку Customize.



В секции Customize Results выбираются возможные варианты профиля командной строки и набор команд. В нашем случае используется только набор команд.

Для создания правила нажимаем кнопку Create.



Проставляем галочки и условия. Пункт AD1:mailNickname нужен если правило настраивается с привязкой к конкретному имени пользователя, а не всей группе.

Далее необходимо настроить правила в соответствие с первой картинкой.

Примеры настройки tacacs+ авторизации на устройствах Cisco и HUAWEI


Авторизация проходит через через сервер tacacs, если он недоступен, но проверяются локальные учётные записи.

Cisco:
#
 tacacs-server host 1.1.1.1
 tacacs-server key _$ecretkey!
#
 aaa new-model
 aaa authentication login default group tacacs+ local
 aaa authentication enable default group tacacs+ enable
 aaa authorization exec default group tacacs+ local if-authenticated
 aaa authorization commands 0 15 group tacacs+ local
 aaa accounting send stop-record authentication failure
 aaa accounting exec default start-stop group tacacs+
 aaa accounting commands 0 15 start-stop group tacacs+
 aaa accounting connection default start-stop group tacacs+
#


HUAWEI:
#
hwtacacs-server template ht
 hwtacacs-server authentication 1.1.1.1
 hwtacacs-server authorization 1.1.1.1
 hwtacacs-server accounting 1.1.1.1
 hwtacacs-server shared-key cipher _$ecretkey!
#
aaa
 authentication-scheme default
 authentication-scheme l-h
  authentication-mode hwtacacs local
  authentication-super hwtacacs super
 authorization-scheme default
 authorization-scheme hwtacacs
  authorization-cmd 3 hwtacacs
  authorization-mode  hwtacacs
 accounting-scheme default
 accounting-scheme hwtacacs
  accounting-mode hwtacacs
  accounting start-fail online
  accounting realtime 3
 recording-scheme scheme0                                                             
  recording-mode hwtacacs ht                                                     
 cmd recording-scheme scheme0                                                         
 outbound recording-scheme scheme0                                                    
 system recording-scheme scheme0 
 domain default
 domain default_admin
 domain huawei
  authentication-scheme l-h
  accounting-scheme hwtacacs
  authorization-scheme hwtacacs
  hwtacacs-server ht
#


Juniper SRX (хаброюзер m0ps):

 set system authentication-order tacplus
 set system tacplus-server 10.10.10.1 secret «key» 
 set system tacplus-server 10.10.10.1 source-address 192.168.1.1
 set system accounting events login
 set system accounting events change-log
 set system accounting events interactive-commands
 set system accounting destination tacplus
 set system login user REMOTE_SU full-name «Tacacs+ template for remote SU access»
 set system login user REMOTE_SU class super-user


Далее в Shell Profiles создаем профиль JuniperFullAccess в Custom Attributes которого создаем атрибут с именем local-user-name и значением — имя шаблона профиля пользователя (в моем примере — REMOTE_SU).
Теперь идем в Access Policies и в меню Authorization создаем соответствующее правило, согласно которого всем авторизовавшимся на девайсах Juniper применяется соответствующий Shell Profile.

Уточнения хаброюзера m0ps:
Дошли руки собрать лабу.
Все «ок», за исключением того, что все пользователи из АД могут залогиниться на устройства с уровнем привилегий 1. И только пользователи из указанной группы имеют уровень привилегий 15. Нашел документ на циско.ком аналогичный этому топику — в нем все шаги совпадают.
Я что-то сделал не так, или нужно как-то ограничивать возможность логиниться на устройства пользователей, которые не состоят в «интересных» группах?

Прошу прощения, вопрос можно считать снятым. Дело в том, что есть стандартное правило, согласно которого если не одно из сконфигурированных правил не подходит Shell Profile был Permit Access, а вот Command Sets — Denny all Commands.
Соответственно в Shell Profile выбираем DenyAccess и проблема решена.
Думаю стоит уточнить это в статье, т.к. еще кто-то может наступить на эти грабли.

Список используемой литературы


1. Understanding ACS 5.3 Configuration
2. Википедия — свободная энциклопедия
3. HedEx Lite — документация по оборудованию HUAWEI
Tags:
Hubs:
+4
Comments 7
Comments Comments 7

Articles