Understanding Policy Logic in ISE

Understanding how policy and policy flow works in Identity Services Engine (ISE) is essential for managing and securing network access effectively. Cisco ISE uses a robust policy engine to determine how users and devices authenticate, what level of access they receive, and how network resources are allocated based on identity and context. By understanding the flow of these policies, from authentication through authorization, you can fine-tune network access controls to meet security requirements while maintaining flexibility. In this post, we will break down the components of policy creation and explore how policy flows work in Cisco ISE, giving you the knowledge to manage network security with precision and confidence.

The logic of ISE policy creation is pretty straightforward. Almost every policy in ISE comes down to the following logic:

In the early ISE 1.x days, the policies were managed on two different pages: Authentication and Authorization.  Every single authentication rule was in one running list, and every authorization rule was on a separate, long running list.

So what was the problem with that? A rule misorder or misconfiguration could affect your entire deployment. That means a slight change to a wireless authentication rule could have potentially resulted in an outage for VPN, wired, etc! On top of that, trying to troubleshoot access issues was a nightmare when trying to scroll through hundreds of authentication rules.

Thankfully, in ISE 1.3, the creators introduced something called Policy Sets. Identity Services Engine (ISE) policy sets have simplified the configuration process by allowing administrators to group related policies into a single, cohesive structure. Prior to policy sets, administrators had to manage authentication and authorization policies separately, which could become cumbersome and complex, especially in large or diverse environments. Authentication, and authorization rules are consolidated under a single logical bucket, making it easier to manage, view, and apply policies based on specific conditions, such as device type, location, or user identity. This streamlined approach reduces configuration complexity, improves clarity, and enhances the scalability of the network security setup, allowing for quicker, more intuitive policy management.

Policy sets let us segment and logically group authentication and authorization rules by use case or condition. For example, we can have separate authentication/authorization rules for a single SSID or location. If we make any changes to those rules, they don’t affect the rest of our policies. Likewise, suppose we’re troubleshooting an issue with someone connecting to that SSID and need to change an authorization rule. In that case, it is easier to drill down to which rules we need to look at, and if changes need to be made, we know that it won’t affect our wired, VPN, or other network access control policies.

Policy sets have a top-level condition. If a RADIUS packet is received, ISE will first check the policy set list. As soon as ISE finds the first top-level condition matches a policy set, it will evaluate the RADIUS session based on the authentication and authorization rules in that policy set. It will not evaluate any other policy set for that session.

Then, ISE will evaluate the RADIUS session against the authentication rules in that policy set. If the RADIUS session meets a specified condition (e.g. dot1x), then it can be authenticated against a specific identity source or identity source sequence (e.g. Active Directory).

However, a successful authentication does not necessarily mean access! That’s why we have authorization rules to tell ISE what access to grant based on the conditions we want.

After the successful authentication, ISE evaluates the RADIUS session against the authorization rules in that policy set. If it meets certain conditions (e.g. user is a member of the Active Directory group “Employees”), then we grant a level of access (e.g. Employee SGT).

The following is an animated demonstration I gave in my most recent Cisco Live presentation.

Note: You might have to full-screen the videos to see the full animation.

In the following video, ISE receives a RADIUS packet from a network access device located in SJC01 and part of the windows-dot1x-azure group. The first policy set that this RADIUS session matches is the policy set named Dot1x-AzureAD. 

Next, the RADIUS session is evaluated against the authentication rules in the policy set.

In this case, it matched the Dot1x-TTLS authentication rule because the EAP-Tunnel was EAP-TTLS, so the RADIUS session was authenticated against AzureAD.

After successfully authenticating, the RADIUS session is evaluated against the authorization policy in the policy set.

Since the user authenticating was part of the EmployeeGroup in AzureAD, they matched the Employee_Policy rule and were granted Full-Access.

Understanding how the policy logic flows and how ISE policy is evaluated is one of the essential parts of creating policy, designing your policy sets, and making troubleshooting easier.