Поиск...

суббота, 24 января 2015 г.

Аутентификация, авторизация и аккаунтинг с использованием Cisco ACS 5.2

Доброго времени суток!!!

В прошлом посте мы с вами подготовили лабораторию для дальнейшей работы с Cisco ACS 5.2. Сегодня я предлагаю пойти дальше и настроить доступ к сетевому оборудованию AAA (аутентификацию, авторизацию и аккаунтинг) с использованием локальной базы Cisco ACS 5.2.
Как всегда, кто заинтересовался, добро пожаловать под кат…

Схема у нас осталась такая же. Приведу ее еще раз:


Итак, приступим. Начнем мы с cisco ACS 5.2. Открываем браузер и переходим на WEB-страницу сервера. После ввода логина и пароля должна открыться начальная страница:

 
Начнем мы с добавления устройств на сервер. В cisco ACS 5.2 значительно расширился функционал по добавлению устройств. Теперь можно группировать устройства не только по IP-адресу, но еще и по различным (придуманным вами или стандартным) группам (например, создавать группы по вендору, по расположению и так далее). В дальнейшем, каждой созданной группе можно назначать всевозможные параметры, такие как какой протокол AAA использовать (TACACS+ или RADIUS), каким администраторам можно управлять той или иной группой и так далее.
Сильно углубляться не будем, я покажу основной принцип, который в дальнейшем позволит вам создавать свои группы. Создадим группу по типу устройств (например, по вендору). Переходим во вкладку «Network Device Groups» -- «Device Type»:


Нажимаем «Create»:
 

Здесь указываем имя группы и можем нажимать «Submit». Если у вас есть желание данную группу определить внутрь другой группы, то нажимайте на «Select» и выбирайте там, куда именно ее определить:


Как видите, по умолчанию, доступна одна стандартная группа «All Devices Types». Если вам необходимо сделать более глубокий уровень вложений, то нажимайте «Create» и добавляйте новую группу. Таким образом в итоге можно получить довольно глубокую древовидную структуру. Мы так глубоко погружаться не будем и обойдемся стандартной группой. В итоге, созданная группа появится в списке:


Думаю, принцип создания групп понятен. Группировка, например, по месту расположения осуществляется таким же образом.
Идем далее. Теперь необходимо определить сетевые устройства, которые будут выступать в качестве клиентов ACS и протокол, по которому они будут работать. Переходим во вкладку «Network Devices and AAA Clients»:


Нажимаем «Create». Откроется следующее окно:


Здесь вводим следующее:
  • 1. Название;
  • 2. Выбираем протокол для работы (в нашем случае TACACS+);
  • 3. Задаем пароль для аутентификации устройств (в дальнейшем его нужно будет указать непосредственно на них);
  • 4. Задаем IP-диапазон (можно и конкретный IP-адрес). Будут «обслуживаться» только устройства из этого диапазона;
  • 5. Указываем соответствующую маску;
  • 6. Нажимаем «Add» (диапазон должен появиться в списке ниже);
  • 7. В этом пункте определяем принадлежность данных устройств к соответствующей группе. Нажимаем «Select»:


и выбираем ранее созданную группу. Нажимаем «OK». Затем «Submit». В итоге, в закладке «Network Devices and AAA Clients» должна появиться запись, как показана ниже:


Устройства добавили. Теперь необходимо добавить группы пользователей и, собственно, самих пользователей. Я предлагаю сделать две группы пользователей: администраторы с полным доступом и пользователи с ограниченными правами на управление устройствами.
Начнем с групп пользователей. Переходим во вкладку «Users and Identity Stores» -- «Identity Groups»:


Видно, что на данный момент есть только одна глобальная группа «All Groups». Нажимаем «Create»:


Здесь указываем название новой группы и ее принадлежность к группе по умолчанию. Затем нажимаем «Submit». Группа для ограниченных пользователей создается аналогично. В итоге у вас должны получиться две группы:


