Cisco ISE has a feature called Policy Sets, the purpose of policy sets is to give you the ability to logically group authentication and authorization policies within the same logical entity. So for example you could have separate authentication and authorization policies for wired/wireless/vpn or another use case for your business. By default Policy Sets is not enabled on a vanilla Cisco ISE deployment and the Policy Set is defined as default on a vanilla installation (more on this later).
Not only does using Policy Sets make it easier to logically group different business user cases into their own individual policies it actually makes reading the operational logs for troubleshooting much easier.
So in the remainder of this post I will go through and examine what the default policy set gives you and how to enable policy sets and leverage those on your ISE deployment.
Default Policy Set View
In a vanilla installation of ISE you do not have Policy Sets enabled, therefore you will get a view like the one below. What this view gives you is the default policy set view, you define all your different use cases in the authentication and authorization tabs.
A typical Authentication Policy would look something like:
As you can see in the policy set above we have no logical separation of the wired and wireless policies, they are grouped together. We could create separate policies here, but there isn’t much value if you are going to use the same Identity Store Sequence. The authorization policies would live under the authorization tab, I won’t cover them here as they can take any shape and form depending on your requirements.
So from a logging perspective, if an authentication policy matches it will display Default >> MAB or Default >> Dot1X. Which isn’t too informative, how do we know if that the policy matched was for Wired or Wireless for example?
Enabling Policy Sets
To enable Policy Sets it’s relatively simple, to enable within ISE navigate to Administration > System > Deployment > Settings > Policy Sets and select Enabled.
After enabling, you are prompted to re-login. Once you have logged back in you will be presented with a new view, like the one below:
The Authentication and Authorization Tabs have now been collapsed into the single Policy Set Tab. By default all of the Authentication and Authorization Policies you had defined prior are put into the Default Policy Set view, so you don’t lose what you have already. As always if you are making change to a production ISE environment, it’s recommended to only make changes in a maintenance window with a valid backup too.
The view you will receive with all of your policies after enabling Policy Sets will look similar to below:
To create your own Policy Sets, just click the PLUS symbol in the left hand corner. When you create a new Policy Set, you need to set a condition to match. So for example if I wanted to create a Policy Set for Wireless I would create a condition to match only wireless connections, once that match occurs the authentication and authorization policies within that Policy Set would take affect and no other.
Now let’s take Policy Sets one step further, if we were to look at our operational logs, we can now easily distinguish which connection matches which Policy Set and therefore easily identify what’s happening. The snippet below explains how this all links up:
As you can see, Policy Sets make a lot of sense, they make the configuration a lot easier on the eye and troubleshooting much simpler. The only thing to watch out for is, once you enable Policy Sets and create custom Policy Sets other than the default, disabling Policy Sets will actually delete those custom Policy Sets and all associated Authentication and Authorization Policies.
Other caveats include:
- Policies rules cannot be shared amongst different Policy Sets, however conditions can be shared…So use conditions to simplify your configuration
- Duplication of rules only allowed if they are from the same rule type and within only one policy set