Aaron Walrath – Another IT Guy’s Meanderings
Set Up Windows 2003 IAS Server with RADIUS Authentication for Cisco Router Logins
As a companion to my article RADIUS Authentication for Cisco Router Logins, this post will discuss the configuration of a Windows 2003 R2 server for Cisco router logins using RADIUS authentication. In my example I will install the Internet Authentication Service to support RADIUS on a Windows 2003 R2 domain controller and give router login access to an Active Directory domain user.
Configure User(s) for RADIUS Authentication on Windows Server 2003 R2
First Go into Start > Admin Tools > Active Directory Users and Computers. Optionally you can create a new group and add users to it that you want to grant router login access. In this example I will grant access to the existing Domain Admins user group.
Now double click a user account that you want to provide router login capability. I will use the Administrator account.
In the user properties dialog click the Dial-in tab, then make sure that Remote Access Permission is set to “Allow access”. You can also set this to “Control access through Remote Access Policy”, this should work with the policy settings we’ll specify later. Click OK.
Install Windows 2003 IAS/RADIUS Service
Go to Start > Control Panel > Add or Remove Programs.
On the left click Add/Remove Windows Components.
Scroll down and highlight Networking Services, then click Details.
Place a check mark next to Internet Authentication Service, then click OK.
Click Next. Click Finish at the install confirmation window.
Configure Windows 2003 IAS/RADIUS Service for Cisco Router Logins
Now let’s configure the policies to allow our Cisco router to make authentications against this IAS/RADIUS server. Go to Start > Admin Tools > Internet Authentication Service.
In the left pane tree right click Remote Access Policies and choose New Remote Access Policy from the menu.
Select “Set up a custom policy” and type a name for your Cisco router policy. Click Next.
Click Add in the Policy Conditions.
Highlight the Windows Groups attribute type and click Add.
Использование 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 и само значение:
Это значение будет означать что авторизованному пользователю данной политикой нужно предоставить максимальный 15 уровень административного доступа на коммутаторе Cisco
В итоге список специфичных атрибутов в нашем случае будет иметь только одну позицию:
После этого перейдём на шаг завершения создания новой политики доступа, получив сводную информацию о заданных нами настройках.
По аналогии создаём вторую политику для организации доступа на чтение и при её создании, как и в первом случае, в качестве стандартного параметра RADIUS выбираем Service-Type равный значению Login , а вот значение специфического атрибута уже просто не создаём вообще.
При создании и планировании политик обратите внимание на то что имеет значение их порядок. Политики обрабатываются сверху вниз, и когда получается, что все условия в очередной политике соблюдены, их дальнейшая обработка прекращается. То есть с точки зрения безопасности и разрешения конфликтов между политиками правильней будет располагать политики в порядке возрастания административных полномочий.
Этап #4. Настройка коммутатора Cisco
Перейдём к настройке коммутатора. Так как мы собираемся использовать доменные учетные записи для аутентификации и авторизации, стоит уделить особое внимание вопросу безопасности и для коммуникаций с коммутатором вместо протокола Telnet использовать по возможности SSH. Входим в режим конфигурирования и включаем использование SSHv2 последовательностью команд:
При выполнении команды генерации RSA-ключей мы можем получить сообщение о необходимости сконфигурировать параметр конфигурации domain-name :
В таком случае нужно выполнить соответствующую настройку:
Затем настраиваем AAA аутентификацию и авторизацию таким образом, чтобы приоритетно использовалась RADIUS аутентификация, а в случае если RADIUS сервер окажется недоступен, – использовалась локальная аутентификация на базе встроенных учетных записей устройства.
Затем вводим информацию о сервере RADIUS и ключ (Shared secret), который в ранее был прописан для этого устройства на самом сервере RADIUS:
Для того чтобы сделать использование SSH обязательным и отключить Telnet при удалённом доступе выполним команды:
На этом минимальная настройка коммутатора закончена и можно испытать новый механизм аутентификации и авторизации в действии.
Aaron Walrath – Another IT Guy’s Meanderings
RADIUS Authentication Using Windows 2003 IAS for Cisco Router Remote Access IPsec VPN
In a previous post I discussed configuring an IPsec VPN between a Cisco router and a Windows PC with the Cisco VPN client installed. Today I’ll expand on this by configuring the VPN to utilize the RADIUS protocol to authenticate VPN users. This will ease administration and will allow users access to their VPN sessions using their directory services user accounts. For the RADIUS server I will use a Windows Server 2003 R2 that is part of an Active Directory domain with the IAS service installed. The IAS service can be just as easily configured with local user accounts on the Windows workgroup server if desired. When I first started implementing this I had great difficultly getting the IPsec VPN to work with RADIUS, I guess the IOS configuration commands can be a bit tricky. But now it just keeps on working!
Configure the Cisco Router IOS
In this example my router is configured as in the example Configure Cisco Router for Remote Access IPsec VPN Connections. Run through that article and come back here once you’ve completed it.
Next we need to modify AAA to allow user authentication using the RADIUS server.
Now we need to add the RADIUS server. Specify the IP address and a key to use.
That’s it for the configuration in the Cisco IOS. Now let’s move over to the Windows 2003 IAS configuration.
Configure Windows Server 2003 IAS RADIUS Service
If you have previously read my article Set Up Windows 2003 IAS Server with RADIUS Authentication for Cisco Router Logins, you have a Windows IAS server already set up and the configuration should be able to authenticate your IPsec VPN connections. One thing that I have noticed is that my IPsec VPN authentication does not work when I have the IAS service installed on a domain controller. If the IAS service is installed on a domain member server the VPN connections do work fine. To configure the Windows IAS service follow these steps:
On a domain controller go into Start > Admin Tools > Active Directory Users and Computers. Optionally you can create a new group and add users to it that you want to grant router login access. In this example I will grant access to the existing Domain Admins user group.
Now double click a user account that you want to provide router login capability. I will use the Administrator account.
In the user properties dialog click the Dial-in tab, then make sure that Remote Access Permission is set to “Allow access”. You can also set this to “Control access through Remote Access Policy”, in which case the user account will be granted permission by its group membership that will be specified in the policy. Since we’ll specify a group in the Remote Access Policy, the above step actually should not be necessary. Click OK.
Install Windows 2003 IAS/RADIUS Service
Now on the domain member server that will host the IAS service go to Start > Control Panel > Add or Remove Programs.
On the left click Add/Remove Windows Components.
Scroll down and highlight Networking Services, then click Details.
Place a check mark next to Internet Authentication Service, then click OK.
Click Next. Click Finish at the install confirmation window.
Configure Windows 2003 IAS/RADIUS Service for Cisco Router Logins
Now let’s configure the policies to allow our Cisco router to make authentications against this IAS/RADIUS server. Go to Start > Admin Tools > Internet Authentication Service.
In the left pane tree right click Remote Access Policies and choose New Remote Access Policy from the menu.
Select “Set up a custom policy” and type a name for your Cisco router policy. Click Next.
Click Add in the Policy Conditions.
Highlight the Windows Groups attribute type and click Add. (Page 2)
Click Add and we’ll select the user group that will be allowed access with this policy.
In this case I’m using a domain group and my group’s location is already set to the domain because this is a domain controller. I’m just going to use Domain Admins here. Type the group name and click Check Names. Then click OK.
We want to grant access to the Domain Admins so select “Grant remote access permission” and click Next.