Использование RADIUS (Windows Network Policy Server) для аутентификации и авторизации на коммутаторах Cisco

imageВ предыдущей заметке была рассмотрена процедура установки и настройки RADIUS сервера в составе роли Network Policy and Access Services в Windows Server 2008 R2 для использования аутентификации и авторизации на контроллерах APC Web/SNMP Management card. В случае с коммутаторами Cisco на стороне настроек сервера RADIUS всё делается по аналогии, за исключением некоторых моментов. Рассмотрим эти моменты и проведём настройку коммутатора на примере модели Catalyst WS-C2950-24.

image 

Этап #1. Создание групп доступа в домене

Начнём с того что в нашем примере создадим в домене две локальных группы безопасности.

image

В первую группу включим пользователей которым нужно предоставить полный административный доступ на управление коммутаторами, во вторую соответственно, — доступ только на чтение текущей конфигурации и состояния устройств. При этом, стоит помнить, что для пользователей, которые будут включаться в эти группы должно быть установлено разрешение в домене, дающее право удалённого доступа (значение настройки Network Access Permission на закладке Dial-In свойств учетной записи пользователя)

 

Этап #2. Добавление клиентов на сервер RADIUS

На сервере RADIUS в консоли Network Policy Server создадим для нашего коммутатора запись о клиенте, указав его имя или IP-адрес и ключ (Shared secret). Для этого в дереве консоли NPS развернём раздел RADIUS Clients and Servers и на элементе RADIUS Clients откроем контекстное меню и выберем пункт New и заполним соответствующие поля

image

Значение поля Friendly name может отличаться от DNS имени. Оно потребуется нам в дальнейшем для идентификации конкретного сетевого устройства при создании политик доступа – Remote Access Policy. Опираясь на это имя мы сможем задавать например маску по которой будут обрабатываться определённой политикой доступа несколько разных RADIUS клиентов.

 

Этап #3. Создание политик доступа на сервере RADIUS

С помощью политик доступа NPS мы произведём связку созданных ранее записей о коммутаторах-клиентах RADIUS и доменных групп безопасности, определяющих уровень доступа к этим коммутаторам. То есть в нашем случае будет создано две политики доступа —  с полными правами и только для чтения.

Итак, создадим первую политику, определяющую полный административный доступ к коммутатору. В дереве консоли NPS в разделе Policies > Network Policies откроем контекстное меню и выберем пункт New. В открывшемся мастере создания политики введём название создаваемой политики (пусть например оно будет созвучно с группой доступа) и выберем тип соединения Unspecified

image

На следующем шаге Specify conditions нам нужно добавить условия при которых будет применяться данная политика RADIUS. Добавим два условия, – чтобы пользователь, проходящий авторизацию, входил в определенную доменную группу безопасности, и устройство, к которому осуществляется доступ, имело определённое имя «Friendly name». Через кнопку Add добавим условия по типам Windows Group и Client Friendly Name.

Здесь важно понимать, что для условия с Windows Group использование встроенных групп безопасности таких как, например, Domain Admins не является хорошей практикой с точки зрения безопасности.
Для условия Client Friendly Name в качестве значения можно использовать как конкретные «Friendly name» устройств так и их маску, например в нашем случае политика будет применяться ко всем клиентам RADIUS у которых в свойствах атрибута «Friendly name» указано значение начинающееся с “KOM-AD01-SW

В итоге, в нашем случае, список условий будет выглядеть так:

image

На следующем шаге Specify Access Permission укажем, что данная политика является политикой, разрешающей доступ – Access granted

image

На следующем шаге Configure Authentication Methods отключим все методы аутентификации и включим метод Unencrypted authentication (PAP, SPAP), так как коммутатор в нашем случае поддерживает только этот метод:

image

При этом мы получим предупреждение о том, что выбранный метод является не безопасным и для того, чтобы оставить выбор в силе, нужно нажать – No.

image

На следующем шаге настройки дополнительных ограничений Configure Constraints можно ничего не изменять и перейти к шагу конфигурационных настроек Configure Settings, где в разделе настроек стандартных атрибутов RADIUS удалим имеющиеся по умолчанию там два атрибута и добавим новый по кнопке Add.

image

В открывшемся окне выбора стандартных атрибутов, выберем Service-Type и нажмём Add.

image

Переключатель значения атрибута Attribute value установим в положение Others и из выпадающего списка выберем значение Login

image

В итоге список стандартных атрибутов RADIUS в нашем случае будет иметь только одну позицию:

image

Теперь переключимся на закладку Vendor Specific и вызовем диалог добавления атрибута по кнопке Add

image

В открывшемся списке выберем тип атрибута Vendor-Specific (RADIUS Standard) и вызовем диалог добавления атрибута по кнопке Add

image

