Configuring 802.1X on Cisco Switches Using Failover NPS (Windows RADIUS with AD)

Let us consider in practice the use of Windows Active Directory + NPS (2 servers for fault tolerance) + 802.1x standard for access control and authentication of users - domain computers - devices. You can familiarize yourself with the theory of the standard in Wikipedia, under the link: IEEE 802.1X

Since my “laboratory” is limited in resources, the roles of NPS and a domain controller are compatible, but I recommend that you share such critical services.

I don’t know the standard ways to synchronize configurations (policies) of Windows NPS, therefore we will use PowerShell scripts launched by the task scheduler (the author is my former colleague). For authentication of domain computers and for devices that do not know how to use 802.1x(telephones, printers, etc.), Group Policy will be configured and security groups created.

At the end of the article I’ll talk about some of the subtleties of working with 802.1x - how to use unmanaged switches, dynamic ACLs, etc. I’ll share information about the caught “glitches” ...

Let's start by installing and configuring failover NPS on Windows Server 2012R2 (everything is the same for 2016) : through Server Manager -> Add Roles and Features Wizard, select only Network Policy Server.



or using PowerShell:

Install-WindowsFeature NPAS -IncludeManagementTools

A small clarification - since for Protected EAP (PEAP) you will definitely need a certificate confirming the authenticity of the server (with the appropriate usage rights), which will be trusted on client computers, then you will most likely need to install the Certification Authority role . But let's assume that you already have CA installed ...

We will do the same on the second server. Create a folder for the C: \ Scripts script on both servers and a network folder on the second server \\ SRV2 \ NPS-config $

On the first server, create a PowerShell script C: \ Scripts \ Export-NPS-config.ps1 with the following contents:

Export-NpsConfiguration -Path "\\SRV2\NPS-config$\NPS.xml"

After that, configure the task in the Task Sheduler: “ Export-NpsConfiguration ”

powershell -executionpolicy unrestricted -f "C:\Scripts\Export-NPS-config.ps1"

Perform for all users - Run with highest privileges
Daily - Repeat the task every 10 minutes. within 8 hours.

On the standby NPS, configure the configuration import (policies):
create a PowerShell script:

echo Import-NpsConfiguration -Path "c:\NPS-config\NPS.xml" >> C:\Scripts\Import-NPS-config.ps1

and the task of its implementation every 10 minutes:

powershell -executionpolicy unrestricted -f "C:\Scripts\Import-NPS-config.ps1"

Perform for all users - Run with highest privileges
Daily - Repeat the task every 10 minutes. within 8 hours.

Now, for verification, add a couple of switches to RADIUS clients (IP and Shared Secret) in NPS on one of the servers (!), two connection request policies: WIRED-Connect (Condition: “NAS port type - Ethernet ”) and WiFi-Enterprise (Precondition:“ NAS port type is IEEE 802.11 ”), as well as the Access Cisco Network Devices (Network Admins) network policy :

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

After configuration, after 10 minutes, all clients \ policies \ settings should appear on the standby NPS and we will be able to log in to the switches using the ActiveDirectory account, a member of the domain \ sg-network-admins group (which we created in advance).

Let's move on to setting up Active Directory - create a group and password policy, create the necessary groups.

Group Policy Computers-8021x-Settings :

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

Let's create a security group sg-computers-8021x-vl100 , where we will add the computers that we want to distribute to vlan 100 and configure filtering for the previously created group policy for this group: You can



verify that the policy worked successfully by opening the “Network Control Center and Sharing (network settings and Internet) - Change adapter settings (settings adapter settings) - adapter properties ", where we can see the tab" authentication ":



when you are sure that the policy is successfully applied - you can proceed to Setting up the network policy on the NPS and the access layer switch ports.

Create a network policy 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)

Typical settings for the switch port (I draw attention to the fact that the authentication type is “multi-domain” - Data & Voice, and it is also possible to authenticate to the mac address. For the “transition period” it makes sense to use the following parameters:

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

the id is entered not of “quarantine”, but of the same one where the user computer should get after successfully logging in - until we make sure that everything works as it should. The same parameters can be used in other scenarios, for example, when an unmanaged switch is inserted into this port and you want all devices connected to it and not authenticated to fall into a certain vlan (“quarantine”).


You can verify that the computer / phone successfully authenticated using the command:

sh authentication sessions int Gi1/0/39 det

Now create a group (for example, sg-fgpp-mab ) in the Active Directory for phones and add one test device to it (in my case, this is Grandstream GXP2160 with the mass address 000b.82ba.a7b1 and the corresponding account domain \ 000b82baa7b1 ) .

For the created group, we will lower the password policy requirements (using Fine-Grained Password Policies through the Active Directory Administrative Center -> domain -> System -> Password Settings Container) with the following Password-Settings-for-MAB parameters :



thereby allowing us to use the mas address of devices as passwords. After that, we can create a network policy for 802.1x method mab authentication, let's call it neag-devices-8021x-voice. The parameters are as follows:

• 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

after successful authentication (do not forget to configure the switch port), see the information from the port:


Now, as promised, consider a couple of not-so-obvious situations. For example, we need to connect computers \ devices of users through an unmanaged switch (switch). In this case, the port settings for it will look like this:


PS a very strange glitch was noticed - if the device was connected through such a switch, and then it was stuck in a managed switch, then it will NOT work until we restart the (!) Switch Until I found other ways to solve this problem.

Another point related to DHCP (if ip dhcp snooping is used) - without such options:

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

for some reason, the IP address cannot be correctly received ... although this may be a feature of our DHCP server.

And Mac OS & Linux (in which native 802.1x support) are trying to authenticate by the user, even if authentication by mass address is configured.

In the next part of the article, we will consider the use of 802.1x for Wireless (depending on the group the user account is in, we will “drop it” into the corresponding network (vlan), although they will connect to the same SSID).