Chapter 6

Authorization

Abstract

This chapter will discuss the authorization (AuthZ) portion of ISE which is used to assign network access permissions to clients based on a set of criteria. We’ll talk about recommended ways to format and order rules so that clients go through the policy in the intended order. For wired connections we’ll cover topics such as overriding VLANs, applying dACLs, and assigning voice domain access to phones; wireless connections will cover overriding airspace interfaces and applying airspace ACLs and finally VPN connections will cover applying dACLs and overriding group policies for remote access.

Keywords

authorization

AuthZ

dACLs

airspace

Authorization (AuthZ) policies are the core of ISE functionality. The purpose of the authorization ruleset is to establish what kind of network permissions are assigned to a user or device. Permissions in terms of network permissions can take the form of a variety of things.

The anatomy of an authorization rule is very simple. Typically we recommend that you utilize conditions identifying some basic parameters about the connectivity being used including:

• Connectivity medium:

• Wired

• Wireless

• VPN

• 802.1x:

• Password-based AuthC

• Certificate-based AuthC

• Does the device match a profiling policy (printer, phone)?

• Is the MAC address a member of a static group (security badge reader, custom device)?

• Does the authentication have RADIUS attributes we care about?

• Calling station ID

• Called station ID

• What network device is the session originating from?

• What directory security group does the user belong to?

• What user identity group does the user belong to?

• What kind of information from the client certificate is available (if they’re authenticating with X509 credentials)?

• Certificate issuer

• Subject attributes (O, OU, State, City, Country)

• Subject Alternative

• Certificate expiration

Conditions come in two flavors when you’re configuring them in the authorization policy.

• Existing conditions

• New conditions

Let’s start with the new condition. The new condition option is where you select a single attribute you’d like to match, things like what you see in the above list of possible attributes. To start with, let’s match PEAP in our authentication.

You’re thinking you want to be more specific in your authorization rule and you want to add a second condition to the rule. If you select the gear, and select Add Attribute/Value, this is exactly like selecting “Create New Condition” from a new rule.

In this case we select “Domain User” membership in AD.¹

This would be really typical of a wireless authentication deployment for simple AD username/password authentication to ISE but to add a convenient way to specify that this was in fact a wireless authentication, and that it was done via 802.1x, we can use some of the ISE built in compound conditions. On the same gear icon select “Add Condition from Library”; this is exactly the same as clicking “Select Existing Condition from Library”.

There are a few options when you go with library conditions. They include:

• Simple conditions

• Compound conditions

• Time and date conditions

If you want to see what is available by default, or configure additional simple or compound conditions, you can browse to them via: Policy → Policy Elements → Conditions → Authorization.

Time and date conditions are available in: Policy → Policy Elements → Conditions → Common.

Simple conditions are the same types of conditions you’re selecting in Attribute/Value. They are just preconfigured in the policy library and given names the administrator may find useful.

Compound conditions are commonly used in authorization rules as they provide a nice short way of making authorization rules specific. They have multiple simple conditions in them to allow us to shorten our authorization rules.²

In our case here, we want to specify that the authorization rule is used for wireless 802.1x sessions by using the “Wireless_802.1x” compound condition. There are also a couple of other conditions added to handle AD group matching and EAP type.

If we dig into the Wireless_802.1x authorization compound condition, we can see that it has its own two subconditions. One is that its used RADIUS Service-Type is framed, which is typical for 802.1x authentication. We can also see that the RADIUS NAS-Port-Type is IEEE 802.11.

This allows us to be more specific quickly and easily in our AuthZ rules without as many specific lines of conditions in each rule we write.

After selecting those conditions our rule looks like this.

But we’re not done yet since we’ve configured some conditions in a rule; we still need the “then” side of an AuthZ rule. In our basic policy, let’s start out by permitting the wireless domain users to get on the network on the default VLAN the WLC WLAN is configured for and select “PermitAccess” under the “Standard” profiles menu.

This will return a simple Access-Accept RADIUS message to the WLC. With this policy we’re validating that the users are using 802.1x, wireless networking, they’re using PEAP as their EAP type, and they’re members of domain users. To conform to best practices we also added a “domain computers” policy in case the endpoints are configured for machine authentication. The end result of the policy is the following.