В окне информации об атрибутах для добавления нового атрибута нажмём Add 

image

В окне добавления атрибута из ниспадающего списка выберем вендора оборудования к которому мы настраиваем доступ, в нашем случае это Cisco , укажем что атрибут соответствует стандартам RADIUS RFC и нажмём кнопку Configure Attribute чтобы настроить значение атрибута

image

В открывшемся окне конфигурации значения атрибута введём значение номера атрибута – 1, тип значения строковой – String и само значение:

shell:priv-lvl=15

Это значение будет означать что авторизованному пользователю данной политикой нужно предоставить максимальный 15 уровень административного доступа на коммутаторе Cisco

image

В итоге список специфичных атрибутов в нашем случае будет иметь только одну позицию:

image

После этого перейдём на шаг завершения создания новой политики доступа, получив сводную информацию о заданных нами настройках.

image

По аналогии создаём вторую политику для организации доступа на чтение и при её создании, как и в первом случае, в качестве стандартного параметра RADIUS выбираем Service-Type равный значению Login , а вот значение специфического атрибута уже просто не создаём вообще.

image

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

 

Этап #4. Настройка коммутатора Cisco

Перейдём к настройке коммутатора. Так как мы собираемся использовать доменные учетные записи для аутентификации и авторизации, стоит уделить особое внимание вопросу безопасности и для коммуникаций с коммутатором вместо протокола Telnet использовать по возможности SSH. Входим в режим конфигурирования и включаем использование SSHv2 последовательностью команд:

configure terminal 
crypto key generate rsa modulus 1024 
ip ssh version 2

image

При выполнении команды генерации RSA-ключей мы можем получить сообщение о необходимости сконфигурировать параметр конфигурации domain-name:

% Please define a domain-name first.

В таком случае нужно выполнить соответствующую настройку:

KOM-AD01-SW003(config)# ip domain-name mydom.holding.com

Затем настраиваем AAA аутентификацию и авторизацию таким образом, чтобы приоритетно использовалась RADIUS аутентификация, а в случае если RADIUS сервер окажется недоступен, – использовалась локальная аутентификация на базе встроенных учетных записей устройства.

aaa new-model 
aaa authentication login default group radius local 
aaa authorization exec default group radius if-authenticated

image

Затем вводим информацию о сервере RADIUS и ключ (Shared secret), который в ранее был прописан для этого устройства на самом сервере RADIUS:

radius-server host 10.160.160.160 key RjRh5adkj63D
service password-encryption

image

Для того чтобы сделать использование SSH обязательным и отключить Telnet при удалённом доступе выполним команды:

line vty 5 15
transport input ssh

image

На этом минимальная настройка коммутатора закончена и можно испытать новый механизм аутентификации и авторизации в действии.

Источники информации:

Всего комментариев: 9 Комментировать

  1. kvazar /

    Спасибо за статью, будем настраивать на всех своих коммутаторах

  2. Саша /

    спасибо за статью Алексей. настроил себе аутентификацию. некоторое время не мог зайти в прив. режим под локальной учеткой (при недоступном радиус-сервере). дело оказалось в том что у локальной учетки уже был 15 режим, а enable-пароль в конфигурации свича не был установлен. Убрал 15 привилегию с лок. учетки и задал пароль прив. режима — все заработало. Коммутатор стал доступен в любом случае!

  3. Александр /

    сервер не дает добавить более 50 радиус-клиентов :(
    что делать Алексей?

  4. Илья /

    Спасибо за статью. У меня все настроено аналогично, все работает. Но есть необходимость доступа на коммутатор человека, у которого нет доменной учетки (он из другой фирмы). Зато у него есть локальная учетка на коммутаторе. Как бы сделать возможным одновременный доступ по локальным учеткам и через радиус. Или настроить так, чтобы не найдя логин на сервере, коммутатор предлагал логиниться локально (это идеальны вариант).
    Что бы Вы посоветовали?

    1. Алексей Максимов /

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

  5. Ilya /

    Алексей, подскажите, возможно вы настраивали радиус в режиме прокси. Ситуация: несколько доменов в одной организации. В разных доменах разные пользователи. На каталист надо ходить людям из разных доменов. Пробовал настроить прокси сервер, который будет перенаправлять запросы другим радиус серверам, но, увы, не работает. Есть вариант в качестве прокси сервера использовать freeradius линуксовый. Вдруг Вы что то знаете об всем вышеописанном. Заранее спасибо.

    1. Алексей Максимов /

      Не имел опыта настройки в режиме прокси.

  6. Сергей /

    У меня не прокатила настройка с shell для 15 уровня. Зато замечательно сработала сервис-тайп Администраторы. Тогда я получаю полный доступ к режиму enable в shell.
    если ставлю , как тут пишут только login , то только консоль.

Добавить комментарий