Группы создали, теперь необходимо создать пользователей и определить их в соответствующие группы. Переходим во вкладку «Users and Identity Stores» -- «Internal Identity Stores» -- «Users»:


Нажимаем «Create»:


Вводим следующее:
  • 1. Логин для пользователя;
  • 2. Описание (опционально);
  • 3. Пароль для пользователя для входа на устройство;
  • 4. Пароль для пользователя для входа в привилегированный режим;
  • 5. Для добавления пользователя в соответствующую группу нажимаем «Select»:


и определяем его в соответствующую группу.
Нажимаем «OK» и затем «Submit». Таким же образом создаем второго пользователя. В итоге у вас должно получиться вот так:


Пользователи созданы. Теперь необходимо настроить разграничение по доступу к устройству и командам. localadmin будет иметь доступ к устройству и ко всем командам, а localuser будет иметь доступ к устройству, но только к командам группы show и команде write memory (wr).
Настройка производится в несколько этапов. Сначала создадим профили, в которых укажем, какой Privilege Level будет доступен тому или иному пользователю. Для этого, переходим во вкладку «Policy Elements» -- «Authorization and Permissions» -- «Device Administration» -- «Shell Profiles»:


Следует отметить, что профиль, созданный по умолчанию («Permit Access»), дает доступ только к Privilege Level 1 (до команды enable на оборудовании). Нажимаем «Create»:


Сначала создадим профиль для группы администраторов. Обязательно указываем название (поле «Name») и, если необходимо, то описание. Затем переходим во вкладку «Common Tasks»:


Так как мы договорились дать администратору полный доступ к устройству, то в поле «Maximum Privilege» выбираем параметр «Static» и указываем значение «15». Остальные параметры оставляем без изменения (но если есть желание, то сами можете с ними потом поиграться). Нажимаем «Submit». Созданный профиль появится в списке. Таким же образом создаем политику для пользователей, в поле «Maximum Privilege» тоже указываем значение «15». Какие команды им можно будет выполнять мы укажем далее. В итоге, у вас должно быть два профиля:


Профили создали, теперь переходим к следующему этапу и создадим списки команд, которые позволено выполнять тому или иному пользователю, относящемуся к соответствующему профилю. Для этого переходим во вкладку «Policy Elements» -- «Authorization and Permissions» -- «Device Administration» -- «Commands Sets»:


Следует отметить, что список команд, созданный по умолчанию («DenyAllCommands»), запрещает выполнение любых команд. Создадим сначала набор команд для группы администраторов. Нажимаем «Create»:


Здесь указываем имя набора команд (обязательное поле), пояснение к нему (по желанию) и самое главное, отмечаем галку напротив «Permit any commands that is not in the table below». Это означает, что будут доступны команды, которые НЕ указаны в таблице ниже, т.е. все команды. Затем нажимаем «Submit».
Вы вернетесь на предыдущую страницу. Созданный набор команд появится в списке. Снова нажимаем «Create» и создадим набор команд, доступных группе обычных пользователей:


Здесь снова придумываем имя набору команд, примечание и затем переходим к добавлению разрешенных команд (на этот раз галку не ставим). Для добавления команд используется нижнее меню:
  • 1. Выбираем разрешить («Permit») команду;
  • 2. Прописываем непосредственно необходимую команду;
  • 3. Указываем аргумент этой команды. У некоторых команд есть несколько аргументов (видно если поставить «?» после команды), так что необходимо выбирать необходимый;
  • 4. Нажимаем «Add» для добавления команды в таблицу.
После добавления в таблицу всех необходимых для группы пользователей команд нажимаем «Submit». Наборы команд созданы.
Переходим к следующему этапу, на котором необходимо связать все, что мы создали ранее в единую политику. Политики состоят из:
  • - сервисов («Access Services»), отвечающих за доступ к устройству, к командам, которые можно выполнять и так далее, и четко идентифицирующих пользователя;
  • - правил («Service Selection Rules»), которые отвечают за попадание того или иного устройства (группы устройств) на обработку соответствующему сервису, согласно критериям, заданным в них.