Like we said earlier, it is critical to identify the media with which a device is connecting because that media will have different options in what kind of permissions you’re applying to that user session. As you can see, wireless, wired, and VPN have a variety of different options. You want to be sure you’re applying the correct result to the correct media so that the user gets the correct permissions you’re looking to apply.

Permissions in our case are found: Policy → Policy Elements → Results → Authorization → Standard Profiles.

Each profile allows you to set what results are to be passed back from ISE to the NAD. You can set a variety of permissions per authorization profile, not just one. An example of that may be that you want to override both the VLAN and the ACL, and that is definitely allowed. When you go into an authorization profile, you can see that there are four sections:

• The top has Name, Description, Type (accept or reject), and service template.³

• Common tasks: These are check boxes for various settings you may push.

• Advanced Attitudes Settings: These are menu-driven override settings determined by Cisco to not be “Common.”⁴

• Attributes details: This is a list of the exact RADIUS attributes and variables being sent to the NAD.

For wired implementations the most commonly deployed overrides are as follows:

• Downloadable ACL

• VLAN

• Voice domain

• Session timeout

• Web authentication (central web authentication (CWA))

Downloadable ACLs are a pretty sweet feature ISE provides to us. A downloadable ACL is an ACL configured in ISE that is sent down the specific switchport that the user is on. This means if you don’t have to configure this ACL on all your switches, and when you want to make an update to the ACL, you only have to update it in ISE.⁵

dACLs are configured in the menu: Policy → Policy Elements → Results → Authorization → Downloadable ACLs.

When you configure them for wired access, there are a few things to think about:

• They support extended named ACL IOS syntax, including source port, destination port, and IP host/subnet.

• The source address of the ACL must be “any.”

• They do not support some operators including the following: time range and log.

This leaves you loads of flexibility; if you want to send a result down to a client that prevents a client from getting to a specific subnet, the ACL configuration is really straightforward. Let’s take a look at a really common dACL we use.

The ACL, when applied to a client session, does the following:

• Permits Bootstrap Protocol (BOOTP)/DHCP to function so the client can get an IP address

• Permits DNS so the client can look up DNS names

• Denies all access to RFC1918 networks

• Permits anything else

For users who don’t have public IP space in their local area network (LAN) (which is frankly still pretty common) this restricts the device with this ACL from connecting to anything internally other than DHCP and DNS and allows them to access the internet.

Another popular dACL looks like this.

Here the dACL is doing the following:

• Permits the client to obtain an IP address

• Denies all other traffic

In the case where you want to deny access to devices on the wired network, but still obtain profiling information about a device I find this to be a really useful dACL. Obtaining DHCP information provides you information about the device’s operating system (OS) and potentially its manufacturer and this could be useful in applying appropriate policy. I often use this ACL instead of simply denying network access to a device that otherwise doesn’t match our policy.⁶

Using them in an AuthZ rule is as simple as referencing the dACL you created in a standard authorization profile.

Frankly, as you create dACLs in your environment we encourage you to get creative as appropriate. Use of dACLs provides you a boatload of flexibility and functionality in wired enforcement.⁷

You’ll also notice that there is a dACL syntax checker; we highly recommend you use this every time before you click Save on your dACL. If you have a syntax error in your dACL, the authentication on the port will fail when a bad ACL is downloaded by the switch. This can be very difficult to troubleshoot.⁸

If dACLs don’t work for you and you have specific VLANs you need specific users or devices on, you can absolutely override the VLAN and set the VLAN of these sessions. There are a few things to note about doing VLAN overrides:

• You can override the VLAN ID (number) or the VLAN name. This is really important because you have a specific VLAN, say for printers, you specify that you want printers on the VLAN named “Printer” and the specific number could be different for every switch or site.⁹

• You cannot override the VLAN to the VLAN that is configured on the port as the voice VLAN. This is not supported.

• When you perform a VLAN override, the running configuration will show the original VLAN configured. This is because the configuration is not changed but the switch functionality is. If you execute “show interface gig 1/0/1 switchport” or “show authentication session interface gig 1/0/1,” you will see the VLAN ISE has configured while the running configuration has not changed.

