CCNP Security SISAS 300-208 Official Cert Guide (2015)

---

1. ISE Guest Services use which of the following approaches to authenticate a user?

a. Badge

b. WebAuth

c. TACACS+

d. SSH

2. The sponsor and guest portals can run on which of the following ISE personas?

a. Admin

b. MnT

c. PSN

d. a and b

e. a and c

f. b and c

3. True or False: A network administrator can customize the guest portals to run on any port greater than 1024.

a. True

b. False

4. Which default sponsor groups are available on ISE? (Select three.)

a. SponsorAllAccounts

b. SponsorADAccounts

c. SponsorAdministrator

d. SponsorGroupGrpAccounts

e. SponsorAllUsers

f. SponsorGroupOwnAccounts

5. When using Active Directory group membership as authentication and authorization for sponsors, which of the following must occur?

a. ISE must be associated to the domain.

b. The sponsor must create all guest accounts on the Active Directory Server.

c. The Active Directory identity store must be part of the identity source sequence for the sponsor portal.

d. a and b.

e. b and c.

f. a and c.

6. Under the Operations tab of the portal configuration page, which of the following items can be configured?

a. Guest Device Registration

b. Allow or Require Guest to change password

c. Guest Self-Service

d. Acceptable Use Policy frequency

e. All of the above

7. What are the three configurable options for a sponsor group?

a. Authorization Levels, Guest Roles, Time Profiles

b. Access-List, VLAN, Security Group Tag

c. Switch, Router, Firewall

d. Centralized WebAuth, Network Supplicant Provisioning, Device Registration Webpage

8. Which of the following are options for provisioning guest accounts on Cisco ISE?

a. Guest, Contractor, Consultant

b. OneDay, OneWeek, OneMonth

c. Individual, Import, Random

d. Full, Basic, InternetOnly

9. Which security policy must be enabled on the Guest WLAN/SSID to facilitate WebAuth on a Cisco WLC?

a. WPA2 with 802.1X Key Management

b. WPA2 with 802.1X and CCKM Key Management

c. MAC Filtering and RADIUS NAC

d. Open

10. To verify a guest user’s access policy on a Cisco switch, you should run which of the following commands?

a. show crypto ipsec sa

b. show aaa authorization <username> details

c. show authorization level guest interface <if_name>

d. show authentication sessions interface <if_name> details

Foundation Topics

Guest Services Overview

Cisco ISE can be flexible in its deployment, allowing network administrators to configure varying levels of access for a number of different user scenarios—such as for full-time employees and visitors alike. This section focuses on the configuration of Guest Services.

Guest Services and WebAuth

As you just learned, Guest Services is the ability for ISE to provide access to a temporary user. This temporary user could be one of the following:

Visitor—Possibly the employee’s sick child who came to work with his mother. The mother might choose to provide the user basic Internet access so the child can watch cat videos all day.

Consultant—This user might need a slightly higher level of access than the child who is visiting his parent. However, we don’t want to give the consultant an unfettered level of access. This consultant’s access level may allow her to reach a few servers that are internal to the corporate network as well as access to the Internet.

Contractor—This user, because he is acting as a temporary employee, can require the same amount of access as an employee—just for a shorter period of time.

This temporary user will be added to the network by a trusted user, such as a network administrator, an employee, or a manager—and often allowed access to a finite set of network resources based on the sample use cases given previously.

As we discuss Guest Services, it is imperative that we also discuss Web Authentication (WebAuth). WebAuth is exactly like it sounds—the end user will use a webpage to authenticate, requiring only a valid username and password. Because you typically have no control over the hardware or software capabilities of a guest’s endpoint (the device might not support 802.1X or have no supplicant), WebAuth is well suited for guest services. How must we configure ISE and the network access device (NAD) to allow for this authentication? We discuss the specifics of the authentication and authorization process later in this chapter. In the meantime, we’ll briefly discuss the theory behind the Guest Services operation and how it interacts with the WebAuth function of ISE.

