Cisco’s Identity Services Engine (ISE) is a powerful rule-based engine for enabling policy-based network access to users and devices. ISE allows policy enforcement around the Who?, What?, and When? of network access.
- Who is this user? A guest? An internal user? A member of the Finance department?
- What device is the user bringing onto the network? A corporate PC? A Mac? A mobile device?
- When are they connecting? Are they connecting to the secure network during regular business hours or at 02:00 in the morning?
These questions can all be answered easily within ISE and are all standard policy conditions that are relatively easy to implement. In the post below I’m going to focus on the How? — How is the user or device connecting to the network? Asked another way, the question is Wired? or Wireless?
Why Does Wired or Wireless Matter?
TL;DR answer: Because if you can differentiate between the two types of users, you can apply different policies to each group. (And you almost always want to apply different policies to wired vs wireless users).
Longer answer: The most basic ISE policy would typically assign the user to a specific VLAN. This is really the most fundamental policy action. If corporate user, then put in VLAN X. If guest user, then put in VLAN Y. Policy complexity goes up from there which causes an even greater divergence of wired and wireless policy. Now, if you evaluate your wireless users against that same policy, does VLAN X and Y even exist on the wireless network? Probably not. Your WiFi network is probably either a more enterprise-y deployment with distributed access points (APs) and central controllers that have their own VLANs for bridging user traffic or you’ve got standalone APs doing the AAA requests themselves in which case they will ignore the VLAN that ISE sends and will dump every user into the same VLAN (which violates policy).
It’s important to apply unique ISE policies to wired and wireless users because it’s typical to have different business/security/technical policies for them.
Underneath the covers ISE uses the RADIUS protocol to perform authentication, authorization, and accounting (AAA) functions. Between a client (the switch, access point or wireless controller where the user is connected) and the server (ISE) RADIUS passes attribute/value pairs (AVPs). These AVPs allow client and server to pass relevant information back and forth. For instance, the client informs the server of the username, password and MAC address of the end user trying to get onto the network. The server in turn replies with AVPs of its own which can include things like whether to allow or deny the access, the IP address the client should take and how long they’re allowed to stay on the network.
In addition to the basic AVPs, there’s a lot of AVPs exchanged that carry metadata about the session. This metadata is what’s used to answer the Wired? and Wireless? questions.
Inspecting RADIUS Attributes
Ok, so the RADIUS AVPs are being exchanged, how do we inspect them? This is the job of a “condition” in ISE.
I equate policies in ISE to an if-then-elseif-then ladder. The individual rules in the policy equate to a single “if” or “elseif” rule. The ISE conditions then are the expressions that are evaluated in the “if” or “elseif” rule. In fact, the policy editor screen even expresses the rules in an if-then fashion:
As you can see in the screenshot, the conditions Cisco-IP-Phone, isFinanceUser, and isCorporateUser are consumed by the policy rules but their actual definition is not visible when looking at the policy. The conditions are defined separately from the policy which allows a condition to be treated as a building block and reused in multiple rules. My example policy below will use this feature when testing if a client has initiated an 802.1X connection.
Conditions are defined in the Policy, Policy Elements, Conditions menu in ISE. There are six categories of conditions but I’ll only be looking at the Authorization (authz) conditions. Authz conditions come in two flavors: simple and compound. Simple conditions evaluate exactly (1) expression while compound conditions can evaluate multiple expressions with each either logically ANDed or ORed together.
Building the Conditions
ISE does most of the heavy lifting for us in the conditions department. It comes with policies for matching wired and wireless users already. However what I’ve found useful is to create conditions to match specific wireless networks as identified by their SSID. This allows specific policies on a per SSID basis.
Inside Policy, Policy Elements, Conditions, Authorization, Compound Conditions, add a new policy. Name the policy and give it a description. Then choose to “Create New Condition”.
Select the expression under “Radius” called “Called-Station-ID”. For a WiFi user, this AVP is sent to ISE as the MAC address of the access point and the SSID concatenated together with a colon (:) between them. Since the MAC address is irrelevant to our policy, we’ll use a “Matches” operator instead of “Equals” to just inspect the SSID part. Do not use “Equals” with a value of the SSID. It won’t work. “Match” conditions take regular expressions as a value. To match the SSID “Corp” use:
This says to match any number and type of character (.*), a colon (:), and the word “Corp” which must appear at the very end of the AVP value ($ means “at the end”).
That’s it for conditions. We’ll pair this with the existing one called “Wireless_802.1X”.
Updating the Policy
Now that we have the building blocks of our policy rules created we can update the policy. Written in plain language, our mock policy is this:
- Users in the finance department who connect to a wired port using 802.1X must be put in their own VLAN
- All other corporate users connecting on a wired port using 802.1X must be put in the general user VLAN
- Any user who connects to the “Corp” WiFi network using 802.1X must only connect between the hours of 08:00 and 18:00
- Everyone else is denied access
Even though I’m mentioning the policy results (the VLANs and time restrictions) above, I’m not going to show how to create them.
Translating our plain language policy into ISE means we’ll have to modify our existing finance and corporate user rules, add a rule for the Corp WiFi network, and modify the default rule from its stock “allow all” posture to “deny all”.
Whereas the simplest policy rules — and even the stock rules that come with ISE — only use a single condition, we’ll need to use multiple conditions which are logically ANDed together to get our desired results. For example, in our first rule we’ll need to look for members of the finance department AND users who are connecting on a wired 802.1X port. By adding conditions from the library, this rule can be built up to match our business policy.
Notice the choice of ANDing or ORing the conditions together.
There it is. The first rule is complete. Now update the wired corporate user rule and create the WiFi rule and the policy should look like so:
By using the built-in conditions to test for wired and wireless connectivity and creating a custom condition to look for a specific SSID, unique policy results can now be applied to users based on answers to the questions Wired? and Wireless?