• You need to take care when performing VLAN overrides as a device is profiled that it’s given a chance to get the IP on the VLAN it’s assigned. Let’s take the example of a policy where printers are assigned to a specific printer VLAN while everything else is left on the port’s default VLAN. When you plug in a new DHCP printer to the network before ISE has a chance to establish any profiling details on the device, it will be assigned to the default VLAN. Once ISE processes the device’s profiling information, ISE will send a CoA to the switch and ask the device to reauthenticate the MAC address (presumably with MAB). The switchport will reauthenticate and be assigned a different VLAN but the printer won’t know that it needs to obtain a new IP address because it’s on a different subnet. The printer will either have to have its port disconnected and reconnected or need to be rebooted so that it requests a new IP on the correct subnet.

Configuring a VLAN override is also done in an authorization profile.

When this authorization result is applied to an AuthZ rule, the device is set on the VLAN named “Printer.”¹⁰

The next common wired result is the “voice domain permission.” This permission is set so that the MAC address of the phone that is assigned the AuthZ result is put on the voice VLAN. In this configuration you’ll notice that ISE does not set the specific VLAN ID or name that should be used for voice. In this case the switch allows the phone on the VLAN the switchport has configured for voice. This is important to remember because in configurations where voice VLAN is used for E911 or the like, ISE remains independent from any of that functionality. Have the voice guys set the voice VLAN they’d like and we can just allow their phones on that VLAN they’d like. The default Cisco IP Phone rule looks like this.

Session timeout is a fairly popular option that needs to be used carefully.¹¹ It is used to determine how long a device may remain authenticated on a switchport before it must perform authentication again. The default is that session does not time out and once a device is authorized it may remain there until the device disconnects, switch reboots, or a CoA is issued for the device.

Session timeout is configured in seconds and the default value when timeout is enabled is 1800 s. If you wish to allow the device to remain connected during the reauthentication, then select “RADIUS-Request.” If you would prefer the device to be disconnected while reauthentication is occurring, select “Default.”

Lastly on wired AuthZ results, a popular and common result is CWA. There are a few different types of web authentication that provide for a few different functions:

• CWA: Standard web authentication user login

• Device Registration: Registering the MAC to an identity group

• Native Supplicant Provisioning: NSP BYOD

• Posture Discovery: Provisioning of posture agent and discovering an endpoint’s posture state

• MDM: Mobile device management onboarding

In our example we’ll be focused on the standard CWA. Applying a CWA result for a session has a few requirements:

• You must configure a dACL to restrict what a device may access before authentication completes. This typically restricts access of the endpoint to only resources required to actually connect to the website to do the login.

• You must configure the web portal they will use to log in.

• You must configure a redirect ACL on the switch that governs the traffic that is redirected to the ISE node. Typically this is only HTTP or HTTPS traffic not destined to the ISE PSN.

Let’s look at the dACL first. The device needs to be able to do the following to perform a web authentication:

1. Obtain an IP address via DHCP.

2. Resolve hostnames via DNS (specifically the hostname of the ISE policy nodes they will be using to log in).

3. Connect to the web server on the ISE policy nodes that hosts the web authentication pages. This web server runs on port 8443. In the case of our example our PSNs are 192.168.254.133 and 134.

Next we’ll select the web page that we’ll be assigning to the client. In our case we’ll be using the default sponsored guest Webauth page. If you wanted a customized page, you’d select it in the Value drop down.

Lastly for CWA, you need to have the redirect ACL set correctly. That is the “ACL” setting in the Web Redirection setting in the AuthZ profile. The redirect ACL is an extended named ACL configured in the switch that governs what traffic is redirected to the web authentication website. The ACL in our case works in reverse of what we’re used to. A deny statement will prevent a packet from being redirected, and a permit statement will allow the switch to redirect a session to the ISE server.

Looking at the webauth ACL, we are excluding all traffic we need for web authentication to occur properly, and with a permit any at the end, any other traffic may be subject to web authentication redirection.

For wireless access we can easily provide similar functionality as wire sessions on Cisco AirOS but with slightly different syntax. The different syntax is required simply because wireless controllers running the Cisco AirOS run differently than Cisco IOS switches.¹² The following are common authorization policy results used on wireless infrastructure:

• Airspace ACL

• Airspace interface

• Quality of Service (QoS) profile

• Web authentication (CWA)

• Session timeout

Airspace ACL is an ACL configured on the WLC. The ACL is configured statically on the WLC and simply referenced by the ISE policy.

Without getting into the details of the functions of the airspace ACL there are a few things that are important to remember about them:

1. They are stateless.

2. They impact traffic bi-directionally.

3. They have scalability limits to 64 rules.

Applying the airspace ACL via ISE to a user session applies the ACL to just that user session. It does not affect other user sessions on the same VLAN.

Setting this attribute is simple. Select the Airspace ACL Name common task, and type on the name of the ACL. Keep in mind that if you misspell the ACL name, the user authentication will fail.

Like overriding a VLAN on a wired LAN, the same functionality is available for override on a Cisco WLC but instead of overriding the VLAN ID you will be using the airspace interface override feature. Like using a VLAN name rather than ID in case the VLAN ID is different between switches, if you have multiple WLCs, you may have multiple VLANs associated the different controllers. If you have configured the airspace interface the same between your different WLCs, you can have different VLANs associated to each WLC potentially.

On the WLC here is where you may configure each airspace interface.

Inside ISE the override is actually configured as an advanced task. You need to browse the tasks Airspace → Airspace Interface Name. Then you may manually input the name of the airspace interface you’d like assigned to the session.

While typically on wired networks there are very limited use cases for differentiated QoS functionality, on wireless differentiated QoS configuration is much more common. Use cases where you’d potentially override QoS features include:

• Wishing to limit the number of WLANs deployed and configure per device QoS profiles. Giving wireless phones Platinum QoS while maintaining Silver QoS profiles for standard PCs.

• Configuring lower QoS profile levels for nonbusiness critical users. When you have a WLAN with mix of users, some users may be provided Bronze QoS profiles because they are less critical for business.

Like airspace interfaces, airspace QoS level is also an advanced attribute. Simply browse through Airspace → Airspace-QoS-Level and then assign the QoS profile you’d like assigned to the session.

Wireless CWA is a really common implementation configuration when you’re configuring ISE services because CWA is used in almost every guest or BYOD or posture deployment. It’s configured very similar to how it’s configured in a wired switch environment with the difference being how the ACLs are implemented. First, because we’re implementing this on a WLC there is no dACL to configure. You only need to configure an airspace ACL that will both provide redirect functionality and also restrict network access while prior to CWA authentication.

In this case we’ve specified “ACL-Redirect” as the ACL governing this CWA page and because it’s a guest CWA redirect we need to allow only the ports and protocols that will enable a client to connect to the ISE PSN (172.19.110.164): DHCP, DNS, and the port the ISE web server servers CWA guest pages (8443).¹³

Lastly on the wireless common authorization results is session timeout. Even though we’ll cover this we don’t recommend you implement it because mobile clients naturally reauthenticate with much greater frequency than wired clients; forcing them to authenticate every few hours is often pointless since their sessions don’t last that long anyway. If you have a specific use case where you require sessions to not last more than X seconds, select the reauthenticate button under common tasks and enter a value in seconds. If you are going to select a session timeout, then you should set a value that is longer than the period you believe a client should be working.¹⁴

Last, but certainly not the least, important medium for authorization results is VPN. With ASA VPN there are a few common results we use to enforce network access policy:

• Downloadable ACL

• Group policy

Downloadable ACL is really popular because it works very similar to the wired dACL results we talked about a few pages ago. These allow you to apply an ACL directly to the user’s VPN session without having to necessarily have the ACL configured on the ASA. The main difference in configuring the ACL for ASA implementation versus IOS is that ASA by default don’t use wild card masks; standard netmasks are used. For those who have trouble with wildcard syntax this is often a welcome reprieve. In the next example we permit DNS, deny access to 10.0.0.0/8, and then permit all traffic.

If you are inclined to use wildcard network masks in your dACLs with an ASA, the ASA will allow wild card masks but they have to be explicitly permitted with the following command:

Without that the ASA will attempt to auto-detect when a wildcard is used, but this may not be effective depending on what mask is used specifically.

The other common authorization result in ASA is the group policy. When you’re looking for maximum flexibility in manipulating your VPN users, the group policy is the gold standard in customization. With group policy you can manipulate the following:

• Split tunneling

• Split DNS

• Static VPN filters

• Statically assigning a VLAN ID

• Possible allowed VPN tunnel protocols

• Session timeouts

• Proxy settings

And more.¹⁵ To configure some of these features the first thing you need is to create a group policy on your ASA:

Then specify the group policy in the “ASA VPN” field under common tasks as shown in the screen shot.

This result will assign that group policy to your VPN user who is authenticating through your ISE.

So that is the mechanics of writing basic ISE AuthZ rules. The real challenge of creating an AuthZ policy is not just the simple rules, but how to create a ruleset that works cohesively without having incorrectly matching rules.

For a new user of ISE, authentication rules pose a design challenge that we hope to help with over the course of the next few pages. There is a huge amount of flexibility offed by ISE in deploying network authorization. That’s nice when you get used to it, but during initial deployments the level of flexibility can be overwhelming. As we break down writing AuthZ rules, we need to think about what we really care about in a user session, identify the major components of what matter to our policy, and apply them in a sensible order.

Well-written ISE AuthZ rules have a few components. They identify what media was used to authenticate (wired/wireless/VPN), what authentication method was used (dot1x, MAB, PAP for VPN), and the directory group membership for a user that you’re looking to authorize. Additionally, you’d want to specify any other pertinent information that can be useful in differentiating a specific authentication from another. That would be things like EAP method or perhaps a specific location:

• Corp

• BYOD

• Guest

• Profiling

• Phones

By default ISE AuthZ rules are read and applied in a first match manner. Meaning that when a request comes in, each rule is evaluated top down. Once an AuthZ rule is found that contains conditions that exist in the authorization request, processing is stopped and the result is sent to the NAD, a log entry is created, and accounting is started. For this reason it’s important that when you create your authorization profiles, you ensure that they are specific enough that you’re confident you won’t be applying incorrect results to an authorization request.

A few common examples of these and strategies to avoid them include:

• It’s possible to accidentally match the results for domain users when a guest username overlapped with a username that exists in AD. This is more common when you’re using common names such as “msmith” that could match any number of people in a large environment. Looking at the AuthZ policy below, if a guest user happens to have the same username as a domain user, the AuthZ rule for corporate access would be matched.

• Solution: Use the RADIUS called station ID to match the SSID name for guest user authorizations along with specific compound conditions around how authentication should happen, or derive the guest username from their email. The example below validates the methodologies of the corporate user auth, and the guest user, and what SSID the guest user is using. More on this in Chapter 9.

• Matching a domain PC authorization rule with a nondomain mobile device. This is very common when you neglect to specify the authentication methodology required to determine if the device is corporate owned. In our example here we have AuthZ rules that would cause our EAP-TLS authenticated corporate users to also match the BYODAccess permission because we have nothing that specifically would exclude them from matching that rule. More on this in Chapters 12 and 13.

• Solution: Ensure you’re specifying the authentication methodology as specifically as you can. For example, corporate PCs should be authenticating with certificates while mobile phones should be authenticating with username/passwords; you should specify the authentication method as x509 for corporate devices. If BYOD devices also use certificates, be sure to identify which CA was used to issue the certificate to ensure you’re identifying the device correctly. In our case below, we’re specifying which CA is issuing our certificates and this allows us to determine the correct authorization profile to use per device type. More on this later in Chapters 12 and 13.

• Using a profile that matches only on OUI instead of matching another authorization profile later on. Some profiles, for better or worse, may be matched only via OUI. These are useful for things like printers (HP or Xerox) and may be required to use if DHCP or Simple Network Management Protocol (SNMP) can’t be assured for higher profiling fidelity. So you’re using these profiles to set your HP printers on the correct printer VLAN. If you’re not careful, it may be possible for HP corporate laptops to match this profile if you fail to specify MAB as required for printer/profiling policy. In the example below, if a PC has an HP OUI, it’s possible to match the printer profile even if it authenticates with dot1x because the HP device profile rule is above the dot1x ruleset.

• Solution: Ensure you have robust profiling information available including DHCP. Profiling policies should typically be below corporate dot1x authorization policies as the dot1x policies may be more specific and more easily matched. Also because each media provides for different methodologies for enforcement, you should create authorization rules and results for each potential use case you’re looking to apply. Looking at the policy below, this issue would not be encountered because both the printer rule is below the dot1x rule and the printer rule requires MAB as part of its conditions.¹⁶

---

¹ Notice that there is a Boolean operator available there. The conditions by default have an “AND” operator on them all, but it’s possible to use the “OR” operator, but it is not on by default (you won’t use OR operators very often).

² Nearly all of the authorization rules we have/will write include a compound condition specifying what media is being used to authenticate (wired vs. wireless) and what authentication methodology they’re using (MAB vs. dot1x). We highly recommend using these compound conditions heavily in your deployments.

³ We’re not going to go over service templates. Nothing against them per se but they’re not commonly used.

⁴ Don’t be afraid of using these. If you feel like one works for you deployment, you should definitely give it a shot.

⁵ Remember that a dACL is applied only when a user is authorized. If you update a dACL in ISE, the update will not be pushed down. You will have to wait for clients to reauthenticate, have to disconnect them at the NAD (shut/no shut), or need to issue them a CoA to force them to reauthenticate.

⁶ One thing that makes some people crazy is that while we’re denying the device from basically any network resource and typically I’d call this a failed authentication, from ISE’s perspective the authentication will be successful and we’re just giving it a result that denies it almost complete network access and the log entry in ISE will be green, rather than red, for a truly failed AuthC or AuthZ.

⁷ dACLs are applied on the switchport in hardware generally so the length of the dACL is dependent on the hardware resources available on the switch platform and some platforms such as the Cat3750 allow you to adjust how ternary content-addressable memory (TCAM) resources are allocated. In those cases it’s recommended you allocate more resources to security where possible (run “sdm prefer access” from config mode).

⁸ If you do have to troubleshoot this, we recommend starting with “debug radius” on the switch command-line interface (CLI) and the culprit should show itself quickly.

⁹ If you’re doing VLAN override, it’s highly recommended you standardize on overriding the name rather than the ID.

¹⁰ While VLAN override is a popular feature and many users find it to be a compelling enforcement mechanism, using it does not in itself actually change resulting security design. This is because overriding a device’s VLAN does not inherently change their network access permissions. To change network access permissions with VLAN override you have to either have an ACL on an upstream router or use firewall policy based on the source subnet to apply access policy. If you’re going to be applying policy with either of those methods, then definitely VLAN override is a good choice; if you’re not otherwise applying security policy based on VLAN membership, VLAN override may not be a worthwhile effort.

¹¹ We recommend using session timeout on wireless sparingly because typically once a session is authorized, we normally want to leave it there and not mess with the user/device. Occasionally we’ll use session timeout in a monitor mode deployment to limit the amount of time a device may stay in the monitor mode result but we rarely find session timeout on wired dot1x sessions to be really useful.

¹² We’re not going to cover converged access because it is not currently broadly deployed but its syntax is comparable to the wired syntax described in this chapter.

¹³ When you’re performing other kinds of CWA redirect actions such as NSP or posture client provisioning, you’ll need to enable other TCP and User Datagram Protocol (UDP) ports (8905 and 8909) but the fundamental configuration is the same whatever you happen to be using CWA for.

¹⁴ Setting this value on wireless deployments can additionally be problematic for the scalability of your ISE cluster. If you’re forcing clients to reauthenticate at a high interval, you will be forcing ISE to consume more resources for more authentications for the same number of clients. Do use this feature sparingly.

¹⁵ Typically we use group policy when there is a need to specify the tunnel configuration (full or split) or we need to override webvpn-type settings between groups of users. Other configurations are totally fine in your group policy but some of them are less useful in actual network access enforcement. Your mileage may vary.

¹⁶ If you run into this problem in the wild, your options may be limited in dealing with it at times. Depending on the device type and amount of unique information ISE can get from it using a static endpoint identity group with MAB might make things slightly easier.