When a user first authenticates to the network, ISE issues the endpoint a very restrictive authorization profile (see Figure 14-1). This restrictive level of access provides the endpoint basic network connectivity—just enough to allow it to access ISE’s Guest Services web portal. As the user attempts to browse a website, he is redirected to ISE’s WebAuth portal. This WebAuth portal allows the user to provide login credentials—a pre-provisioned username and password. After authenticating via this web portal, ISE issues a Change of Authorization (CoA) to the NAD. This CoA forces a reauthorization of the endpoint on the NAD. Via this reauthorization process, ISE deploys a different authorization profile that provides the endpoint its final level of access. This level of access—in both the length and the content—can be as permissive or restrictive as necessary, commensurate with the use cases as defined in the company’s security policy and implemented on ISE.

Figure 14-1 WebAuth process flow.

As we review the configuration of the Guest Services authorization policy later in this chapter, you will have a better understanding of what happens during these individual steps.

Portal Types

Cisco ISE has several portal types that we’ll leverage for Guest Services. The three major types of application portals as they relate to guest services are

Admin portal—Shown in Figure 14-2, it allows the network administrator to configure sponsor and guest user policy.

Figure 14-2 Admin portal.

Sponsor portal—Shown in Figure 14-3, it allows the sponsor to manage guest user accounts.

Figure 14-3 Sponsor portal.

Guest user portal—Shown in Figure 14-4, it allows the guest user to log in.

Figure 14-4 Guest user portal.

The guest user portal contains a number of elements, including these:

Guest User Login screen—This screen within the guest portal prompts the user for a username and password field (see Figure 14-4). This is the authentication piece of WebAuth.

Acceptable Use Policy screen—This screen enables administrators to provide the end user the rules, regulations, and guidelines—the Terms of Use—for using the network (see Figure 14-5). The user might get this screen upon the first login only or each time she logs in. This is configurable and can be customized with the requisite Acceptable Use Policy for your organization.

Figure 14-5 Acceptable Use Policy screen.

Required Password Change screen—This screen requires the user to change the provided password. This can help ensure that the guest user can change the password to something that she knows as well as provide the guest user the option to change the password to something more private that only she knows—as the sponsor already knows the initial password that was issued. This is enabled by default.

Allow Password Change screen—This screen allows the user to change the password if she chooses to (see Figure 14-6). If she clicks a Change Password link, this screen appears. This feature is enabled by default.

Figure 14-6 Required Password/Allow Password Change screen.

Self-Registration screen—This screen is an optional screen that lets guests to set up their own accounts (see Figures 14-7 and 14-8).

Figure 14-7 Self-Registration Login screen.

Figure 14-8 Self-Registration Creation screen.

To change whether the fields are optional, mandatory, or unused, you can go to Administration > Web Portal Management > Settings, Guest > Details Policy within the administration portal (see Figure 14-9). If you want to modify the Optional Data fields to be something more meaningful, you can do so by going to Administration > Web Portal Management > Settings > Sponsor > Language Template and choosing the appropriate language that should be modified. After selecting the appropriate language, you can now choose which sponsor portal page needs to be modified (for example, Configure Self Registration).

Figure 14-9 Self-Registration input field configuration.

Device Registration screen—This screen enables a guest user to self-register a predefined number of endpoints by MAC address (see Figure 14-10). This registration results in static population of an internal endpoint identity database. The user requires valid credentials if she wants to register devices.

Figure 14-10 Device Registration screen.

Some of these elements can be optionally leveraged to customize the guest user’s experience as she joins the network.

In a distributed ISE deployment, the Admin portal runs exclusively on the Admin node. The sponsor and guest user portals run on those policy service nodes (PSNs) that are configured to run session services.

We discuss each of these portal types in more detail as we move along through this chapter.

Configuring the Web Portal Settings

Now that we know what each portal is capable of doing, we’ll walk through the configuration of many of these portals. The default configuration of the portals will often work fine for many deployments. However, we will provide a quick overview of several of the more common configuration options in case you choose to customize your deployment to match your company’s security policy.

The base configuration location to change the General Web Portal Settings within ISE is Administration > Web Portal Management > Settings > General. Expanding the General folder, you will see options for Portal Theme, Ports, and Purge (see Figure 14-11). We’ll be focusing mainly on the Ports configuration at this time.

