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

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

 

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

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

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

 

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

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

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

 

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

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

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

На следующем шаге 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”

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

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

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

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

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

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

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

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

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

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

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

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

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

shell:priv-lvl=15

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

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

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

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

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

 

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

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

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

При выполнении команды генерации 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

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

radius-server host 10.160.160.160 key RjRh5adkj63D
service password-encryption

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

line vty 5 15
transport input ssh

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

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

• Aaron Walrath Blog - Install Windows 2008 R2 NPS for RADIUS Authentication for Cisco Router Logins
• Aaron Walrath Blog - RADIUS Authentication for Cisco Router Logins
• Youritguy's Blog - AAA RADIUS authentication with Windows Server 2008
• Daryl Hunter Blog - Cisco IOS-fu #7 - Cisco + RADIUS + Windows Server 2008 NPS