Настройка radius server на windows 2016 для cisco - Доктор Windows

В этой статье мы покажем, как настроить сервер централизованной аутентификации, авторизации и аккаунтинга (RADIUS) на операционной системе Windows Server 2016, а также как настроить Radius-аутентификацию на Cisco устройствах с помощью службы Политики сети и доступа (Network Policy Server).

RADIUS (англ. Remote Authentication in Dial-In User Service) — протокол для реализации аутентификации, авторизации и сбора сведений об использованных ресурсах, разработанный для передачи сведений между центральным севером и различными сетевым оборудованием и клиентами.

В первую очередь создайте в домене Active Directory группу безопасности AllowRemoteCiscoUsers, в которую нужно добавить пользователей, которым будет разрешена аутентификации на маршрутизаторах и коммутаторах Cisco.

Далее нужно установить на сервере, с помощью которого будет выполнятся аутентификация клиентов и назначаться права доступа, роль RADIUS сервера. Для этого на сервере Windows Server 2016 откройте оснастку Server Manager и вызовите мастер добавления ролей — Add Roles and features.

В открывшемся мастере на шаге выбора ролей отметьте роль Network Policy and Access Services. На шаге выбора служб роли в нашей ситуации достаточно будет выбрать только службу Network Policy Server.

Протокол Remote Authentication Dial In User Service (RADIUS) в Windows Server 2016 включен в состав роли Network Policy Server.

В консоли Server Manager выберите меню Tools и откройте консоль Network Policy Server (nps.msc).

Для полноценного использования NPS-сервера в домене необходимо зарегистрировать его в домене Active Directory. В оснастке на NPS, щелкните ПКМ по вашему NPS узлу и выберите Register server in Active Directory.

Подтвердите регистрацию сервера в Active Directory:

При этом мы должны предоставите серверу полномочия на чтение свойств учётных записей пользователей, касающихся удалённого доступа. Сервер при этом будет добавлен во встроенную доменную группу RAS and IAS Servers.

Теперь можно добавить клиента Radius. Для этого в дереве консоли NPS разверните раздел RADIUS Clients and Servers и на элементе RADIUS Clients выберите пункт New.

На вкладке Settings заполните поля Friendly name, Client address (можно указать IP адрес или DNS имя подключающегося сетевого устройства) и пароль — Shared Secret + Confirm shared (этот пароль вы будете использовать в настройках коммутатора или маршрутизатора Cisco для установления доверительных отношений с Radius сервером).

Во вкладке Advanced выберите в поле Vendor name — Cisco.

Теперь нужно создать политики доступа на сервере RADIUS. С помощью политик доступа мы свяжем клиента Radius и доменную группу пользователей.

Раскройте ветку Policies —> Network Policies, и выберите пункт меню New:

Укажите Имя политики (Policy name). Тип сервера доступа к сети (Type of network access server) оставьте без изменения (Unspecified):

На следующем шаге Specify conditions нам нужно добавить условия, при которых будет применяться данная политика RADIUS. Добавим два условия: вы хотите, что для успешной авторизации пользователь входил в определенную доменную группу безопасности, и устройство, к которому осуществляется доступ, имело определённое имя. С помощью кнопки Add добавим сначала условие, выбрав тип Windows Group (добавьте группу RemoteCiscoUsers) и укажите Client Friendly Name (Cisco_*).

На следующем выберите значение Доступ разрешен (Access Granted).

Т.к. наш коммутатор Cisco поддерживает только метод аутентификации Unencrypted authentication (PAP, SPAP), снимите все остальные флажки.

Следующий шаг настройки ограничений (Constraints) мы пропустим.

В разделе Configure Settings перейдите секцию RADIUS Attributes -> Standard. Удалите имеющиеся там атрибуты и нажмите кнопку Add.

Выберите Access type -> All, затем Service-Type->Add. Укажите Others=Login.

Теперь в секции RADIUS Attributes -> Vendor Specific добавьте новый атрибут. В пункте Vendor, найдите Cisco и нажмите Add. Здесь нужно добавить сведения об атрибуте. Нажмите Add и укажите следующее значение атрибута:

shell: priv-lvl = 15

На последнем экране будут указаны все созданные вами настройки политики NPS. Нажмите Finish:

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

После создания политики, можно переходить к настройке маршрутизаторов и коммутаторов Cisco для аутентификации на сервере Radius NPS.

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

Ниже пример конфигурации для авторизации на Radius (NPS) сервере для коммутатора Cisco Catalyst:

aaa new-model aaa authentication login default group radius local aaa authorization exec default group radius if-authenticated radius-server host 192.168.1.16 key R@diu$pa$$ service password-encryption

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

Источник

RADIUS (Remote Authentication in Dial-In User Service) is a network protocol for the implementation of authentication, authorization, and collecting information about the resources used. It is designed to transfer information between the central platform and network clients/devices. Your remote access (RADIUS) server can communicate with a central server/service (for example, Active Directory domain controller) to authenticate remote dial-in clients and authorize them to access some network services or resources. Thanks to this, you can use a single centralized authentication system in your domain.

In this article, we’ll show how to configure the centralized RADIUS server based on Windows Server 2022, 2019, or 2016 OSs, and how to configure RADIUS authentication on Cisco devices using the Network Policy Server (NPS) service. In this example, the RADIUS will use the AD to authenticate remote users and authorize them to access Cisco and Mikrotik switches/routers (act as RADIUS clients) command-line interface.

Installing Radius Server (NPS) Role on Windows Server 2022/2019/2016