Figure 14-11 General web portal settings.

Port Numbers

As we discussed previously, ISE provides a number of portals to administrators, sponsors, and users alike, and many of these portals are central to the Guest Services Function. Starting with the base configuration location for the General Web Portal Settings, you will see an option for Ports(see Figure 14-12). These port settings enable you to modify the HTTPS ports that are used to access each portal on ISE. By default, these ports are all port 8443—except the Blacklist portal (which is port 8444). To change the port for a particular portal, simply change the port within the box to a value between 8000 and 8999 and then click Save.

Figure 14-12 General Web Portal Settings – Ports.

Depending on your corporate security policy, you might choose to allow certain ports through your network by default or choose to block access to these ports from certain users or devices. By modifying the HTTPS port on which these portals reside, you have a greater amount of flexibility to provide certain users access to certain ports and portals while denying access to other users.

Again, the default configuration for these port settings will often work fine for many deployments.

Interfaces

While still under the Ports settings under the General Web Portal Settings (refer to Figure 14-12), you will also notice that you can enable or disable access to the individual portals on certain interfaces of the PSNs. Depending on the size and configuration of your ISE deployment, you can choose to allow access to the various portals on a number of interfaces. By enabling the portal on more interfaces, this can help you as you can now distribute the load across multiple interfaces.

From a security standpoint, for similar reasons to changing the HTTPS ports where the portals are hosted, you might choose to host a certain portal on a specific physical interface. For instance, you might elect to allow access to the sponsor portal out-of-band from the rest of your network. This would enable you to isolate the creation and management of guest accounts to computers on a management network.

Friendly Names

The Friendly Names configuration—again, still on the Ports configuration screen of the General Web Portal Settings (refer to Figure 14-12)—allows the administrator to simplify access to certain portals. As a sponsor, you will need to periodically access the sponsor portal to create guest user accounts. To make this account creation webpage easier to remember, you can configure a friendly name.

If you want to configure a Friendly Name for your sponsor portal, you can check the box beside Default Sponsor Portal FQDN and fill in the text box with the appropriate FQDN. For instance, a few good names for a sponsor portal might be sponsor.domain.com or guestaccounts.domain.com. This FQDN must be added to the relevant domain name service (DNS) servers for your organization, pointing to the appropriate interface Internet Protocol (IP) address(es) that are configured for the sponsor portal access. Also, because the sponsor portals are provided over HTTPS and leverage a X.509 certificate to authenticate the ISE portal server, it is imperative that you add the FQDN to the Subject Alternative Name of the portal’s X.509 certificate to minimize security warning pop-ups on your browser. Otherwise, without a properly constructed X.509 certificate by a trusted certificate authority (local or well-known), you can continually get untrusted server warnings as you access the sponsor and other ISE portals.

Besides the sponsor portal, you can also enable the friendly name for the My Devices Portal of ISE. End users can manage their registered devices via this My Devices Portal. For the lay user, it can be difficult to remember a long URL. If the user has just lost his endpoint or had it stolen, he might need to browse to the portal via a kiosk or a co-worker’s computer. An easy-to-remember URL will enable him to more quickly report his device as lost or stolen and minimize the risk of lost corporate intellectual property. A few examples of a My Devices FQDN would be mydevices.domain.com or byod.domain.com. The MyDevices portal is not one of the three portals required by Guest Services but is provided here for completeness.

The default URLs to access the common portals are listed in Table 14-2.

Table 14-2 Default URLs to Access the Common Portals

Configuring the Sponsor Portal Policies

ISE provides a great deal of flexibility in determining who can be a sponsor of guest user accounts. As an ISE administrator, you can define which users, if any, on your network can create a guest user account. The users given the privilege of creating guest accounts will be referred to assponsors. Depending on your corporate security policy, you can allow only certain users to create accounts for guests or can allow all full-time employees to create the guest accounts. As we’ll discuss shortly, the level of access given to a sponsor can vary depending on any number of factors.

