802.1x wired authentication with Cisco IOS - Part I (Supplicant/Client and Authentication Server/Radius Configuration)

Again a multipart series. This time around it is about 802.1x wired authentication (switch port) with Windows NPS  as Radius server and Cisco IOS Switch. In part I, we will look at client/supplicant (Windows 10) and server/Radius (Windows NPS) configuration. And in part II,  we will look at Cisco switch/authenticator configuration.

 Let's begin with our topology.
Topology for 802.1x wired
Topology for 802.1x wired
In our topology we have 4 vlans which are server (id 245 - 172.16.245.0/24), client (id 246 - 172.16.246.0/24), guest (vlan id 247 - 172.16.247.0/24) and mgmt (vlan id 250 - 172.16.250.0/24). The NPS server has an IP adress of  - 172.16.245.11/24. The router is the gateway to all of the vlans. The client will get an IP adress from vlan 246 or 247 depending on 802.1x authentication status. The NPS-Server also acting as a DHCP server for different networks.

 We are testing only dot1x authentication. There is no traffic filtering applied between client and guest vlan. When a client is placed into vlan 246 (client) or guest (246) by dot1x, it has the same level of network access. Here we are testing authentication of a wired clients using 802.1x, not access to the network using firewall rules.

Before driving into the configuration part, let's introduce us to three (3) terminology - 

  • Supplicant/Client - In dot1x supplicant always means client, for example - end users computers. They will run 802.1x client software and by using that client software they will request network access. We are using Windows 10, as supplicant. Windows has a built-in dot1x client which is enabled by running the service named "Wired AutoConfig".
  • Authenticator/Switch - In wired 802.1x terminology an authenticator is always the switch. The switch acts as a proxy between supplicant/client and authentication server. It gathers authentication information from the client and send it to the authentication server. Upon successful/unsuccessful authentication from the server (NPS/Radius), the switch gives access to the client by opening switch port in different access vlans or deny access by disabling port.
  • Authentication Server - The server is responsible for processing client requests for authentication and inform the authenticator/switch whether it was successful or not. In turn, switch opens or closes it's port accordingly where the client is connected. In wired 802.1x, Authentication server runs radius protocol. We will configure Windows NPS server which is Microsoft's implementation of radius protocol.

 Let's start the configuration.

 Supplicant/Client configuration

 Our client will be a Windows 10 computer. We will start windows service named "Wired AutoConfig". We will do only username/password authentication. Certificate based authentication is beyond the scope of this article. How we have configured the client is given below in a series of screenshots - 


01-Enable Wired AutoConfig Service
01-Enable Wired AutoConfig Service
02-Configuring dot1x Client
02-Configuring dot1x Client
03-Configuring dot1x Client (disable certificate validation)
04-Configuring dot1x Client (enable user authentication)
04-Configuring dot1x Client (enable user authentication)

 If we have done the above steps, then we are done with client configuration.

 Authentication Server configuration
We are using Windows NPS as our radius server. I am not covering how to install NPS in windows. I will just show how to configure the various settings in NPS which is again a series of screenshots.

First we will generate a self-signed certificate in our windows NPS server using the below powershell command, the certificate is needed for PEAP authentication -

 New-SelfSignedCertificate –DnsName server01.family.local -CertStoreLocation “cert:\LocalMachine\My”

 Then we will create two users named user01 and user02, then assigned them to a group named group-dot1x. This group is used in our radius policy for authentication.
01-add-radius-group-user
01-add-radius-group-user
02-add-radius-client
02-add-radius-client
Then we will create a connection request policy in NPS.
03-connection-request-policy01
03-connection-request-policy01
03-connection-request-policy02
03-connection-request-policy02

03-connection-request-policy03
03-connection-request-policy03
03-connection-request-policy04
03-connection-request-policy04
03-connection-request-policy05
03-connection-request-policy05
Now we will create a network policy in NPS. The policy checks the conditions for successful authentication which are users must belong to the group named "group-dot1x" and the request for authentication comes from the switch (172.16.250.2). Upon successful authentication, the port will granted access to the network using VLAN 246 - client vlan (VLAN is radius/nps assigned).
04-network-policy01
04-network-policy01
04-network-policy02
04-network-policy02

04-network-policy03
04-network-policy03
04-network-policy04
04-network-policy04
04-network-policy05
04-network-policy05
Now we are done with the configuration of 2 terminology in wired 802.1X - supplicant/client and authentication server/radius. In part II, we will configure the last bit of the puzzle which is authenticator/switch and verify wired 802.1x operation.
References


  
Location: Sundsvall, Sweden

Comments

Post a Comment

Popular posts from this blog

Fortigate firewall AAA Configuration for management with TACACS+ protocol and Cisco ISE

Image
In this blog I will write about how to implement AAA services in Fortigate firewalls using Cisco ISE as an authentication server with TACACS+ protocol. First good to know our limitations. AAA means - Authentication (supported by ISE TACACS+), Authorization (partially supported by ISE TACACS+; Fortigate implements Admin-Profiles; so what a user can/cannot do is defined locally in the firewall with "Admin Profiles"; ISE just instructs the firewall to allocate one of those profiles), Accounting (not supported; instead configure syslog to get accounting data, Fortigate firewalls generate syslog messages for configuration changes made by a user). Let's jump to our configuration. Our topology is very simple; one Fortigate firewall and Cisco ISE server connected with the same management network which looks like below -  01 - Network Topology We have a management network 192.168.199.0/24. The firewall is at  .230  and Cisco ISE is at  .49  IP address. We are running...
Read more

Stacking switches Part - VI (Dell OS10 VLT - Virtual Link Trunking)

Image
In this blog I will configure MLAG (multi chassis link aggregation) for Dell OS10 switches. As every other vendor choses a fancy name of their implementation of MLAG; Dell is no exception to this. Dell calls their implementation VLT - Virtual Link Trunking . Let's look at our network topology - Two Dell OS10 switches will run peering between them and will run VLT/MLAG between them. Two Debian 10 linux machine will be connected with LACP bonding with both switches. They will simulate the client connection. Our topology looks like below - 01 - Dell OS10 VLT Topology Let's look at some terminology before configuration - VLT peer – The two switches participating in VLT are peer to each other. In a VLT domain a maximum of two switches are allowed. VLT interconnect (VLTi) – VLTi synchronizes state information between VLT peers. It synchronizes layer 2 and layer 3 control-plane information. These state/control-plane information includes MAC table, ARP table, IPv6 neighbors etc. VLT ...
Read more

Network device configuration management with Oxidized (Basic)

Image
I always like to work with open source tools. As a network engineer, we need to maintain a device configuration management system where we take backup of configuration for different networking devices like routers, switches, firewalls etc. We want to have our backups ready so that we can restore a device configuration when a device fails or replace with new one or for auditing purpose to track recent configuration changes. Today I will talk about such a open source tools named - Oxidized. Interested readers can have a look at it's GitHub page . It is a network configuration management tool with support for diverse networking equipments. Oxidized is developed with programming language Ruby. It is very configurable, extensible and can be integrated with management tools like Librenms . I will do a two part blog about Oxidized. In this part I will cover basic setup of Oxidized and start taking configuration backup of networking equipments. Network Topology Our topology l...
Read more