At first, create a new security group in the Active Directory domain (for example, RemoteCiscoUsers) in which you will need to add all users that will be allowed to authenticate on Cisco routers and switches (How to add AD user to group with PowerShell?).

Starting with Windows Server 2008 R2, the RADIUS server functionality was implemented with the Network Policy Services (NPS) role. With the NPS role, you can authenticate remote clients against Active Directory using the Radius protocol.

So, you need to install the RADIUS server role on your Windows Server 2022/2019/2016. Open the Server Manager console and run the Add Roles and Features wizard. The Remote Authentication Dial-In User Service (RADIUS) protocol in Windows Server is a part of the Network Policy Server role. In the wizard that appears, select the Network Policy and Access Services role in the role selection step.

Note. Also, you can install NPS role and management tools from an elevated PowerShell console:
Install-WindowsFeature NPAS –IncludeManagementTools

Check if the NPAS role is installed on your Windows Server host:

Get-WindowsFeature -Name NPAS

After the role installation is completed, open the Network Policy Server (nps.msc) in the Tools menu.

To use the NPS server in the domain, you must register it in the Active Directory. In the NPS snap-in, right-click on a root and select Register server in Active Directory.

Confirm the registration of the server in Active Directory.

Also, you can register your NPS server in Active Directory with a command:

netsh ras add registeredserver

In this case, the server will be given the authority to read the properties of Active Directory user accounts to authenticate users. The server will be added to the built-in domain group RAS and IAS Servers.

Now you can add the Radius client. Radius client is the device from which your server will receive authentication requests. In this example, it could be a Cisco router, switch, Wi-Fi access point, etc.

To add the new Radius client, expand the RADIUS Clients and Servers section in the NPS console tree and select New on the RADIUS Clients item.

On the Settings tab, fill the fields Friendly name, client Address (you can specify IP address or DNS name), and Shared Secret + Confirm shared password (you will use this password in the configuration of the Cisco switch/router).

Note. The shared secret password is rarely used in huge corporate networks due to the problems with the distribution of shared keys. Instead of shared passwords, it is recommended to use certificates. If you have a corporate Certification Authority deployed to implement PKI infrastructure, you can request and import a *.p12 certificate for the Radius/NPS server. Just add the certificate to the personal certification store of the Local Machine.

In the Advanced tab, select Vendor name – Cisco.

You can use the PowerShell command instead of the NPS GUI to add a new RADIUS client. In this case, you can use the New-NpsRadiusClient PowerShell cmdlet:

New-NpsRadiusClient –Address "192.168.31.1" –Name "cisco2960" –SharedSecret "Zb+kp^JUy]vePb-h.Q*d=weya2AY?hn+npRRp[/J7d"

Configuring NPS Policies on the RADIUS Server

NPS policies allow you to authenticate remote users and grant them access permissions configured in the NPS role. Using NPS access policies, you can make a link to the RADIUS client records and the domain security group that determines the level of access to CISCO devices.

There are two types of policies on a RADIUS server:

Connection request policies — these policies define a set of conditions that determines which RADIUS servers should authenticate and authorize connection requests received from RADIUS clients;
Network policies — a set of conditions and settings that allow you to specify who is authorized to connect to your network and a list of assigned access permissions. These policies are processed sequentially from the top to down;

In our case, we will use only the NPS Network policies. Expand the Policies > Network Policies branch and select New:

Specify the Policy name, the type of network access server should remain unchanged (Unspecified).

In the next step Specify conditions, you need to add the conditions under which this RADIUS policy will be applied. Let’s add two conditions — the authorized user must be a member of a specific domain security group, and the device you want to access has a certain name. Use the Add option to create a new condition by selecting the Windows Group type (add the RemoteCiscoUsers group) and specifying the Client Friendly Name (Cisco_*).

Note. The Client Friendly Name field may differ from the DNS name of your device. We will need it in the further steps to identify a specific network device when creating a Remote Access Policy. Using this name, you can specify, for example, a mask by which several different RADIUS clients will be processed by a single access policy.

On the next screen, select Access Granted.

Our Cisco switch supports only the Unencrypted authentication method (PAP, SPAP), so that’s why we’ll uncheck all other options.

Skip the next configuration Constraints step.

In the Configure Settings section, go to the RADIUS Attributes > Standard section. Delete the existing attributes there and click the Add button.

Select Access type > All, then Service-Type > Add. Specify Others = Login.

Now add a new attribute in the RADIUS Attributes > Vendor Specific section. Under Vendor, select Cisco, and click Add. Here you need to add information about the attribute. Click Add and specify the following value:

shell: priv-lvl = 15

This value means that the user authorized by this policy will be granted a maximum (15) administrative access permission on the Cisco device.

The last screen displays all selected NPS policy settings. Click Finish.

Hint. You can back up the current NPS server configuration to the XML file using the command:
Export-NpsConfiguration -Path c:psbackup_nps.xml

If you need to restore the NPS configuration from a previously created backup file, run:

Import-NpsConfiguration -Path c:psbackup_nps.xml

When creating and planning RADIUS policies, pay attention to what matters in their order. Policies are processed from the top to down, and when it turns out that all the conditions in the next policy are met, their further processing is terminated. You can change the priorities of policies in the NPS console using the Processing Order value.

To enable the user account to be used for Radius authentication, open the Active Directory Users and Computers snap-in (dsa.msc), find the user, open its properties, go to the Dial-In tab and select the Control access through NPS Network Policy option in the Network Access Permission section.

Also, you can check the current option value using PowerShell:

Get-ADUser richard.doe -Properties msNPAllowDialin -Server dc1.theitbros.com

If the above command did not return any result (empty), this means that the default value “Control access through NPS Network Policy” is used.