To configure the sponsor portal policies, start at Administration > Web Portal Management > Settings > Sponsor. Expanding the Sponsor folder, you will see Authentication Source. This authentication source is an identity source sequence that ISE uses to authenticate sponsors as they attempt to log in. To configure the identity source sequence, go to Administration > Identity Management > Identity Source Sequences. You can add a new identity source sequence or modify the existing Sponsor_Portal_Sequence (see Figure 14-13). Any sponsor that will be creating guest users must be authenticated using one of the identity stores within the chosen identity source sequence (i.e., Sponsor_Portal_Sequence). For more information or to review identity source sequences, please refer to Chapter 9, “Initial Configuration of Cisco ISE.”

Figure 14-13 Sponsor_Portal_Sequence.

Sponsor Types

Sponsors can have varying levels of access, or capabilities, when it comes to creating guest users. ISE provides this flexibility in differentiating sponsors, as not all sponsors should be created equal. Earlier, we discussed that sponsors can be network administrators or full-time employees. Should all guest users created by either of these two groups of sponsors have the same level of access to network resources? Maybe, but probably not.

As a network administrator, you might have a better understanding of the level of security provided by the different guest user account types (which we’ll discuss more shortly). Furthermore a full-time employee might not be well versed on networking and might have no idea what network security even means.

To further highlight the need for different levels of sponsors, the guest accounts created by the two sponsor groups can have different purposes. A guest account created by an employee might be to allow Internet access for a day, week, or month. However, a guest account created by a network administrator might need to be semi-permanent and have a much greater level of access. For instance, a network administrator may be responsible for providing long term network access to contract employees, giving them full access to all corporate resources for a year or more. This is not a responsibility that you would normally give to just any employee. By allowing your sponsors to create guest user accounts, they are allowing, potentially, unfamiliar, dangerous people onto your network. These guest users might be innocent or they might be nefarious hackers trying to steal all your corporate secrets and sell them to a competitor. A network administrator might have a few additional resources to verify his guest users or might receive additional training to help ensure that the guest user is legit and not a criminal.

Now that we have a background as to why we need differentiation between sponsors, let’s take a look at how this is done. Within ISE, browse to Administration > Web Portal Management > Settings > Sponsor Groups (see Figure 14-14). Looking at the default configuration, you will notice that there are three different sponsor groups—SponsorAllAccounts, SponsorGroupGrpAccounts, and SponsorGroupOwnAccounts. These default groups and their associated policy provide the following sponsor access:

Figure 14-14 Sponsor groups.

SponsorAllAccounts—These sponsors can manage all guest accounts on your ISE network.

SponsorGroupGrpAccounts—These sponsors can manage only guest accounts created by sponsor users from the same sponsor group.

SponsorGroupOwnAccounts—These sponsors can manage only those guest accounts that they have created.

Opening any of these three groups, you will see that there are several tabs to configure and many useful options to consider.

General—This is the name and a brief description of the sponsor group.

Authorization Levels—This tab highlights what the sponsor can and cannot do (see Figure 14-15). For instance, a sponsor might be allowed to create random accounts, create accounts from a CSV file, send emails/SMS, and view the guests’ passwords, amongst other options.

Figure 14-15 Authorization levels.

Guest Roles—This tab shows what guest roles a sponsor can create (see Figure 14-16). These guest roles can eventually play a role in the level of access provided to the guest user. For instance, you might choose to create a guest role of Contractor (giving full access to the network on a temporary basis) or a Visitor (giving only Internet access to the guest user).

Figure 14-16 Guest roles.

Time Profiles—This tab shows the length of time that a sponsor can allocate to a guest account (see Figure 14-17). These profiles are defined via Administration > Web Portal Management > Settings > Guest > Time Profiles (see Figure 14-18). Depending on the sponsor group, you can choose which time profiles are viable options.

Figure 14-17 Time profiles.

Figure 14-18 Time profiles definition.

Mapping Groups

Now that we have defined the sponsor groups and the groups’ capabilities, we must map these groups to the sponsors who will create the guest user accounts. The manner in which this mapping happens is similar to the IF-THEN constructs we used in defining authentication and authorization policies.

