Ciscos 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 Im 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?
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 youve 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).
Its important to apply unique ISE policies to wired and wireless users because its typical to have
different business/security/technical policies for them.

RADIUS Attributes
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 theyre allowed to stay on the network.
In addition to the basic AVPs, theres a lot of AVPs exchanged that carry metadata about the session.
This metadata is whats 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 Ill 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 Ive 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, well use a Matches operator instead of Equals to
just inspect the SSID part. Do not use Equals with a value of the SSID. It wont work. Match
conditions take regular expressions as a value. To match the SSID Corp use:
.*:Corp$
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).


Thats it for conditions. Well 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 Im mentioning the policy results (the VLANs and time restrictions) above, Im not going to
show how to create them.
Translating our plain language policy into ISE means well 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, well need to use multiple conditions which are logically ANDed together to get our desired
results. For example, in our first rule well 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?