CISCO + Radius на Windows 2008\2012 NPS
Настроим аутентификацию по доменным учеткам на оборудовании cisco:
На Доменконтроллере:
1. Создаем группу безопасности (например «radius»)
2. Помещаем туда нужные учетки пользователей
У учеток, которые будут в группе должно быть установлено разрешение, дающее право удалённого доступа
(Network Access Permission на закладке Dial-In)
На Windows 2012\2008 сервере для радиуса:
1. Устанавливаем роль Network Policy Server (все по дефолту)
В консоли Network Policy Server:
Правой кнопкой мыши по «NPS(local)» — Register Server in Active Directory
2. Добавление клиентов на RADIUS
В консоли Network Policy Server:
Radius Clients and Servers — Radius Clients — New ( указать имя(Friendly name), IP, ключ(Shared secret), vendor name — cisco )
В имени(Friendly name) делаем маску «cisco_» — пример cisco_CORBINA
3. Политика доступа на RADIUS
Свяжем записи о клиентах и доменных групп безопасности
Policies — Network Policies — New ( Указать имя, тип соединения — Unspecified )
В Specify conditions добавим условия применения политики RADIUS:
3.1 пользователь должен входить в определенную доменную группу безопасности
3.2 устройство должно иметь определённое «Friendly name» в шаге 2 — Add — добавить условия Windows Group и Client Friendly Name
Политика будет применяться к RADIUS клиентам, у которых свойство атрибута «Friendly name» = значение начинающееся с «cisco_»
4. Specify Access Permission – Access granted
5. Configure Authentication Methods:
5.1 удалим все методы аутентификации
5.2 включим — Unencrypted authentication (PAP, SPAP), т.к. наше устройство поддерживает только этот метод
6. Выйдет предупреждение, нажмем – No
7. Configure Constraints ничего не указываем, идем дальше
8. Configure Settings, раздел стандартных атрибутов (Radius Attributes Standard):
8.1 удалим два имеющихся по умолчанию атрибута
8.2 добавим новый — Add — в открывшемся окне выбора атрибутов — Service-Type — Add
8.3 Переключатель Attribute value — Others — выберем Login — ok
8.4 Ниже слева Radius Attributes Standard закладка Vendor Specific — Add
8.5 Тип атрибута — Vendor-Specific (RADIUS Standard) — Add — Add
8.6 Vendor: select from list — cisco, пункт — Yes. It conforms, жмем Configure Attribute
8.7 Значения атрибута – 1, формат строковый – String, значение — shell:priv-lvl=15 — ok
8.8 Ok — завершаем
9. Policies — Connection Request Policies — оставим по умолчанию
На CISCO:
Конфигурируем ssh второй версии:
configure terminal
crypto key generate rsa modulus 1024
ip ssh version 2
Если ругнулся:
% Please define a domain-name first.
Тогда (cisco_corb — заменить на имя оборудования):
ip domain name cisco_CORBINA.local
Аутентификация сначала на радиусе, если недоступен — локально:
aaa authentication login default group radius local
Авторизация достаточно локальной:
aaa authorization exec default local
Укажем сервер и ключ из шага «2. Добавление клиентов на RADIUS»:
radius-server host 192.168.10.2 key gh2@t#
service password-encryption
line vty 5 15
transport input ssh
Проверка:
Не разрывая установленного соединения проверяем:
1. Новое соединение с включенным NPS Radius
2. Новое соединение с выключенным NPS Radius
Сохраняемся:
wr
Логи пишутся в журнале windows, искать по ключевому слову «cisco» или ip адресу
Либо вариант с более новыми версиями IOS
Сначала Радиус (NPS)
На CISCO
ROUTER>enable
ROUTER#config terminal
ROUTER(config)#username Your_Name priv 15 secret Your_Pass
ROUTER(config)#aaa group server radius Your_NPS_SERVER
ROUTER(config-sg-radius)#server-private 192.168.10.10 auth-port 1812 acct-port 1813 key CISCO
ROUTER(config)#aaa authentication login default group Your_NPS_SERVER local
ROUTER(config)#aaa authorization exec default group Your_NPS_SERVER local if-authenticated
ROUTER(config)#aaa authorization console
Настраиваем доменную аутентификацию на сетевом оборудовании
При обслуживании больших сетей системные администраторы часто сталкиваются с проблемами аутентификации на сетевом оборудовании. В частности, довольно сложно организовать нормальную работу нескольких сетевых администраторов под индивидуальными учетными записями на большом количестве оборудования (приходится вести и поддерживать в актуальном состоянии базу локальных учетных записей на каждом устройстве). Логичным решение было бы использовать для авторизации уже существующей базы учетных записей — Active Directory. В этой статье мы разберемся, как настроить доменную (Active Directory) аутентификацию на активном сетевом оборудовании (коммутаторы, маршрутизаторы).
Не все сетевое оборудование популярных вендоров (CISCO, HP, Huawei) поддерживает функционал для непосредственного обращения к каталогу LDAP, и такое решение не будет универсальным. Для решения нашей задачи подойдет протокол AAA (Authentication Authorization and Accounting), фактически ставший стандартом де-факто для сетевого оборудования. Клиент AAA (сетевое устройство) отправляет данные авторизующегося пользователя на сервер RADIUS и на основе его ответа принимает решение о предоставлении / отказе доступа.
Протокол Remote Authentication Dial In User Service (RADIUS) в Windows Server 2012 R2 включен в роль NPS (Network Policy Server). В первой части статьи мы установим и настроим роль Network Policy Server, а во второй покажем типовые конфигурации сетевого устройств с поддержкой RADUIS на примере коммутаторов HP Procurve и оборудования Cisco.
Установка и настройка сервера с ролью Network Policy Server
Как правило, сервер с ролью NPS рекомендуется устанавливать на выделенном сервере (не рекомендуется размещать эту роль на контроллере домена). В данном примере роль NPS мы будем устанавливать на сервере с Windows Server 2012 R2.
Откройте консоль Server Manager и установите роль Network Policy Server (находится в разделе Network Policy and Access Services).
После окончания установки запустите mmc-консоль управления Network Policy Server. Нас интересуют три следующих раздела консоли:
- RADIUS Clients — содержит список устройств, которые могут аутентифицироваться на сервере
- Connection Request Policies – определяет типы устройств, которые могут аутентифицироваться
- Network Polices – правила аутентификации
Добавим нового клиента RADIUS (это будет коммутатор HP ProCurve Switch 5400zl), щелкнув ПКМ по разделу RADIUS Clients и выбрав New. Укажем:
- Friendly Name:sw-HP-5400-1
- Address (IP or DNS): 10.10.10.2
- Shared secret (пароль/секретный ключ): пароль можно указать вручную (он должен быть достаточно сложным), либо сгенерировать с помощью специальной кнопки (сгенерированный пароль необходимо скопировать, т.к. в дальнейшем его придется указать на сетевом устройстве).
Отключим стандартную политику (Use Windows authentication for all users) в разделе Connection Request Policies, щелкнув по ней ПКМ и выбрав Disable.
Создадим новую политику с именем Network-Switches-AAA и нажимаем далее. В разделе Сondition создадим новое условие. Ищем раздел RADIUS Client Properites и выбираем Client Friendly Name.
В качестве значения укажем sw-?. Т.е. условие будет применяться для всех клиентов RADIUS, начинающийся с символов :”sw-“. Жмем Next->Next-> Next, соглашаясь со всеми стандартными настройками.
Далее в разделе Network Policies создадим новую политику аутентификации. Укажите ее имя, например Network Switch Auth Policy for Network Admins. Создадим два условия: в первом условии Windows Groups, укажем доменную группу, члены которой могут аутентифицироваться (учетные записи сетевых администраторов в нашем примере включены в группу AD Network Admins) Второе условие Authentication Type, выбрав в качестве протокола аутентификации PAP.
Далее в окне Configure Authentication Methods снимаем галки со всех типов аутентификации, кроме Unencrypted authentication (PAP. SPAP).
В окне Configure Settings изменим значение атрибута Service-Type на Administrative.
В остальных случаях соглашаемся со стандартными настройками и завершаем работу с мастером.
И, напоследок, переместим новую политику на первое место в списке политик.
Настройка сетевого оборудования для работы с сервером RADUIS
Осталось настроить наше сетевое оборудование для работы с сервером Radius. Подключимся к нашему коммутатору HP ProCurve Switch 5400 и внесем следующе изменение в его конфигурацию (измените ip адрес сервера Raduis и пароль на свои).
Совет. Если в целях безопасности вы запретили подключаться к сетевому оборудованию через telnet, эти строки нужно удалить из конфига:
Не закрывая консольное окно коммутатора (это важно!, иначе, если что-то пойдет не так, вы более не сможете подключиться к своему коммутатору), откройте вторую telnet-сессию. Должно появиться новое окно авторизации, в котором будет предложено указать имя и пароль учетной записи. Попробуйте указать данные своей учетной записи в AD (она должна входить в группу Network Admins ). Если подключение установлено – вы все сделали правильно!
Для коммутатора Cisco конфигурация, предполагающая использование доменных учетных записей для аутентификации и авторизации, может выглядеть так:
Для Cisco ASA конфигурация будет выглядеть так:
Совет. Если что то-не работает, проверьте:
- Совпадают ли секретные ключи на сервере NPS и коммутаторе (для теста можно использоваться простой пароль).
- Указан ли правильный адрес NPS сервера в конфигурации. Пингуется ли он?
- Не блокируют ли межсетевые экраны порты 1645 и 1646 между коммутатором и сервером?
- Внимательно изучите логи NPS сервера
RBAC Radius with Microsoft NPS 2012 R2
In this configuration I’m at looking at using Microsoft NPS 2012 R2 as radius server and I’m going to skip the installation of NPS because it really is just a next, next, finish installation. In this demo I already have this NPS system connected to a Windows domain, my goal is to create role based access on Cisco IOS routers while using radius to login. I’ll have a couple for active directory accounts each them will represent different types of allowed access to these IOS routers. One account will get full administrative access while the other will only get read access, how cool cat is that 😉
We have to get some house-cleaning things done first before we jump into it. To keep this simple in this example I’m only using one router and this router is able to reach the radius server. I’ll have to create an enable secret on the device, create a local username with a password, and turn AAA (Authentication, Authorization, Accounting). I like to create my own AAA method lists one for the console logins and one for remote logins here is what I got so far:
The router needs to know where radius server is located, we also need to put in a radius key and this needs to match between both the router and radius server.
If our router has more than one active interface we also should specify which IP interface we want the radius information to come from. In this example GigabitEthernet 0/1 will be the source interface.
Apply this AAA method to the console and VTY ports:
The magic begins with the Microsoft NPS server although any radius server is just as magical. We first have to create our client list within the Microsoft NPS. I have just used the defaults and have kept note of the radius key we configured earlier. This is pretty simple, expand the Radius Clients and Servers folder and right-click on Radius Clients and select new.
A new window will show, populate the information with a friendly name of the device you wish to add, IP address of the device and the radius key. After that select OK.
NOTE: Make sure the address matches to what you have configured as the source-interface on the router in this example it was GigabitEthernet0/1.
Once we have the all the clients in the client list we can now go to the Connection Request Polices. I usually just delete the existing policy, Use Windows authentication for all users and create a new policy called Radius-Login. Right-click on the Connection Request Policy folder, select new and follow these steps:
- Add a policy name and click next.
- Add a condition, (I usually do a a day and time condition and select the time frame you want logins to occur. Select next.
- Accept the defaults, Authenticate requests on this server, select next.
- Don’t override anything, select next
- Leave the defaults which is blank on everything, select next.
- At the Connection Request Policy summary page it should look like something like below, select finish.
Go to the Network Policy Folder you will see some policies already created, delete those policies. We are going to create our own and the first policy is going to be a Network Administrators policy which will give full access to the IOS router if the user belongs to the correct Windows Security group. Right-click on the Network Policy folder and select new, new window will appear. Type in the policy name. In this example I’m using Allow Network Administrators — Administrative Access, select next. Under conditions select User Groups and in this example I have already created a security group on the Windows directory called Network Administrators, select next. On the following screen grant access and select next as well.
In the Authentication Methods clear the following check-boxes and select the Unencrypted Authentication (PAP, SPAP), select next and disregard the warning. On the following screen Configure Constraints accept the defaults select next.
We should be at the Configure Settings page, under the Radius Attributes delete the existing attributes and add Service-Type Administrative.
Under Vendor Specific we need to add to a Cisco-AV Pair to tell the router to go to privilege level 15, select next when you add the shell:priv-lvl=15 in the Cisco-AV.
You are now at the summary page and it should pretty similar to what I have below, select Finish!
You have now just created your first radius network policy. If all is well and if you have a user in Windows Security group you should be able to login into the router via radius. In this example I was able to login into the HQ router with my Windows active directory username and password.
Here is the debug information of AAA when I logged into the router using radius:
So we have done pretty good but what about if we had a junior network technician and we did not want to allow full administration access to the device but this technician needs to be able to use show commands? How would we be able to do this with radius? Well with Cisco IOS you can use parser views, basically you configure a parser view on the IOS router call it name and configure the view to only allow the commands you want. You configure the radius server to pass the name of the parser view you created on the IOS router, if the parser view name matches the router will put that user into that view and only allow the user to use the commands that are configured in that view. More information about parser views can be found on Cisco website: Role-Based CLI AccessВ
So in this example we are going to create a parser view called SHOWMODE and only allow show commands. In the enable prompt we want to be in «root view mode» to do this we would type enable view, the router is going to be asking for a password and that is your enable secret password you created at the beginning of this post.
NOTE: If you have Radius enabled you will have to at least disable the client in NPS when you are first configuring a parser view. By disabling the client in NPS the router will fail-back to its local database of username and passwords to authenticate. The reason for this is because the router will try to use the NPS server to authenticate, this may not sound like a problem but the router is not using your username when you issue the command enable view. If your radius server has logging enabled you’ll see that the router is using a different username called root. Since root is not in our Windows Active Directory the radius server will reject the request. Although you could create a user called root in Windows Active directory and put that user in the correct security groups to allow logins using radius that just doesn’t sound like a good idea. The simplest method is to disable the client in NPS and use your enable secret password. Give it a second or two as this has to timeout before it fails-back to the local username and password database.
Now that we have verified we are in «root view» let’s go to configuration mode and create a parser view called SHOWMODE. We also have to create another secret password this should be different from the enable secret.
Once we have the password created we can tell the router what commands we want to allow in this view. In this example we are only allowing show commands so the command would be:
We can test this parser view by going into it by using the command enable view SHOWMODE. We are prompt for the password to enter this view (Again the client on NPS should be disabled so that we can use our local username and password database on the router).
If I issue a question mark (?) I get a list of the commands I can issue: (It looks I can only use show commands)
So we have created a parser view on our router now lets configure our Microsoft NPS server to use that parser view when our junior technician logs into this router. We have to create a new network policy in NPS. In this example I’m calling it Allow Network Operators — Read Only. Follow the steps you did before when we first created the Network Administrators policy the only difference of course is going to be a different Windows Active Directory security group and our radius attributes. We only need to focus on the Vendor Specific section of the network policy under the radius attributes section. We need to add a different Cisco AV-Pair called shell:cli-view-name=SHOWMODE and also add the shell:priv-lvl=15.
It would look something like this, select next.
We now should be at the summary screen of the new policy we just created and to give you a reference here is what I have for this example.
Once we select finish we should be able to login to our router but this time it is going to be using the parser view we created. Joe is another account I have created in Windows Active Directory and this account is part of the network operators security group. Here is what I have when Joe logs into the router.
As we can see Joe can only issue show commands and we can verify what privilege Joe is under by issuing the show privilege command notice Joe is using the SHOWMODE parser view we created on the IOS router, how cool cat is that 😉
BelieveВ it or not that’s it for this post. We have created policies on Microsoft NPS server as well as created parser views to limit access based on user accounts and tied it all together using radius. I hope this this information is helpful in helping you build a better RBAC with your network devices!
Static Comments:
Hey Darkpenguin, Privilege levels are hierarchical where as parser views are role based, so they are two different things. I can specifically call out different commands to use under a parser view regardless if its at a lower or higher privilege level. If you look at the example where the username Joe logs into the router, although this account has privilege level 15 this account is tied to a parser view called SHOWMODE. This account could only do show commands regardless what the privilege level was set. I really don’t need to worry about privilege levels if I’m using parser views, however you could give them a lower privilege level but I think the end result would be the same, they would only be able to use show commands on that lower privilege level. So I’m not sure what benefit you would get from putting this group at a lower privilege level. Ryan
Why add the «shell:priv-lvl=15» to the view only group?
