Cisco ISE provides a lot of features such as compliance, BYOD, guest wireless, Trustsec, TACACS and wired & wireless access. This post will describe the basic configuration for wireless authentication and authorization using IEEE 802.1X. This post is mainly based ISE version 3.1. The post will focus on the ISE policy set.
Dot1x hinges on the use of RADIUS. When a wireless clients tries to connect to a wireless network, the access point will communicate to ISE (using its RADIUS server IP addresses). This RADIUS communcation wil achive two things; authentication and authorization. If the authentication is successful, ISE will respond back to the AP with a successfull authorization after which the client can connect to the wireless network.
From an ISE perspective Policy sets are where ISE does its the authentication and authorization descision making. So the authentication part of this process decides IF a user can connect to the network and the authorization part dictates WHAT the user can access.
Prerequisites to configuring policy sets
Before I go into detail on policy sets, you would need to configure a number of items first. The most important ones are: external identity stores and network devices.
First you will need to add all your network devices that will communicate to ISE for authentication/authorization. This does not only include RADIUS, but also TACACS. This is where the IP address of the network device is set (this is the source IP address for all RADIUS communications from the network device to the ISE server (PSN) this IP address needs to be identical.
Administration > Network resources > Network Devices
If you are going to configure policies that are using AD groups as a way to authenticate users, you will also need to add an external identity source a.k.a. Join Point, as you can see below.
Administration > Identity Management > External Identity Sources
You can get more granular and only make certain AD groups available by going into groups and add/delete groups. These groups will later become available when configuring your authentication policies
I do not want ot go into further detail on how to integrate AD with ISE and uploading certificates etc. because this post is aimed at the workings of policy sets. I merely want to point out that setting up join points are a prerequisite for configuring policy sets that use AD.
OK so Back to policy sets, the following picture shows the scenario what we are going to configure:
For this on your Wireless LAN controller, you will need to configure AAA methods pointing to your ISE servers so that each WLAN that requires Dot1X points to ISE for authentication and authorization purposes.(as per below)
Assign the method to your WLAN (in this demo case, we will use 1 WLAN with a PSK and one WLAN with dot1x).
You will need to use AAA override on your WLC configuration to allow ISE to stipulate VLAN assignements and dACLs. You can find a detailed description on AAA override at:
Again, I do not want to spend to much time on detailing on how you need to configure the WLC because that is not what this post is about.
Configuring Policy Sets
Once you have configured your WLC, you can then set up your AD integration in ISE and have added your network devices into ISE, you are ready to start putting together your ISE Policy set.
There are 3 main components to a policy set:
- Policy set condition
- Authentication policy
- Authorization policy
ISE evaluates these components sequentially.
1. ISE Policy set conditions
ISE policy set s work similar to access-lists; the are evaluated top down. If the condition is met, it will not continue down the line. Policy sets are in essence collections of authorization (AuthZ) and authentication (AuthC) rules. If there is any overlap in conditions, you should order the more granular/specific condition to the top.
Also it is important to understand, that if a condition is met and the authentication for that policy set is unsuccessfull, it does not move on to the next policy set in the list.
The picture below show the basics of the policy set conditions and allowed protocols.
The allowed protocols are usually left to Default, This means all protocols, that are turned on, are allowed. You can create additional allowed protocol lists, to force only a certain protocols.
The picture below shows a list that only allows EAP-TLS.
U can then use this exclusive list as your allowed protocols.
For our demo scenario we have 2 SSIDs. One uses dot1X and one uses PSK. This means that we need two policy sets; one that meets the C9800-dot1x SSID and one that meets the C9800-PSK SSID.
To achive this, you can use the called station-ID and the SSID name as the condition set.
2. Authentication policy
After we have created our ISE policy set condition, in step1, we will now need to authenticate the supplicants credentials. Remember step 1 only matches something wanting to authenticate dot1x with a called station ID of C9300-DOT1X. The authentication policy now defines how we are going to check the credentials.
The authentication policy defines how users are authenticated against which source (STORE).
Basically the authentication policy sets a condition. After this condition is met the result defines the store against which authentication is checked. This store could be AD, internal identity store or Certificate Authentication Profile etc.
By default, when you create a new ISE Policy set, the authentication condition is populated with the default value. This will use all identity stores as its source:
Although leaving it to default will probably work, i think this is not a good habit. In our case we can set it to use AD as the source, because the authorization will be checked against AD group membership.
3.Authorization policy
Authorization deals with the WHAT of the RADIUS transactions. What can the user/endpoint access AFTER its successful authentication. The picture below shows this:
A condition is met the result kicks in. The result is defined in the authorization profile. The authorization profile can contain for example a VLAN assignment or a downloadable ACL (dACL). As a result you would like to configure your results first, before you configure your policy sets. Our scenario needs a distinction between contractors and employees, once they try to connect to the C9300-DOT1X SSID, as per below:
The condition here, is that contractors are part of the Users/Contractors AD group and Employees are member of Users/Domain Users Group. Based on this group member ship an authorization policy is applied. To configure a result got to Administration > Policy > Policy elements > Result > Authorization > autorization Profile/dACL
So for the IoT profile you could create a profile with the following dACL (allowing only internet traffic):
We can can now define this dACL inside the IoT authorization profile. Ofcourse the Access Type in your profile would have to be ACCESS-ACCEPT.
What this actually means is that within a certain single policy set you can have multiple authorization conditions. In our case, we want role base access on the same SSID. In order not treat contractors and employees equally in terms of access.
I have to add that this post describes just ONE method to meet the use case scenario. There are plenty more ways to achieve the same objective. In general ISE policies come down to the creativity of the engineer . There simply is no one size fits all.
Because I am on a journey to learn more about ISE, no doubt i will do more posts on ISE policy set.
Namaste!
Comments