If you want to reset this user attribute to the default state, use the command:

Set-ADUser richard.doe -Clear msNPAllowDialin -Server dc1.theitbros.com

Or you can reset this attribute for all users in the specific Active Directory OU using the LDAP filter:

Get-ADUser -SearchBase "ou=Users,ou=Paris,dc=theitbros,dc=com" -LDAPFilter "(msNPAllowDialin=*)" | % {Set-ADUser $_ -Clear msNPAllowDialin}

Configuring RADIUS Setting on Cisco Devices

After creating the policy, you can proceed to configure your Cisco routers or switches for authentication on the newly installed Radius NPS server.

Because we use domain accounts for authorization, the user credentials must be transmitted over the network in an encrypted form. To do this, disable the telnet protocol on the switch and enable SSHv2 on Cisco using the following commands in configuration mode:

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

AAA works in such a way: if the response from the server is not received, the client assumes unsuccessful authentication. Be sure to create a local user in case the RADIUS server is unavailable for some reason.

You can create a local user with the following command:

username cisco_local password $UPerrP@ssw0rd

To make the use of SSH mandatory and disable remote access using Telnet, execute the following commands:

line vty 5 15
transport input ssh

Below is an example of the configuration for authorizing a Radius server for the Cisco Catalyst Switch:

aaa new-model

aaa authentication login default group radius local

aaa authorization exec default group radius if-authenticated

radius-server host 192.168.1.16 key Sfs34e#sf

#Specify your RADIUS server IP address and key for encryption (the shared secret that we specified on the RADIUS server)

service password-encryption

# Enable password encryption

If you have several Radius servers, add them to the group:

aaa group server radius radius_srv_group

server 192.168.1.16

server 192.168.101.16

This completes the minimum switch configuration and you can try to check Radius authentication on your Cisco device.

How to Configure RADIUS Authentication on Microtik (RouterOS) Devices?

In this part, we will show you how to configure RADIUS authentication for VPN user connections via a Mikrotik router (RouterOS based).

Open the Network Policy Server console (nps.msc) and create a new Radius client.

Select New RADIUS Client and configure the following settings:

Enable this RADIUS Client;
Friendly Name — enter the name of your Mikrotik router here;
Address — specific the IP address of the Mikrotik router;
Specify your Preshared secret key.

Create a new Network Policy with the following settings:

User Groups — specify the name of the domain user group that is allowed to authenticate on your Mikrotik router;
Authentication Type — MS-CHAPv2;
Tunnel Type — Point-to-Point Tunneling Protocol (PPTP);
Access Permissions — Access granted;
In the Configure Authentication Methods window, leave only MS-CHAPv2 and allow users to change expired passwords (User can change password after it has expired option);
Multilink and Bandwidth Allocation Protocol (BAP) – Do not allow Multilink connections;
In the Standard section, remove Service-Type – Framed and leave only Framed-Protocol PPP;
Encryptions — leave only the Strongest encryption (MPP 128-bit) method.

Once you have created a new policy, open the Network Policy Server settings.

Leave only the following UDP ports for the RADIUS server communications:

Authentication — 1812;
Accounting — 1813.

Check if these UDP ports are open in Microsoft Defender Firewall Rules. If not, open them manually.

Now you need to configure the connection settings for Windows Server RADIUS in the Mikrotik configuration (we assume that PPP VPN Server is already configured on RouterOS to connect users).

Check in the PPTP server settings that only mschap2 is allowed to use for authentication.

Now we need to configure the connection to Radius NPS server. Select New Radius Server and specify the following options:

Service: ppp;
Address: IP address of the RADIUS server;
Secret: preshared key that you specified in the network policy settings;
Src/ Address: Mikrotik IP address from which traffic will be sent to NPS;
Authentication Port: 1812;
Accounting Port: 1813.

Add appropriate access rules to Mikrotik Firewall.

Then go to Secrets > PPP Authentication and Accounting and enable the Use Radius option.

It remains to configure a PPTP VPN connection to your Mikrotik VPN on users’ computers. To authenticate to Mikrotik, users can use their Active Directory accounts (accounts must be added to the AD group that you have specified when creating the Miktotik Network Policy on NPS).

How to Check the NPS/RADIUS Logs on Windows?

To enable NPS Server Radius Authentication logging, you need to enable the Network Policy Server audit policy. You can enable this policy via the local Group Policy Editor or with the following commands:

auditpol /get /subcategory:"Network Policy Server"

auditpol /set /subcategory:"Network Policy Server" /success:enable /failure:enable

Now you can open the Event Viewer console (eventvwr.msc), go to the Windows Logs > Security, and filter the event by the Event ID 6272.

Network Policy Server granted access to a user.

If you need to find all NPS authorizations events for the specific user (Richard.Doe in this example), use the next PowerShell script:

$Query = @"
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">
*[EventData[Data[@Name='SubjectUserName'] and (Data=theitbrosrichard.doe')]] and
*[System[(EventID='6272')]]
</Select>
</Query>
</QueryList>
"@
$events = Get-WinEvent -FilterXML $Query
$ipaddr = @{ label="IP"; Expression={$_.properties[9].value} }
$events | select $ipaddr | group "IP" | format-table Count, Name -autosize

About
Latest Posts

I enjoy technology and developing websites. Since 2012 I’m running a few of my own websites, and share useful content on gadgets, PC administration and website promotion.

Источник

Наконец «Долгая дорога в дюнах» закончилась, и мы пришли к корпоративному управляемому Wi-fi решению. В начале думали про решение Cisco или Aruba, но к сожалению текущий бюджет никак не располагает к решениям подобного плана. В итоге, в ходе долгих поисков истины и раздумий, решили остановиться на решении Ubnt (отдельно благодарю Александра за нужные советы). Конечно, это не одного поля ягоды с решением Cisco или Aruba, но в текущей ситуации, что есть, то есть.

Как говорил мой командир: «На пожаре и Х… водопровод» (да простят меня за мой русский).

Итак, решение выбрано, задача настроить корпоративный внутренний и гостевой сегменты Wi-fi с авторизацией на Radius сервере.

VPN сервер уже готов, осталось настроить RADIUS, сегодня как раз об этом. На первый взгляд, развернуть и настроить RADIUS сервер, не такая уж сложная задача, но немного загнались с сертификатом, пришлось «поплясать с бубном», ну об этом далее по порядку.

Для начала необходимо запросить сертификат с Центра сертификации, центр сертификации у нас уже есть, поэтому его установку в этом посте я пропущу.

MMC-Файл-Добавить или удалить оснастку-Добавляем Сертификаты-Учетной записи компьютера-Локальным компьютером.

Находим наш центр сертификации

snap1

Запрашиваем сертификат (*.p12), сохраняем его на диск, далее устанавливаем его в Личные сертификаты на будущий радиус сервер

snap2

Далее добавляем роль самого RADIUS сервера

snap3

Далее запускаем Сервер политики сети

snap4

snap5

Добавляем в раздел RADIUS-клиенты свои Wi-fi точки доступа или сервер управления точками доступа если он поддерживает эту возможность (в этом случае он будет выполнять роль RADIUS клиента)

snap6

Общий секрет, указываем тот, который в последствии укажем на Wi-fi точке (IP адрес точки в той подсети, где она находится).

Переходим к политике запросов на подключение

snap7

snap8

snap9

Вот тут, если нажать на:защищенные EAP(PEAP)-Изменить, мы должны видеть свой сертификат, если он был правильно запрошен и установлен.

snap10

Далее настраиваем Сетевые политики

snap11

snap12

snap13

На первый взгляд настройка RADIUS сервера на этом закончена, но это еще не все.

На эту тему есть четкие рекомендации, про которые я совсем забыл (спасибо Александру, что он напомнил):

https://technet.microsoft.com/en-us/library/cc754198.aspx?f=255&MSPPError=-2147217396

если сервер не включен в группу RAS and IAS, то его надо туда добавить:

https://msdn.microsoft.com/en-us/library/cc754878(v=ws.11).aspx

На всякий случай проверяем, что все так, как должно быть, открываем на сервере локальную политику (gpedit.msc)

И проверяем следующий пункт

snap14

Далее на точке или точках Wi-fi указываем авторизацию WPA Enterprise.

snap15

Здесь же хотел поблагодарить Романа, за подробные разъяснения по неясным моментам по серверу управлению Wi-fi и настройкам непосредственно Wi-fi.

И получаем далее авторизуем с доменными учетными данными, пользователей подключаемых к корпоративному Wi-fi.

Почитать по теме можно здесь:

How to Configure Windows 2012 NPS for Radius Authentication with Ubiquiti Unifi

или здесь:

https://habrahabr.ru/post/142070/

Всем хорошей работы!!!

06.12.2016 —

Posted by |
ms windows server 2016

Sorry, the comment form is closed at this time.

Источник

В предыдущей заметке была рассмотрена процедура установки и настройки 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

Источник

Quick description:

This is a how to guide on how to set up Radius Authentication for Cisco equipment.

What we want to achieve:

SSH into Cisco switch/router/firewall using Active Directory account in a specified security group.

Use Case:

Home Lab; Small Business

What we already need setup:

Windows Server 2016
Active Directory
Cisco Switch/Router/Firewall

Note: I will be using a Cisco 3750 Switch for this how to guide. Cisco commands will be different when using a firewall.

Configuration:

Windows Server 2016

Cisco 3750 Switch

Radius Server IP: 10.0.20.6

Text Values you can change gold

Default port settings aqua

username backup secret A-password

aaa group server radius RAD-SERVERS
server-private 10.0.20.6 auth-port 1812 acct-port 1813 key Radius-Key

aaa authentication login default group RAD-SERVERS local
aaa authorization console
aaa authorization exec default group RAD-SERVERS local

Command breakdown:

username backup secret A-password

This sets up an account called backup with an encrypted password of A-password. This is in case the Radius server is offline and you need to get into the switch!

aaa group server radius RAD-SERVERS

Configures an aaa group on switch called RAD-Servers (you can have multiple servers in this group for failover)

server-private 10.0.20.6 auth-port 1812 acct-port 1813 key Radius-Key

Adds a server (IP: 10.0.20.6) to RAD-Servers AAA group. It is important to have a matching radius key on the radius server as it is used to decrypt the request.

The default ports for radius authentication (1812) & accounting (1813) can be changed, but you need to change this on the Radius server as well.

Note: you need to enter the above AAA group first before entering this command.

aaa authentication login default group RAD-SERVERS local

This tells the switch when there is a login attempt to first try to Authenticate to RAD-SERVERS AAA group. If this fails then it will go to local

Local authentication means the switch will look at its own local user database. This is the backup account we created earlier.

aaa authorization console

This adds an authorization check to the console port when attempting to login. By default IOS will not do this bypassing authorization.

aaa authorization exec default group RAD-SERVERS local

This tells the switch when a logged in user requests to go into privileged mode (enable) to prompt for a password & check it if they are authorized to do so by first asking RAD-SERVERS AAA group. If this fails then it will go to local.

Note: in this How To we configured the Radius server to return privilege 15 level for Engineers this will automatically enter you into privileged mode. Lower privileges will be prompted for their password again.

How to troubleshoot this:

Cisco 3750

Enable debuging

debug radius accounting

debug radius authentication

debug aaa authorization

debug aaa authentication

terminal monitor

Once you have entered these commands open another SSH session and attempt to login you will see debug statements like below

Example of successful login:

Jul 8 02:50:30.259: AAA/BIND(00000022): Bind i/f
Jul 8 02:50:30.259: AAA/AUTHEN/LOGIN (00000022): Pick method list ‘default’
Jul 8 02:50:30.259: RADIUS/ENCODE(00000022): ask “Password: ”
Jul 8 02:50:30.259: RADIUS/ENCODE(00000022):Orig. component type = EXEC
Jul 8 02:50:30.259: RADIUS: AAA Unsupported Attr: interface [170] 4
Jul 8 02:50:30.259: RADIUS: 74 74 [ tt]
Jul 8 02:50:30.259: RADIUS/ENCODE(00000022): dropping service type, “radius-server attribute 6 on-for-login-auth” is off
Jul 8 02:50:30.259: RADIUS(00000022): Config NAS IP: 0.0.0.0
Jul 8 02:50:30.259: RADIUS/ENCODE(00000022): acct_session_id: 34
Jul 8 02:50:30.259: RADIUS(00000022): sending
Jul 8 02:50:30.259: RADIUS/ENCODE: Best Local IP-Address 10.0.20.1 for Radius-Server 10.0.20.6
Jul 8 02:50:30.259: RADIUS(00000022): Send Access-Request to 10.0.20.6:1812 id 1645/37, len 91
Jul 8 02:50:30.259: RADIUS: authenticator 41 D0 92 B5 1B 06 69 C9 – E9 E6 C5 51 C9 AF 1D 02
Jul 8 02:50:30.259: RADIUS: User-Name [1] 6 “noob“
Jul 8 02:50:30.259: RADIUS: Reply-Message [18] 12
Jul 8 02:50:30.259: RADIUS: 50 61 73 73 77 6F 72 64 3A 20 [ Password: ]
Jul 8 02:50:30.259: RADIUS: User-Password [2] 18 *
Jul 8 02:50:30.259: RADIUS: NAS-Port [5] 6 2
Jul 8 02:50:30.259: RADIUS: NAS-Port-Id [87] 6 “tty2”
Jul 8 02:50:30.259: RADIUS: NAS-Port-Type [61] 6 Virtual [5]
Jul 8 02:50:30.259: RADIUS: Calling-Station-Id [31] 11 “10.0.10.5”
Jul 8 02:50:30.259: RADIUS: NAS-IP-Address [4] 6 10.0.20.1
Jul 8 02:50:30.268: RADIUS: Received from id 1645/37 10.0.20.6:1812, Access-Accept, len 96
Jul 8 02:50:30.268: RADIUS: authenticator A3 19 0E 6A E5 13 53 6C – B8 C9 03 B6 68 60 6F 79
Jul 8 02:50:30.268: RADIUS: Service-Type [6] 6 Login [1]
Jul 8 02:50:30.268: RADIUS: Class [25] 46
Jul 8 02:50:30.268: RADIUS: 8F AF 08 DB 00 00 01 37 00 01 02 00 0A 00 14 06 00 00 00 00 08 88 97 83 43 80 AC 47 01 D2 F6 F8 74 9C B5 8A 00 00 00 00 00 00 00 0B [ 7CGt]
Jul 8 02:50:30.268: RADIUS: Vendor, Cisco [26] 24
Jul 8 02:50:30.268: RADIUS: Cisco AVpair [1] 18 “shell:priv–lvl=1″
Jul 8 02:50:30.268: RADIUS(00000022): Received from id 1645/37
Jul 8 02:50:30.268: %SEC_LOGIN-5-LOGIN_SUCCESS: Login Success [user: ] [Source: 10.0.10.5] [localport: 22] at 12:50:30 ADEST Sat Jul 8 2017
Jul 8 02:50:30.276: AAA/AUTHOR/EXEC(00000022): processing AV priv–lvl=1
Jul 8 02:50:30.276: AAA/AUTHOR/EXEC(00000022): Authorization successful

Example of failed login attempt – (account noob was removed from security group)

Jul 8 02:55:47.802: AAA/BIND(00000023): Bind i/f
Jul 8 02:55:47.802: AAA/AUTHEN/LOGIN (00000023): Pick method list ‘default’
Jul 8 02:55:47.802: RADIUS/ENCODE(00000023): ask “Password: ”
Jul 8 02:55:47.810: RADIUS/ENCODE(00000023):Orig. component type = EXEC
Jul 8 02:55:47.810: RADIUS: AAA Unsupported Attr: interface [170] 4
Jul 8 02:55:47.810: RADIUS: 74 74 [ tt]
Jul 8 02:55:47.810: RADIUS/ENCODE(00000023): dropping service type, “radius-server attribute 6 on-for-login-auth” is off
Jul 8 02:55:47.810: RADIUS(00000023): Config NAS IP: 0.0.0.0
Jul 8 02:55:47.810: RADIUS/ENCODE(00000023): acct_session_id: 35
Jul 8 02:55:47.810: RADIUS(00000023): sending
Jul 8 02:55:47.810: RADIUS/ENCODE: Best Local IP-Address 10.0.20.1 for Radius-Server 10.0.20.6
Jul 8 02:55:47.810: RADIUS(00000023): Send Access-Request to 10.0.20.6:1812 id 1645/38, len 91
Jul 8 02:55:47.810: RADIUS: authenticator 0E 71 7E FE 2D 73 F9 93 – C9 FD A9 6C 10 01 9B 01
Jul 8 02:55:47.810: RADIUS: User-Name [1] 6 “noob“
Jul 8 02:55:47.810: RADIUS: Reply-Message [18] 12
Jul 8 02:55:47.810: RADIUS: 50 61 73 73 77 6F 72 64 3A 20 [ Password: ]
Jul 8 02:55:47.810: RADIUS: User-Password [2] 18 *
Jul 8 02:55:47.810: RADIUS: NAS-Port [5] 6 2
Jul 8 02:55:47.810: RADIUS: NAS-Port-Id [87] 6 “tty2”
Jul 8 02:55:47.810: RADIUS: NAS-Port-Type [61] 6 Virtual [5]
Jul 8 02:55:47.810: RADIUS: Calling-Station-Id [31] 11 “10.0.10.5”
Jul 8 02:55:47.810: RADIUS: NAS-IP-Address [4] 6 10.0.20.1
Jul 8 02:55:47.819: RADIUS: Received from id 1645/38 10.0.20.6:1812, Access-Reject, len 20
Jul 8 02:55:47.819: RADIUS: authenticator 7E 70 BB EB 0C EE 22 DD – FB D0 CF 6D 5A 79 2B 9D
Jul 8 02:55:47.819: RADIUS(00000023): Received from id 1645/38
Jul 8 02:55:49.824: %SEC_LOGIN-4-LOGIN_FAILED: Login failed [user: ] [Source: 10.0.10.5] [localport: 22] [Reason: Login Authentication Failed] at 12:55:49 ADEST Sat Jul 8 2017

Источник

При обслуживании больших сетей системные администраторы часто сталкиваются с проблемами аутентификации на сетевом оборудовании. В частности, довольно сложно организовать нормальную работу нескольких сетевых администраторов под индивидуальными учетными записями на большом количестве оборудования (приходится вести и поддерживать в актуальном состоянии базу локальных учетных записей на каждом устройстве). Логичным решение было бы использовать для авторизации уже существующей базы учетных записей — 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
Настройка сетевого оборудования для работы с сервером RADUIS

Установка и настройка сервера с ролью 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 и пароль на свои).

aaa authentication console enable radius local

aaa authentication telnet login radius local

aaa authentication telnet enable radius local

aaa authentication ssh login radius local

aaa authentication ssh enable radius local

aaa authentication login privilege-mode

radius-server key YOUR-SECRET-KEY

radius-server host 10.10.10.44 YOUR-SECRET-KEY auth-port 1645 acct-port 1646

radius-server host 10.10.10.44 auth-port 1645

radius-server host 10.10.10.44 acct-port 1646

Совет. Если в целях безопасности вы запретили подключаться к сетевому оборудованию через telnet, эти строки нужно удалить из конфига:

aaa authentication telnet login radius local

aaa authentication telnet enable radius local

Не закрывая консольное окно коммутатора (это важно!, иначе, если что-то пойдет не так, вы более не сможете подключиться к своему коммутатору), откройте вторую telnet-сессию. Должно появиться новое окно авторизации, в котором будет предложено указать имя и пароль учетной записи. Попробуйте указать данные своей учетной записи в AD (она должна входить в группу Network Admins ). Если подключение установлено – вы все сделали правильно!

Для коммутатора Cisco конфигурация, предполагающая использование доменных учетных записей для аутентификации и авторизации, может выглядеть так:

Примечание. В зависимости от модели сетевого оборудования Cisco и версии IOS конфигурация может несколько отличаться.

aaa new-model
radius-server host 10.10.10.44 auth-port 1645 acct-port 1646 key YOUR-SECRET-KEY
aaa authentication login default group radius local
aaa authorization exec default group radius local
ip radius source-interface Vlan421
line con 0
line vty 0 4
line vty 5 15

Примечание. В такой конфигурации для аутентификации сначала используется сервер RADIUS, а если он не доступен – локальная учетная запись.

Для Cisco ASA конфигурация будет выглядеть так:

aaa-server RADIUS protocol radius
aaa-server RADIUS host 10.10.10.44 key YOUR-SECRET-KEY
radius-common-pw YOUR-SECRET-KEY
aaa authentication telnet console RADIUS LOCAL
aaa authentication ssh console RADIUS LOCAL
aaa authentication http console RADIUS LOCAL
aaa authentication http console RADIUS LOCAL

Совет. Если что то-не работает, проверьте:

Совпадают ли секретные ключи на сервере NPS и коммутаторе (для теста можно использоваться простой пароль).
Указан ли правильный адрес NPS сервера в конфигурации. Пингуется ли он?
Не блокируют ли межсетевые экраны порты 1645 и 1646 между коммутатором и сервером?
Внимательно изучите логи NPS сервера

Источник

Рассмотрим на практике использование Windows Active Directory + NPS (2 сервера для обеспечения отказоустойчивости) + стандарт 802.1x для контроля доступа и аутентификации пользователей – доменных компьютеров – устройств. Ознакомиться с теорией по стандарту можно в Wikipedia, по ссылке: IEEE 802.1X
Так как “лаборатория” у меня ограничена по ресурсам, совместим роли NPS и контроллера домена, но вам я рекомендую такие критичные сервисы все же разделять.

Стандартных способов синхронизации конфигураций (политик) Windows NPS я не знаю, поэтому будем использовать скрипты PowerShell, запускаемые планировщиком заданий (автор мой бывший коллега). Для аутентификации компьютеров домена и для устройств, не умеющих в 802.1x (телефоны, принтеры и пр), будет настроена групповая политика и созданы группы безопасности.

В конце статьи расскажу о некоторых тонкостях работы с 802.1x – как можно использовать неуправляемые коммутаторы, dynamic ACL и пр. Поделюсь информацией об отловленных “глюках”…

Начнем с установки и настройки failover NPS on Windows Server 2012R2 (на 2016-м все аналогично): через Server Manager -> Add Roles and Features Wizard выбираем лишь Network Policy Server.

или с помощью PowerShell:

Install-WindowsFeature NPAS -IncludeManagementTools

Небольшое уточнение – так как для Protected EAP (PEAP) вам обязательно потребуется сертификат, подтверждающий подлинность сервера (с соответствующими правами на использование), который будет в доверенных на клиентских компьютерах, то вам скорее всего потребуется установить еще и роль Certification Authority. Но будем считать, что CA у вас уже установлен…

Сделаем тоже самое и на втором сервере. Создадим папку для скрипта C:Scripts на обоих серверах и сетевую папку на втором сервере SRV2NPS-config$

На первом сервере создадим PowerShell скрипт C:ScriptsExport-NPS-config.ps1 со следующим содержанием:

Export-NpsConfiguration -Path "SRV2NPS-config$NPS.xml"

После этого настроим задание в Task Sheduler: “Export-NpsConfiguration”

powershell -executionpolicy unrestricted -f "C:ScriptsExport-NPS-config.ps1"

Выполнять для всех пользователей — Выполнить с наивысшими правами
Ежедневно — Повторять задачу каждые 10 мин. в течении 8 ч.

На резервном NPS настроим импорт конфигурации (политик):
создадим скрипт PowerShell:

echo Import-NpsConfiguration -Path "c:NPS-configNPS.xml" >> C:ScriptsImport-NPS-config.ps1

и задачу на его выполнение каждые 10 минут:

powershell -executionpolicy unrestricted -f "C:ScriptsImport-NPS-config.ps1"

Теперь, для проверки, добавим в NPS на одном из серверов(!) пару коммутаторов в RADIUS-клиенты (IP и Shared Secret), две политики запросов на подключение: WIRED-Connect (Условие: “Тип порта NAS – Ethernet”) и WiFi-Enterprise (Условие: “Тип порта NAS – IEEE 802.11”), а также сетевую политику Access Cisco Network Devices (Network Admins):

Условия:
Группы Windows - domainsg-network-admins
Ограничения:
Методы проверки подлинности - Проверка открытым текстом (PAP, SPAP)
Параметры:
Атрибуты RADIUS: Стандарт - Service-Type - Login
Зависящие от поставщика - Cisco-AV-Pair - Cisco - shell:priv-lvl=15

Со стороны коммутаторов следующие настройки:

aaa new-model aaa local authentication attempts max-fail 5 ! ! aaa group server radius NPS server-private 192.168.38.151 auth-port 1812 acct-port 1813 key %shared_secret% server-private 192.168.10.151 auth-port 1812 acct-port 1813 key %shared_secret% ! aaa authentication login default group NPS local aaa authentication dot1x default group NPS aaa authorization console aaa authorization exec default group NPS local if-authenticated aaa authorization network default group NPS ! aaa session-id common ! identity profile default ! dot1x system-auth-control ! ! line vty 0 4 exec-timeout 5 0 transport input ssh escape-character 99 line vty 5 15 exec-timeout 5 0 logging synchronous transport input ssh escape-character 99

После настройки, спустя 10 минут, все клиентыполитикипараметры должны появиться и на резервном NPS и мы сможем авторизоваться на коммутаторах с помощью учетной записи ActiveDirectory, члена группы domainsg-network-admins (которую мы создали заранее).

Перейдем к настройке Active Directory – создадим групповую и парольную политики, создадим необходимые группы.

Групповая политика Computers-8021x-Settings:

Computer Configuration (Enabled)
Policies
Windows Settings
Security Settings
System Services
Wired AutoConfig (Startup Mode: Automatic)
Wired Network (802.3) Policies

NPS-802-1x

Name NPS-802-1x
Description 802.1x
Global Settings
SETTING VALUE
Use Windows wired LAN network services for clients Enabled
Shared user credentials for network authentication Enabled
Network Profile
Security Settings
Enable use of IEEE 802.1X authentication for network access Enabled
Enforce use of IEEE 802.1X authentication for network access Disabled
IEEE 802.1X Settings
Computer Authentication Computer only
Maximum Authentication Failures 10
Maximum EAPOL-Start Messages Sent
Held Period (seconds)
Start Period (seconds)
Authentication Period (seconds)
Network Authentication Method Properties
Authentication method Protected EAP (PEAP)
Validate server certificate Enabled
Connect to these servers
Do not prompt user to authorize new servers or trusted certification authorities Disabled
Enable fast reconnect Enabled
Disconnect if server does not present cryptobinding TLV Disabled
Enforce network access protection Disabled
Authentication Method Configuration
Authentication method Secured password (EAP-MSCHAP v2)
Automatically use my Windows logon name and password(and domain if any) Enabled

Создадим группу безопасности sg-computers-8021x-vl100, куда мы будем добавлять компьютеры, которые мы хотим распределять в влан 100 и настроим фильтрацию для созданной ранее групповой политики на эту группу:

Убедиться в том, что политика успешно отработала можно открыв “Центр управления сетями и общим доступом (Параметры сети и Интернет) – Изменение параметров адаптера (Настройка параметров адаптера) – Свойства адаптера”, где мы сможем увидеть вкладку “Проверка подлинности”:

Когда убедились, что политика успешно применяется – можно переходить к настройке сетевой политики на NPS и портов коммутатора уровня доступа.

Создадим сетевую политику neag-computers-8021x-vl100:

Conditions:
  Windows Groups - sg-computers-8021x-vl100
  NAS Port Type - Ethernet
Constraints:
  Authentication Methods - Microsoft: Protected EAP (PEAP) - Unencrypted authentication (PAP, SPAP)
  NAS Port Type - Ethernet
Settings:
  Standard:
   Framed-MTU 1344
   TunnelMediumType 802 (includes all 802 media plus Ethernet canonical format)
   TunnelPrivateGroupId  100
   TunnelType  Virtual LANs (VLAN)

Типовые настройки для порта коммутатора (обращаю внимание, что используется тип аутентификации “мультидомен” – Data & Voice, а также есть возможность аутентификации по mac адресу. на время “переходного периода” есть смысл использовать в параметрах:


authentication event fail action authorize vlan 100
authentication event no-response action authorize vlan 100

влан id не “карантинного”, а того же, куда пользовательский компьютер должен попасть, успешно авторизовавшись – пока не убедимся, что все работает как следует. Эти же параметры могут быть использованы и в других сценариях, например, когда в этот порт воткнут неуправляемый коммутатор и вы хотите, чтобы все устройства, подключенные в него и не прошедшие аутентификацию, попадали в определенный влан (“карантинный”).

настройки порта коммутатора в режиме 802.1x host-mode multi-domain

default int range Gi1/0/39-41
int range Gi1/0/39-41
shu
des PC-IPhone_802.1x
switchport mode access
switchport nonegotiate
switchport voice vlan 55
switchport port-security maximum 2
authentication event fail action authorize vlan 100
authentication event no-response action authorize vlan 100
authentication host-mode multi-domain
authentication port-control auto
authentication violation restrict
mab
dot1x pae authenticator
dot1x timeout quiet-period 15
dot1x timeout tx-period 3
storm-control broadcast level pps 100
storm-control multicast level pps 110
no vtp
lldp receive
lldp transmit
spanning-tree portfast
no shu
exit

Убедиться, что компьютертелефон успешно прошли аутентификацию можно командой:

sh authentication sessions int Gi1/0/39 det

Теперь создадим группу (например, sg-fgpp-mab ) в Active Directory для телефонов и добавим в нее один аппарат для тестов (в моем случае это Grandstream GXP2160 с мас-адресом 000b.82ba.a7b1 и соотв. учетной записью domain00b82baa7b1). Для созданной группы понизим требования парольной политики (используя Fine-Grained Password Policies через Active Directory Administrative Center -> domain -> System -> Password Settings Container) с такими параметрами Password-Settings-for-MAB:

тем самым разрешим использовать мас-адрес устройств в качестве паролей. После этого мы сможем создать сетевую политику для аутентификации 802.1x method mab, назовем ее neag-devices-8021x-voice. Параметры следующие:

NAS Port Type – Ethernet
Windows Groups – sg-fgpp-mab
EAP Types: Unencrypted authentication (PAP, SPAP)
RADIUS Attributes – Vendor Specific: Cisco – Cisco-AV-Pair – Attribute value: device-traffic-class=voice

после успешной аутентификации (не забываем настроить порт коммутатора), посмотрим информацию с порта:

sh authentication se int Gi1/0/34

---------------------------------------- Interface: GigabitEthernet1/0/34 MAC Address: 000b.82ba.a7b1 IP Address: 172.29.31.89 User-Name: 000b82baa7b1 Status: Authz Success Domain: VOICE Oper host mode: multi-domain Oper control dir: both Authorized By: Authentication Server Session timeout: N/A Idle timeout: N/A Common Session ID: 0000000000000EB2000B8C5E Acct Session ID: 0x00000134 Handle: 0xCE000EB3

Runnable methods list: Method State dot1x Failed over mab Authc Success

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

настройки порта коммутатора в режиме 802.1x host-mode multi-auth

interface GigabitEthernet1/0/1
description *SW – 802.1x – 8 mac*
shu
switchport mode access
switchport nonegotiate
switchport voice vlan 55
switchport port-security maximum 8  ! увеличиваем кол-во допустимых мас-адресов
authentication event fail action authorize vlan 100
authentication event no-response action authorize vlan 100
authentication host-mode multi-auth  ! – режим аутентификации
authentication port-control auto
authentication violation restrict
mab
dot1x pae authenticator
dot1x timeout quiet-period 15
dot1x timeout tx-period 3
storm-control broadcast level pps 100
storm-control multicast level pps 110
no vtp
spanning-tree portfast
no shu

P.S. замечен очень странный глюк – если устройство было подключено через такой свитч, а потом его воткнули в управляемый коммутатор, то оно НЕ заработает, пока мы не перезагрузим(!) свитч Пока других способов решения этой проблемы не нашел.

Еще один момент, связанный с DHCP (если используется ip dhcp snooping) – без таких вот опций:

ip dhcp snooping vlan 1-100
no ip dhcp snooping information option

почему-то корректно ip адрес не получить…хотя может это особенность нашего DHCP сервера

А еще Mac OS & Linux (в которых поддержка 802.1x нативная) пытаются пройти аутентификацию пользователем, даже если настроена аутентификация по мас-адресу.

В следующей части статьи рассмотрим применение 802.1x для Wireless (в зависимости от группы, в которую входит учетная запись пользователя, его будем “закидывать” в соответствующую сеть (влан), хотя подключаться они будут к одному SSID).

Автор: Фёдор

Источник

Источник