To configure this sponsor-to-group mapping, go to Administration > Web Portal Management > Settings > Sponsor Group Policy (see Figure 14-19).

Figure 14-19 Sponsor group policy.

Looking at this policy, the first three rules are the default rules that are preconfigured on ISE. In each of these rules, you will see that the only condition governing the access provided to the sponsor is what ISE identity group that user is a part of. These three identity groups are also predefined on ISE. For any user to create user accounts via these first three rules, the usernames and passwords must be defined within ISE’s User Identity store at Administration > Identity Management > Identities > Users. A user can be associated to a number of user groups.

Managing a separate sponsor database on ISE for every employee could quickly become cumbersome, especially if you already have an identity management system that is centralized for your corporation. For that reason, ISE can leverage an external identity management system, such as Microsoft Active Directory, to manage the users for you. The last two sponsor group policy rules have been added to demonstrate this concept.

The first added rule, named AD HR, has no ISE identity group assigned with the rule. The condition, however, references an externally defined AD group—AD1:ExternalGroups EQUALS ise.local/Users/HR. Because these users are members of our human resources (HR) department, we want to allow HR to create and manage all guest user accounts. This results in the HR user being assigned to the sponsor group SponsorAllAccounts. As we discussed previously, this high level of access could provide HR the ability to create or delete guest user accounts for contractors or others, regardless of which employee or network administrator created the account.

The second added rule, named AD Employees, similarly does not have an ISE identity group assigned with the rule. The condition does reference an externally defined AD group: AD1:ExternalGroups EQUALS ise.local/Users/Employees. As we don’t want one employee to delete the user accounts of other employees, we have chosen to assign this group of users to the sponsor group SponsorGroupOwnAccounts. Therefore, the employee can edit or delete only those accounts that she personally created.

For these last two rules to be effective, allowing the designated employees to create the guest accounts, we’ll need to ensure that AD1 is added to the Sponsor_Portal_Sequence, as demonstrated in Figure 14-20.

Figure 14-20 Add AD1 to Sponsor_Portal_Sequence.

Guest User Types

As a sponsor creates a guest user account, the user account can be assigned to any guest role or ISE identity group, as we previously mentioned in the Sponsor Types section. These guest roles, via the configuration Administration > Web Portal Management > Settings > Guest > Guest Roles Configuration, must be assigned to one of two guest user types—Guest or ActivatedGuest. By default, every ISE identity group is assigned to the guest user type of Guest.

What is the difference between Guest and ActivatedGuest? A guest user must authenticate via the Guest Services web portal. An ActivatedGuest can choose to authenticate to the network either via Guest Services web portal or use his credentials to authenticate to the network using 802.1X.

Managing Guest Portals

As you leverage the Guests Services functionality of Cisco ISE, you might decide that you would like to customize the guest user experience, possibly adding company branding or modifying color schemes. If you want to add your own company branding, this can be done via theAdministration > Web Portal Management > Settings > General > Portal Theme.

Portal Types

If you would rather customize a portal, you can do so by modifying an existing portal or by uploading complete HTML pages that are specific to your organization. This can be done via Administration > Web Portal Management > Settings > Guest > Multi-Portal Configurations (seeFigure 14-21). As you browse to this configuration menu, you will see that there is a DefaultGuestPortal. The DefaultGuestPortal is the standard guest portal that comes predefined on ISE. You can choose to modify this guest portal or create a custom portal from scratch, modifying the configuration and pages as you wish.

Figure 14-21 Multiportal configurations.

If you elect to create a custom portal from scratch, select Add from the Multi-Portal Configurations menu. As you click Add, you will be prompted to create a default portal or device web authorization portal—with each of these options allowing the administrator to select a customization template or to upload the HTML files. If you elect to upload HTML, you will be asked to map the HTML files with the specific ISE guest portal function, such as Login, Acceptable Use Policy (AUP), and so on.

