I’ve always wondered if it were possible to control access for a user to a VLAN based on their logon credentials and recently embarked on seeing if this was possible. We commonly use authentication in order to grant or deny permissions to the network for VPN’s and wireless connections but when it comes to physical connections into the network we rely on other physical security factors before considering technical solutions. Step in 802.1x.
802.1x allows a compatible client (a.k.a. supplicant) to pass the credentials to the switch using EAP which then authenticates the user against a RADIUS server. If the credentials match the user is granted access to the network, otherwise the user is refused – it is at this point controls can be put in to move the device into a quarantine or guest VLAN to still give some level of access.
As above, the client, or supplicant, first connects to an 802.1x enabled switch port which starts the process with an EAPOL request. The switch (authenticator) sends an EAP identity request to the client which provides a response and is forwarded onto the RADIUS server inside a RADIUS packet. The messages flow back and forth until eventually the client is either granted or refused access. Finally, when the client logs off an EAP logoff message is forwarded to the authenticator which reverts the port to an unauthenticated state.
I decided to lab this up myself to see just exactly what is involved and was surprised by how straight forward it actually is. Firstly, you need to enable the “Wired AutoConfig” service on a Windows PC that will be the supplicant.
Wired AutoConfig service
Once the service is started, you’ll be given a new “Authentication” tab on the properties of the NIC:
In here you can modify the EAP settings you’re wanting to use on your network – for now we’ll go with “Microsoft: Protected EAP (PEAP)” and continue to configure this. To make the setup as straight forward as possible we’ll keep the settings as default and make a small change in the advanced settings section to specify that we’re going to use User Authentication mode only. This is pretty much it for the client, now we need to do some configuration of our RADIUS server.
Specify authentication mode
In my demo we’ll be using a domain joined Microsoft Server 2012R2 VM (evaluation versions are available from Microsoft) equipped with the Active Directory and NPS roles. Within the NPS console, you’ll want to add the IP of the switch that will performing the authenticator function – one thing to be aware of is that you’ll want to reference the switch IP for the SVI that will be sending the RADIUS messages to the server.
You’ll then want to go ahead and create a Connection Request Policy or retain the default as we’ll want to authenticate users’ Windows credentials anyway. We will however want to make a Network Policy – in this example we’ll create one called “Allow 802.1x clients”.
Connection Request Policy
The policy needs to be enabled and in a suitable position in the list of existing policies in order to be processed correctly. This policy will grant access if the Conditions are met. Within the Conditions tab we’ll just choose the NAS Port Type to be Ethernet, however this can be refined down depending on your security requirements with additional conditions.
Finally, we’ll want to set the authentication methods in the Settings tab to allow PEAP. It’s possible within here to define a certificate to be used by clients to verify the identity of the server, further increasing security – for now we’ll leave that step.
Lastly, we’ll need to go to the switch and setup some commands on there. In this example I’m using VLAN30 for authorised users, while VLAN20 is assigned for those who fail to authenticate with valid credentials and VLAN40 is used for any client who fails to provide EAP messages within the default time period .
aaa authentication dot1x default group radius
switchport access vlan 30
switchport mode access
dot1x pae authenticator
dot1x port-control auto
dot1x guest-vlan 40
dot1x auth-fail vlan 20
dot1x auth-fail max-attempts 1
radius-server host 172.16.0.20
radius-server key CiscoLab
Breaking down these commands from, we’ve got our AAA commands at the top instructing the switch to enable AAA new-model and for dot1x authentication to use the RADIUS server group which includes the server we’ve defined at the bottom of the commands. On the interface, we’ve statically defined VLAN 30 which will be used if the client is authorised by the RADIUS server and assigned the switch port to implement port-security. The ‘dot1x pae authenticator’ command (PAE = Port Access Entity) enables 802.1x authentication on the port with default parameters below:
The ‘dot1x port-control auto’ command enables authentication on the interface, allowing the dot1x process to either authorise or not authorise a connection. It’s possible to force authorisation or un-authorisation too. We’re going to set clients into VLAN40 who refuse to send an EAPOL message with the ‘dot1x guest-vlan 40’ command and the ‘dot1x auth-fail vlan 20’ tells the switch we want unauthorised clients to drop into VLAN 20, while the ‘dot1x auth-fail max-attempts 1’ tells the switch to make the port go into unauthorised after just one failure (for the purposes of the lab it speeds up seeing results).
To verify the authentication you’ll want to connect a device that has already been configured as per the instructions earlier in the post. If the device is domain joined and the “use my Windows credentials” box was ticked then you’ll probably not see much as the Windows credentials are passed through automatically otherwise you’ll get a Windows authentication prompt where you can enter the username and password. Once a device is connected you can issue this command on the switch to view the authentication status, ‘show dot1x details’ which will present either of four scenarios:
|Port State||Port Status output||Authorised By output|
|Pending client 802.1x EAPOL||UNAUTHORIZED||N/A|
If you need to do any troubleshooting you can check the Event Logs on the NPS server to get some really detailed output on what is being passed to it from the authenticator device and then use that output to fine tune any policies.
NPS Event Log for incorrect credentials
In a future post I’ll explore how to expand on all of this to allow the NPS server control over the VLAN assignment. This feature is quite powerful as it can allow users or devices access to different VLANs based on their roles for example. A use perhaps would be to place non-NPS capable devices onto one VLAN, with staff, students and guests receiving different VLANs suitable for their level of access.
Here are some materials that give further reading on the NPS / RADIUS / 802.1x setup: