This is part 2 of my blog series on rapid prototyping without any real networking equipment.
There is a wealth of information on the internet about configuring Radius Servers (Cisco ISE or Aruba Clearpass) to perform a multitude of operations.
This blog series aims to help the network administrator in configuring their RADIUS Server policies.
- Prototyping RADIUS Server Policies: Part 1
- Prototyping RADIUS Server Policies: Part 2 (this blog)
- Prototyping RADIUS Server Policies: Part 3
Let's get more creative and look at testing some EAP methods. The most common method found in enterprises is probably EAP-PEAP with MS-CHAPv2 inner authentication. Typical real-world use case examples include Windows/OSX/Android supplicants where the credentials are typically looked up in Active Directory or LDAP.
There is a great test utility from the wpa_supplicant suite (a suite of tools to test EAP methods, and simulate a supplicant and/or wireless access points).
You can do amazing things with wpa_supplicant when combined with a real wireless access point. But what if you just want to simulate the EAP authentication without all the nuts and bolts of a wireless infrastructure? Let's face it, our AAA server ultimately processes Radius packets which are the result of the interactions of the supplicant and NAD (authenticator). Keep reading to find out how to mimic a real EAP conversation to a Radius server.
EAP Framework in wpa_supplicant
As mentioned in the introduction, the wpa_supplicant package contains the tools we need, and this suite is available in most Linux distributions - in the Redhat/CentOS distribution it can be installed with yum
yum install wpa_supplicant
In this blog we’re only interested in the utility called eapol_test contained in the package.
EAP-PEAP Example Using eapol_test
There is a command line component as well as a configuration file. The configuration file (let's call it mschap.conf) should contain the following text - edit it appropriately - however the only thing you should need to edit are the identity (MSCHAP username) and the password, which are the credentials stored in your AAA or AD.
The ca_cert is a nice to have and it will be used during the TLS setup to validate the Radius Server certificate.
# Line below performs server certificate validation.
# It is optional - just comment it out if you have no certificate
Now you can execute a PEAP authentication as follows
eapol_test -c mschap.conf -s RadiusS3cret -a 192.168.21.101 -M '00:00:00:00:00:10' -N '6:d:2'
The Radius server in my example is Cisco ISE but it could be any Radius product that supports EAP. In my example the Radius server listens on 192.168.21.101
We shall pretend to be a Wi-Fi client with MAC address (Calling-Station-Id) of 00:00:00:00:00:10
The -N '6:d:2' is a handy argument to add additional Radius attributes to the request. The effect of the argment is to send a Service-Type=Framed attribute (see RFC2865 section 5.6). The value 6 is the radius attribute value that specifies 'Service-Type', and 2 is the decimal constant that defines 'Framed'.
The output of the command is quite verbose and mostly not needed. We generally look out for the last few lines of the command’s output, to reveal a success or failure.
MPPE keys OK: 1 mismatch: 0
Prototyping RADIUS Server Policies: Summary
The ISE server and the eapol_test utility enter into the usual EAP exchange and the result is true to the real world.
You can test your Radius server’s EAP policy logic without ever having to touch a real networking device! This is a real productivity boost. But be aware that there is no substitute for the real experience since the real devices may not always do the right thing.
As with all work you undertake on your RADIUS installation, take great care to have a backup and backout plan: this tends to be critical infrastructure, so take care when making any changes to a live network.