Может показаться, что все сложно, но это не так. Главное один раз попробовать :). Итак, переходим во вкладку «Access Policies» -- «Access Services»:


Здесь видно два сервиса доступа, созданные по умолчанию. Они нам не понадобятся, и мы их отключим немного позже. Создадим свой сервис. Нажимаем «Create»:


Здесь указываем название сервиса «Name». Затем выбираем тип сервиса «Device Administration» (используется для доступа к устройству) из выпадающего меню. И ниже отмечаем галки на всех пунктах «Policy Structure», где:
  • Identity – отвечает за процесс идентификации пользователя, т.е. в какой базе искать того или иного пользователя (локальной, LDAP и т.д.);
  • Group Mapping – отвечает за проверку принадлежности пользователя к той или иной настроенной группе (admins или users);
  • Authorization – отвечает за авторизацию, т.е. за то, какие команды позволено выполнять тому или иному пользователю.
Как видно из набора параметров и как я писал выше, сервис отвечает за полную идентификацию пользователя. Нажимаем «Далее»:


На этой странице нужно указать поддерживаемые протоколы, с помощью которых будут аутентифицироваться пользователи (как будут посылаться логин и пароль, в открытом виде или в зашифрованном и т.д.). Нажимаем «Finish». Высветится вот такой запрос:


Он указывает на то, что сервис успешно создан и предлагается изменить правила «Service Selection Rules» (ну или привязаться к одному из них) для того, чтобы активировать созданный сервис. Нажмите пока «No». Вы увидите, что сервис создался, но он не активен, в отличие от созданных по умолчанию. Надо это исправить. Переходим во вкладку «Access Services» -- «Service Selection Rules»:


Видно, что есть два правила по умолчанию. К каждому правилу привязан свой сервис (столбец «Results»). Обратите внимание на столбец «Conditions». Там есть лишь один критерий «Protocol». Т.е. в зависимости по какому протоколу к ACS обращается сетевое устройство (Radius или TACACS+), оно попадает дальше на обработку соответствующему сервису (помните, я говорил, что правилами идентифицируется именно устройство?).
Мы с вами пойдем своим путем и создадим новое правило, критериями у которого будут протокол и принадлежность к группе устройств, а результат – отправка на обработку нашему созданному сервису.
Для начала, добавим недостающий критерий. Нажимаем на «Customize»:


Выбираем из левого столбца необходимый критерий, нажимаем на стрелку и переносим в правый столбец. Затем, вернувшись обратно, нажимаем на «Create». Откроется окно создания правила:


Здесь указываем имя правила, проверяем, чтобы оно было включено. Далее отмечаем галки для активизации критериев («Conditions») и в каждом из них, нажимая кнопку «Select», выбираем нужное нам значение («Protocol» – Tacacs, «Network Device Group: Device Type» – Cisco_Devices (мы ее создавали ранее)). Затем в поле «Results» из выпадающего меню выбираем ранее созданный сервис «MyService». Нажимаем «OK» и созданное правило появится в списке.
Для того, чтобы нам не мешали созданные по умолчанию правила и сервисы мы их отключим. Для этого достаточно отключить не нужные правила, а сервисы, привязанные к ним, отключатся автоматически. Выбираем правило «Rule-1» из списка и внизу нажимаем кнопку «Edit»:


В открывшемся окне ставим статус правила «Disabled» и нажимаем «OK». Точно так же выключаем второе правило. После этих действий, внизу страницы нажмите на «Save Changes». И вот что в итоге вы увидите:


Правила по умолчанию выключены, автоматически выключились и привязанные к ним сервисы. Осталось активным только наше правило и наш сервис.
Но и это пока еще не всё. Осталось настроить наш сервис, а в частности, его три параметра. Начнем по порядку. Идем в «MyService» -- «Identity»:


По умолчанию стоит «DenyAccess». Нажимаем на «Select», откроется дополнительное окно, где из списка выбираем «Internal Users» (так как мы используем локальную базу) и нажимаем «OK». Параметр поменяется, нажимаем «Save Changes» и переходим в «MyService» -- «Group Mapping»:


Так как мы создали один сервис, и он должен обслуживать все группы пользователей, то оставляем параметр по умолчанию. В противном случае, для каждого сервиса надо было бы указывать соответствующую группу.
Переходим в «MyService» -- «Authorization» и сразу идем в «Customize» (правый нижний угол):


В «Customize» переносим необходимые параметры («Identity Group» - в качестве критерия, «Shell Profile» и «Commands Sets» - в качестве результата) из левого столбца в правый (ненужные параметры, если такие есть у вас по умолчанию, убираем в левый столбец). Нажимаем «OK». Теперь создадим первое правило для группы администраторов. Нажимаем «Create»:


Указываем имя правила, проверяем, чтобы оно было включено. Затем:
  • 1. Делаем критерий «Identity Group» активным и, нажав на «Select», выбираем из перечня соответствующую группу;
  • 2. Назначаем этой группе профиль, созданный для нее ранее («Privilege_15»);
  • 3. Назначаем этой группе, созданный ранее набор команд («Permit_All»);
  • 4. Нажимаем «OK».
Таким же образом создаем правило для группы обычных пользователей с соответствующими параметрами. В итоге, у вас должно быть два правила:


Нажимаем «Save Changes» если еще не нажимали.
С сервером ACS закончили. Итак, что у нас сейчас настроено:
- сервер ACS будет принимать запросы на доступ к устройствам, находящимся в сети 192.168.1.0/24 по протоколу Tacacs. Эти устройства попадают в группу Cisco_Devices. Другие устройства обслуживаться не будут. Далее идет аутентификация пользователей, используя локальную базу ACS. В соответствии с тем, с помощью какой учетной записи идет обращение к устройству, пользователь будет попадать в одну из двух групп («Local_Admins» (группа администраторов) или «Local_Users» (группа пользователей)). Группе администраторов разрешен полный контроль над устройством, а группе пользователей – только команды группы show и команда write memory.
Теперь осталось настроить AAA на нашем роутере и проверить, все ли работает. Идем на наш роутер:

L3_Switch#conf t – заходим в режим конфигурирования
L3_Switch(config)#crypto key generate rsa general-keys modulus 1024 – генерируем ключ для включения SSH
L3_Switch(config)#aaa new-model – включаем режим AAA
L3_Switch(config)#username administrator privilege 15 password cisc0 – заводим локального администратора (на случай недоступности ACS)
L3_Switch(config)#aaa authentication login default group tacacs+ local – включаем аутентификацию при входе на устройство с помощью ACS по протоколу TACACS, а если он не доступен, то используется локальная база (т. к. используется «default», то проверка включается на всех линиях)
L3_Switch(config)#aaa authentication enable default group tacacs+ enable - включаем проверку входа в привилегированный режим (enable-режим) с помощью ACS, если он не доступен, то используется пароль, установленный с помощью команды enable secret
L3_Switch(config)#aaa authorization exec default group tacacs+ local – включаем проверку прав на запуск EXEC (тот же enable) режим с помощью сервера ACS, если он не доступен, то используются права локального администратора
L3_Switch(config)#aaa authorization commands 15 default group tacacs+ local – включаем проверку прав на запуск команд, относящихся к Privilege Level 15, через сервер ACS, если он не доступен, то используются права локального администратора
L3_Switch(config)#aaa authorization config-commands – включаем проверку прав на запуск команд конфигурации (команда conf t)
L3_Switch(config)#aaa authorization console – включаем авторизацию на консольной линии (по умолчанию она выключена)
L3_Switch(config)#aaa accounting exec default start-stop group tacacs+ - включаем аккаунтинг (запись действий пользователя на устройстве) в режиме EXEC
L3_Switch(config)#aaa accounting commands 15 default start-stop group tacacs+ - включаем аккаунтинг выполненных команд, относящихся к Privilege Level 15
L3_Switch(config)#tacacs-server host 192.168.1.100 key Pa$$12345 – указываем IP-адрес сервера и пароль для подключения (мы его задавали на самом ACS);

Перечень этих команд немного избыточен. Например, aaa authorization config-commands можно и не вводить, так как localuser и так не будет иметь возможность выполнить команду conf t, так как в списке команд, прикрепленной к его группе ее нет. Ну а какие команды можно убрать еще – это вам домашнее задание :).
Если у вас на устройстве стоит ни линиях vty и console Privilege Level 15, то уберите его, чтобы не мешать нашим проверкам и дальнейшей работе:

L3_Switch(config)#line vty 0 15 
L3_Switch(config-line)#no privilege level 15
и 
L3_Switch(config)#line console 0 
L3_Switch(config-line)#no privilege level 15

Переходим к проверкам. По очереди зайдем на устройство под разными учетными записями:
 

Используя учетную запись из группы администраторов (localadmin) нам доступны любые команды и режимы по конфигурированию устройства. Теперь зайдем под учетной записью из группы пользователей (localuser):


Видно, что есть доступ на само устройство, но нет доступа на вход в режим конфигурирования (conf t), есть доступ к команде именно write memory (ни wr, ни write <любой другой атрибут, отличный от memory>), есть доступ к командам группы show.
Чтобы посмотреть статистику на сервере ACS необходимо пройти по следующему пути в меню: «Monitoring and Reports» -- «Launch Monitoring & Reports Viewer». Откроется дополнительная вкладка в браузере:


Это основная панель, из которой вы можете просматривать любую информацию. Я приведу пример статистики по аутентификации и авторизации, ну а остальную статистику вы, думаю, найдете сами.
Так выглядит статистика по удачной/неудачной аутентификации:


Так выглядит отчет о запрете/разрешении на выполнение команд (авторизация):


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


Здесь видно, что за пользователь пытался зайти на устройство, каким сервисом он обрабатывался, на какое устройство пытался зайти, с какого IP-адреса. Так же указана причина (в данном случае пользователя просто нет в базе ACS).
Ну вот и все :). Все что мы планировали в начале, мы сделали. Пост получился весьма объемным, но надеюсь весьма познавательным и информативным.

По всем возникающим вопросам обращайтесь ко мне через комментарии или лично. Координаты можно найти вот тут.

Если есть желание отблагодарить, то киньте немного WebMoney (Яндекс.Деньги, PayPal) или дайте ссылку на мой блог, если будете еще на каких-нибудь форумах или сайтах :).

С нетерпением жду вас в следующих постах!!!

С уважением, Ant0ni0n

5 комментариев:

  1. Антон в статье про АСУ под ссылкой - http://www.go-to-easyit.com/2013/07/cisco-asa-3.html, АСА с IOS версией 8.4.2, у меня же на АСЕ IOS 8.2, вопрос: подойдут ли настройки 8.4.2 под 8.2 ???
    За ранее благодарен...

    ОтветитьУдалить
    Ответы
    1. Добрый день!
      Большая часть конфигурации и команд подойдет. Отличия будут в настройке NAT, так как начиная с версии 8.3 там произошли довольно большие преобразования.
      Большая просьба к вам писать коменты и вопросы именно в том посте, к которому они адресованы... А то по началу и не понял вопроса, увидев его в посте по ACS 5.2 :)

      С уважением, Антон Шешко

      Удалить
  2. Доброго дня, Антон ! Скажите, насколько, по Вашему мнению, будет функциональна связка Cisco ISR (2911 как вариант)+ACS 5.х+Active Directory для контроля доступа доменных пользователей в интернет ? Возможно ли такое вообще, или тут нужна все же ASA ?

    ОтветитьУдалить
    Ответы
    1. Доброго времени суток!
      По моему мнению для такой задачи необходимо использовать cisco ASA (Identity FireWall технология), так как все-таки cisco ASA для этого и предназначена, и является устройством безопасности.

      Удалить
  3. Zdrastvuyte,a kak mojno, pryam zayti v privileged mode?

    ОтветитьУдалить