Many of the customization options for a custom guest web portal are found on the Operations tab of the portal configuration. On this tab, you can choose whether the user will receive the Acceptable Use Policy (AUP) every time he logs in, only on the first login, or never receive the AUP at all. You can also allow a guest user to change his passwords as he wants, or you might choose to force a password change after the initial login. Equally important, a portal can allow a guest user to self-provision, self-service, and do device registration. Each of these options are unique to each custom portal you create, allowing a different visual experience as well as enabling only those features that are needed for each guest user scenario.

If you create a new guest portal, you will select this new portal as part of the authorization profile that is pushed to the endpoint upon successful authentication. We discuss the configuration of guest access policy later in this chapter.

Depending on your company’s security policy, you also can choose to modify the guest user username or password policies. By going to Administration > Web Portal Management > Settings > Guest > Password Policy (see Figure 14-22) or Administration > Web Portal Management > Settings > Guest > Username Policy (see Figure 14-23) within the ISE admin portal, you will see that you can define minimum guest user password requirements or username requirements. These requirements would define the character sets and quantities of each character class that must be used in a password or username, accordingly.

Figure 14-22 Guest user password policy.

Figure 14-23 Guest user username policy.

Building Guest Authorization Policies

Before we configure guest authorization, let’s take a look at what happens during the authentication process for Guest Services (see Figure 14-24). When we look at the authentication policy on ISE, we will see that the first authentication rule configured is named MAB—using the Internal Endpoints identity store. This MAB policy is leveraged to authenticate users for Guest Services.

Figure 14-24 Authentication policy.

This MAB authentication policy is used only if one of the following conditions is met:

Wired_MAB = Radius:Service-Type = Call Check AND Radius:NAS-Port-Type = Ethernet

Wireless_MAB = Radius:Service-Type = Call Check AND Radius:NAS-Port-Type = Wireless - IEEE 802.11

Another authentication rule that deserves to be mentioned is the 802.1X authentication rule—Dot1X. The Dot1X uses the All_ID_Sources identity store. This Dot1X policy is met with either of the compound conditions:

Wired_802.1X = Radius:Service-Type = Framed AND Radius:NAS-Port-Type = Ethernet)

Wireless_802.1X = Radius:Service-Type = Framed AND Radius:NAS-Port-Type = Wireless—IEEE 802.11)

Finally, the Default authentication rule—chosen if none of the other policies match—uses the Internal Users identity store. Currently, the RA VPN policy does not have an impact on Guest Services.

As a NAD attempts to authenticate a user or an endpoint, there might be an authentication failure. With authentication, it is equally important for us to understand ISE’s behavior during an authentication failure as it is to understand an authentication success. There are several ways that an authentication failure can occur. The authentication failures that ISE can explicitly handle are

Authentication Failed—ISE received an explicit response that authentication has failed, for example due to bad credentials, a disabled user, and so on. The default course of action is reject.

User not found—No such user was found in any of the identity databases. The default course of action is reject.

Process failed—Unable to access the identity database or databases. The default course of action is to drop.

Within ISE, you have the ability to choose how to react to these authentication failures. This functionality enables you to continue to the authorization step, despite a failure during the authentication process. The possible courses of action that ISE can take in case of an authentication failure are

Reject—A reject response is sent.

Drop—No response is sent.

Continue—Cisco ISE continues with the authorization policy.

Even when you choose the Continue option, there might be restrictions on the protocol whereby Cisco ISE cannot truly continue. However, Continue is a viable option for PAP/ASCII, EAP-TLS, and MAC Authentication Bypass (MAB). For all other authentication protocols—those that cannot truly continue—an ACCESS_REJECT response is sent if there is an authentication failure or if the user or host is not found in the identity database. Otherwise, it drops the request and sends no response if the process fails. We discuss how we will leverage the authentication failures within the WebAuth process in more detail shortly.

Now that we understand the current authentication configuration on ISE, let’s take a look at WebAuth from the standpoint of the endpoint device. Because guest users can use several devices with different operating systems and capabilities, we cannot assume that all these guest users’ devices can support 802.1X. However, it is reasonable to expect that all guest devices that need network access have a web browser that can be used for authentication.

As the end user attempts to access the network, the NAD, as we configured it in Chapter 12, “Implement Wired and Wireless Authentication,” attempts to authenticate the user by trying 802.1X first and then MAB next and forwarding this information back to ISE. As the guest’s endpoint does not have an 802.1X supplicant, credentials, or configuration to authenticate to the network, the NAD’s attempts to authenticate the endpoint using 802.1X times out. The NAD then tries to authenticate the user and endpoint via MAB—the second method on the NAD’s authentication list configuration.

As we discussed in Chapter 6, “Introduction to Advanced Concepts,” and Chapter 12, MAB requires that the endpoint’s MAC address already exists in the endpoint identity store. Because this device is likely unknown to the network, this too will fail authentication. In this case, we are actually anticipating the authentication failure and will structure our authentication policy accordingly to handle this failure. To accommodate this anticipated failure and allow the authorization policy to provide the appropriate security policy, we will set the authentication failure reaction forIf user not found and If process failed to Continue (see Figure 14-25).

Figure 14-25 Changing authentication failure policies If User Not Found and If Process Failed to Continue.

Let’s walk through a play-by-play of what will happen with MAB, considering the changes we made on ISE. With the policy configured the way it is, anytime ISE attempts to authenticate an endpoint using MAB, one of two scenarios will play out:

The endpoint’s MAC address is present in the Internal Endpoints or other identity store(s)—depending on the acceptable identity stores per the MAB authentication policy.

The endpoint’s MAC address is NOT present in any of the elected endpoint identity store(s).

In the first scenario, the endpoint’s MAC address is sent as the username for the Radius:Service-Type = Call Check ACCESS_REQUEST. The endpoint can be a member of an explicit endpoint identity list, such as a printer, an IP phone, or a copier MAB list, causing the authentication to pass, moving onto the authorization policy. The resulting authorization policy for an explicit MAB authentication success can be structured to allow the printer, the IP phone, copier, or another device access to a finite list of specific resources. Therefore, the final level of access is determined by the authorization policy on ISE.

In the second scenario, the endpoint’s MAC address is still sent as the username for the Radius:Service-Type = Call Check ACCESS_REQUEST. However, the endpoint will not be found in any of the configured endpoint identity stores. By default, this would result in an immediate authentication failure and an ACCESS_REJECT. With the If user not found being changed from Reject to Continue, the endpoint will still be allowed to continue with the authorization step. It is our responsibility, by our changing If user not found to Continue, to appropriately configure the authorization policy and only allow the device an appropriate level of access. We do not want this change to open the network to any unwanted network traffic.

Ultimately, with this new configuration, anytime the MAB rule is hit, ISE will “pass” authentication and all endpoints will move onto the authorization step. Theoretically, you could choose to configure the Default authentication rule’s If user not found setting to be Continue and it could serve the same purpose as this MAB rule. However, by explicitly mentioning MAB within the authentication rules, it provides the network administrator a more granular approach to handle a larger number of scenarios.

It is a best practice to handle all expected scenarios explicitly and fail closed otherwise. For this reason, it is best to set the Default authentication rule to Deny, resulting in ACCESS_REJECT for authentication failures or user not found scenarios, dropping the authentication request if the process fails.

We’ve now established that we will always move onto the authorization step when using MAB to accomplish Guest Services. Within the authorization step, we can now differentiate those scenarios where the device was found in the endpoint identity stores and those scenarios where the device was not found. This is usually handled by appropriately managing the order of the authorization rules or by electing the conditions of the authorization rules to set apart one MAB authorization from the others.

As was the case with the authentication process, it is a best practice to handle all expected authorization scenarios explicitly and then have a default rule whereby this default rule is as secure as reasonably possible. Often, this final rule will be a RADIUS ACCESS_REJECT response, such as the DenyAccess authorization profile, that denies all traffic from the endpoint.

Figure 14-26 shows this approach. Within the authorization policy, the identity groups are provided in bold typeface. Whenever an identity group is listed, it can be accompanied with other authorization conditions or by itself. In Figure 14-26, you will see that the DRW-Endpoints will be given the authorization profile of Internet_Only AND GUEST. The only condition present in this authorization rule is an endpoint identity group, implying that MAB alone is being used to authenticate this endpoint. The goal of this rule is to check the identity list DRW-Endpoints and, if the endpoint’s MAC address is present, provide the endpoint with the access given in the authorization profile Internet_Only and the SGT policy given by GUEST.

Figure 14-26 Proper ordering of authorization rules for MAB successes and failures.

As we look further down the authorization policy, we will see that there is an explicit mention of Wireless_MAB and Wired_MAB in the authorization rule WebAuth, just before the Default rule. Looking at this rule, the conditions column contains Wired_MAB OR Wireless_MAB (please notice the OR keyword). This rule will take effect only if

All other rules before it don’t match.

The endpoint is using MAB to authenticate to the network (either wired or wireless).

Again, the Wired_MAB and Wireless_MAB conditions are authentication conditions that are configured as

Wired_MAB = Radius:Service-Type = Call Check AND Radius:NAS-Port-Type = Ethernet

Wireless_MAB = Radius:Service-Type = Call Check AND Radius:NAS-Port-Type = Wireless—IEEE 802.11

If either of these conditions is met, the endpoint will be granted the level of access contained in the authorization profile CWA and SGA Policy GUEST. This will provide an initial authorization that provides basic network access and allows the guest user an opportunity to authenticate via a web-based interface. We discuss these authorization profiles and how this web authentication process happens shortly.

A second option besides the one we just mentioned is to use a specific RADIUS condition within ISE designed for this process flow—Network Access:UseCase EQUALS Host Lookup. This rule implies that a MAB process is underway (that is, a host lookup has happened) and has failed to hit all previous and explicit MAB authorization rules within the authorization policy. It accomplishes exactly the same task as our original, configured rule. Depending on your company’s security policy and required use cases, your policy and Guest Services approach can take a slightly different approach yet end up with the same result. ISE is extremely flexible and can accommodate several scenarios.

Usually, the Guest Services’ failed MAB rule is placed just above the Default authorization rule. As mentioned previously, you can design your rule set, authentication and-authorization both, to allow a user to continue connecting to the network following a failed authentication and then eventually elect the Default authorization rule. This would be just one more way to accommodate Guest Services access. Again, ISE is extremely flexible and you can use several approaches to accomplish the same goal.

Please use extreme caution when having a final Default rule that does not provide a RADIUS ACCESS_REJECT response because this could provide a nefarious user access to your network that you might not completely intend.

Now that the user has been authorized to access the network, let’s take a look at what this authorization means to the endpoint and end user. As an endpoint fails to match a MAB endpoint identity group and hits the WebAuth authorization rule, the endpoint—and therefore the user—will be assigned the authorization profile CWA and SGA Security Group GUEST. Let’s first take a look at the CWA authorization profile (Figure 14-27 through Figure 14-30).

Figure 14-27 CWA authorization profile, part 1.

Figure 14-28 CWA authorization profile, part 2.

Figure 14-29 CWA authorization profile, part 3.

Figure 14-30 CWA authorization profile, part 4.

Looking at Figure 14-27, you will first notice the name and description followed by an access type of ACCESS_ACCEPT. This ACCESS_ACCEPT implies that some level of access will be provided to the endpoint. This access can be extremely open or extremely restrictive, but the result is access nonetheless.

Further down in Figure 14-27 is the Common Tasks section. This section, as you learned in earlier chapters, helps simplify the configuration for those security elements that are used often by network administrators. For the CWA authorization profile, we will leverage several of these common tasks.

The first common task we will leverage is the DACL name (see Figure 14-27). DACL, an acronym for Downloadable Access Control List, is an access list, most often used in a wired scenario, that is pushed from ISE down to the NAD. The DACL that we will push to the NAD for the CWA rule is named Pre-WebAuth. This ACL is defined on ISE via the Policy > Policy Elements > Results > Authorization > Downloadable ACLs (see Figure 14-31).

Figure 14-31 Pre-WebAuth DACL.

As the contents of this ACL continue beyond the bottom of the textbox on Figure 14-31, the complete contents of this Pre-WebAuth DACL, commented for your understanding, are shown in Example 14-1:

Example 14-1 Pre-WebAuth DACL