What You’ll Learn
- Overview of the Cisco Identity Services Engine (ISE) policy set
- How to create a policy set using the ISE PAN GUI
- How to create an effective policy set using the proper conditions
What You’ll Need
- Cisco ISE 3.x installed on VMware or a dedicated server
- A client computer to access the ISE PAN
- Cisco ISE 3.1 DevNet Lab: https://devnetsandbox.cisco.com/RM/Diagram/Index/ad4bb2ae-bb67-4d93-9f0d-2a6a04792e2e?diagramType=Topology
A policy set allows the administrator to control the type of access that a user can have on the network—for example, network access use cases such as wireless, wired, guest, and client provisioning. Policy sets come in two forms: network access and device administration sets. We will focus on network access because we are trying to limit the type of access that a user has on the network.
The ISE box is broken up into multiple personas to allow better management and scalability. They are:
- PAN (Policy Administration Node, aka GUI)
- PSN (Policy Service Node)
- MnT (Monitoring Node)
- PxGrid (pxGrid Node)
When you set up a policy set on the PAN GUI, the PSN will process all access requests from an enforcement device that the client is attached to. The enforcement device can be a switch, access point, VPN device, or other supported devices on the network. This enforcement device will then send the access request to the PSN in the form of a RADIUS Access-Request. This is when the PSN will look at the policy set that is configured and process the rules. However, what if you have three policy sets? This is where conditions play a big role. Each policy set can be configured to use one or more conditions that have to be met in order for that policy set to match. After a matching policy set is found, the PSN will process the rules that are inside that policy set.
After a policy set is matched, the policy set will then process two different policies—the authentication policy and authorization policy. Both these policies have rules that have to match to proceed with the network access that the PSN will ultimately give the client via the enforcement device. This can be a downloadable access control list (dACL), VLAN, or security group tag (SGT).
Authentication Policies
Authentication policies are used to authenticate the user via an Active Directory server, Lightweight Directory Access Protocol (LDAP) server, certificate, security assertion markup language (SMAL) server, or other supported authentication options. This is done using rules with conditions that have to match. For example, an administrator can say that you need to be part of the AD Group Admin Users, and you need to present a certificate called MyCA on the issuer section of the certificate. If not, you failed authentication if no other rules match. We can also consider other information that the policy set received as part of the RADIUS Access-Request, such as whether this is coming from a wireless or wired device, whether this is coming from a certain enforcement device, and so on.
Authorization Policies
Authorization policies are used to find other conditions that need to match for the user to get the access they need on the network. This task is also done using rules with conditions that have to match. The difference is that an authorization rule has a result, meaning that after you match a rule when conditions are met, you will be given an authorization profile that the administrator has assigned to that rule. The authorization profile can mandate that the user be moved to a certain VLAN or be pushed to a dACL in order to comply. All this is sent via the PSN using a RADIUS Access-Accept to the enforcement device.
Default Policy Set
By default, there is one policy set configured on the ISE server when first installed.
In order to create more sets, you will need to click the sprocket icon and choose Insert new row above.
As you can see, we created two new policy sets—one named Wired and the other named Wireless.
The challenge with having your own custom policy sets is, how does the ISE server know which one to use? This is where conditions come into play.
Click the + icon under Conditions to open the Conditions Studio. The Conditions Studio will allow you to pick from a variety of conditions, including options that were sent from the enforcement device during the Access-Request processing or other options such as whether it is a wired or wireless device sending the request. Note: The Library column shows the most-often used conditions.
The Conditions Studio also gives you the option to create your own custom condition, allowing you to pick your own attributes to match the policy set that you want the ISE server to use.
As you can see, we picked conditions that were part of the library. Notice that we also picked Default Network Access in the Allowed Protocols section. This controls which Extensible Authentication Protocol (EAP) types that the ISE server will support as well as other authentication options. Be sure to save your work.
Next, click the > icon to edit the policy set.
Once you are inside the policy set, you will see the available policies that you can edit. We will work with the authentication and authorization policies.
If we click Authentication Policy, we will see that there is a default rule already there. The Use column indicates All_User_ID_Stores. All_User_ID_Stores is an Identity Source Sequence, which allows the administrator to pick from a sequence of authentication servers that the ISE server can use to authenticate the client request coming from the enforcement device. This can be left as the default, but it can be customized with conditions of your choice by using the + icon.
After authentication is successful, the ISE server will then process the authorization policy rules. There is only one rule active by default, called Default. As you can see, the Profiles option is set to DenyAccess, and the Security Groups has nothing selected because it is optional. We have only the default rule, so everyone will be denied access, regardless of whether the client has passed authentication.
The next step involves creating a new rule. On the Authorization Policy, click the sprocket icon and choose Insert new row above.
Notice that we named the rule Domain Users. On the right under Profiles, you will see that we have a menu of selectable authorization profiles that will control the user access when the rule matches.
We can also search for certain authorization profile names by using the search bar atop the Profiles menu.
In this case, we selected PermitAccess, which is a generic authorization profile option on Cisco ISE. This option will send back an Access-Accept to the enforcement device with no restrictions. Note that we have not selected any conditions yet; we will do so later. The generic PermitAccess is useful for certain use cases where we want to give unlimited access. But what if we want to limit that access?
If we want a profile with better restrictions, we need to create a custom authorization profile. Using the menu on the top left of the Cisco ISE GUI Dashboard, under Policy Elements, select Results.
Under the Authorization menu, select Downloadable ACLs, and click Add.
From here, we will give the dACL the name HTTP_Only. At the bottom, you will then add ACL statements. This is very similar to Cisco IOS ACL statements, except that:
- No ACL name is required on the statement; this has already been done at the top of the dACL.
- The source needs to be ANY, because the enforcement device will fill in the IP for the user trying to gain access.
Once you are done typing in the ACL statements, the dACL has an option to check the syntax of the statements that were entered.
Now, we need to apply it to an authorization profile. From the Authorization menu, select Authorization Profiles, and click Add.
When naming the authorization profile, it is recommended that you name it something that will describe the usage. Doing this will make it easy to know what it does when applying it to an authorization rule. In this example, we named it Allow_ONLY_HTTP. As you can see, this authorization profile will use the RADIUS Access-Accept to return the result to the enforcement device. We also selected the type of enforcement device we are using—Cisco. Under Common Tasks, select DACL Name from the menu, and choose the HTTP_Only dACL.
We also moved the client to VLAN 15. Note: The switch that the client is attached to needs to already have this VLAN created on the database.
As we go to the bottom of the authorization profile, note that we can send more than one result back to the enforcement device, but not all enforcement devices will support this. Once you are done, click Submit to save the authorization profile.
The new custom authorization profile has been created, and as you can see, we added it to our Domain Users rule. The next step involves creating conditions to match this rule. An authorization rule is very much like an ACL on a Cisco IOS router. Like an IOS router, the ACL needs to match the following:
- Source (SRC) IP
- SRC port
- Destination (DST) IP
- DST port
- Protocol
The authorization rule works much the same way, but instead of using IPs and ports, why not use attributes about the user, the session info, or other supported options? We can start by clicking + to add a new condition to the rule.
This action will bring us to the Conditions Studio. Choose the Click to add an attribute option.
There are many attribute options, as you can see. The rule of thumb you should follow is that you should use an attribute that you know the user will send every time they log in. In other words, it should be predictable, and consistent.
We will use the Identity attribute option. Select IdentityGroup from the menu.
While clicking the menu selection arrow key, Choose User Identity Groups:Employee as the group. This means that if the user is part of the Employee ISE Identity Group, they will match this rule. But we can also add more conditions.
To add another condition to the rule, select NEW.
In this case, we are also requiring that the user has Protected Extensible Authentication Protocol (PEAP) as the EAP type.
We can also control how many conditions need to match by using the AND or OR option. If we choose AND, it means that all the conditions need to match. If we use OR, it means that only one of the conditions needs to match.
As you can see, we now have a working rule that will allow domain users limited access if they are part of the ISE Employee Identity Group and if they are using PEAP as the EAP type.
