CCNP Security SISAS 300-208 Official Cert Guide (2015)
Part V: Advanced Secure Network Access
Chapter 17. Bring Your Own Device
This chapter covers the following exam topics:
Implement BYOD access
Describe elements of a BYOD policy
Device registration
My Devices portal
Describe supplicant provisioning
Back in January 2007, Steve Jobs made a world-altering announcement when he introduced a brand-new device called the iPhone and suggested that Apple was shooting for 1% of the mobile device market. The device had a multitouch screen interface, boasted a “real browser” instead of the cut-down versions that had been used on mobile devices up to that point, and arguably changed the game for the experience that users expected from their mobile devices from that point on. In January 2010, the iPad was released. In June of that same year, Aaron Woland was at Cisco Live in Las Vegas presenting a session on network access control (NAC).
In that NAC session, Mr. Woland asked the audience members a question: Which of their companies would allow users to bring in iPhones and iPad-type devices and connect to the corporate network for purposes of doing work from those devices? There were about 600 attendees in the room, and the response was nearly 90% “no-way” and only 10% “yes.”
At that same conference, Cisco announced the CIUS, which was designed to be a “corporate tablet”—a device to provide that wonderful multitouch user experience along with the security and assurance that IT departments required. Fast-forward 18 months, and Cisco announced the end-of-sale of the CIUS due to lack of adoption.
In June 2012, just two short years later, when Aaron asked the same question about allowing personal devices, the result was 90% affirmative and only 10% said their organizations would not allow personal devices. What a difference two years can make! Bring your own device (BYOD) has become an absolute reality.
As shown in Figure 17-1, we are moving into an era of BYOD, choose your own device (CYOD), and even into a bring your own app (BYOA) type of model.
Figure 17-1 BYOD timeline.
Employees are demanding the use of the devices that make them most productive, with native applications running on those platforms that provide the user experience they are used to and love. This introduces a whole new paradigm for security, requiring the identification of the user, the device, the location of the user, and so much more.
“Do I Know This Already?” Quiz
The “Do I Know This Already?” quiz enables you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 17-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes.”
Table 17-1 “Do I Know This Already?” Section-to-Question Mapping
Caution
The goal of self-assessment is to gauge your mastery of the topics in this chapter. If you do not know the answer to a question or are only partially sure of the answer, you should mark that question as wrong for purposes of the self-assessment. Giving yourself credit for an answer you correctly guess skews your self-assessment results and might provide you with a false sense of security.
1. What is the process of onboarding as it relates to BYOD?
a. It’s a form of torture used in military interrogations.
b. It prepares an endpoint for network access with supplicant configuration, and possibly even certificate provisioning.
c. It’s the process in which an IT department will prestage an endpoint for corporate use before issuing the endpoint to the end user.
d. It prepares an endpoint for network access by preconfiguring an installation package that the end user runs with administrator privilege to configure the endpoint.
2. With a single-SSID model for BYOD onboarding, how does the supplicant begin using its new certificate-based credentials?
a. The endpoint will continue to use the initial credentials until the next reauthentication interval.
b. ISE will send a CoA-DM, causing a new authentication.
c. ISE will send a CoA-Reauth, causing a new authentication.
d. The endpoint will continue to use the initial credentials until the endpoint is deassociated from the network and reassociates.
3. With dual-SSID onboarding, what stops a guest user from receiving a certificate and a supplicant profile?
a. It is hard-coded in ISE to not permit a guest user to enter the provisioning flow.
b. It’s a configurable option, so nothing prevents guests from receiving the certificate and supplicant profile.
c. It’s a configurable option based on the authorization result given to the user.
d. It’s a configurable option in the client provisioning policies to permit guests to enter the provisioning flow.
4. The same ACL can be used for all endpoints to be onboarded. However, the security of the ACL needs to be relaxed for Androids. What is that reason?
a. Google just feels that it is so special, so Androids require special access to keep up.
b. Androids require access to the local app store in ISE.
c. Because Android is inherently an insecure operating system, it therefore needs a less secure ACL.
d. Androids require access to their app store to download and execute Cisco’s Network Setup Assistant APP.
5. What are an ISE admin’s options for dealing with endpoints that are not supported by the BYOD onboarding process?
a. Cisco ISE will reject an authentication from any endpoint that cannot go through the onboarding process.
b. The admin has configurable choices to deny access to any nonconfigured endpoint that reaches the supplicant provisioning flow or to leave it in the current authorization state.
c. Cisco ISE will automatically permit access to any device that can’t be onboarded.
d. After the BYOD onboarding flow is enabled, every device must be onboarded. There are custom templates to be able to push profiles to any device that is not natively supported.
6. From where does an iOS-based device download the iOS Network Setup Assistant?
a. From the Apple App Store.
b. iOS uses the native OTA functionality.
c. From ISE directly.
d. From the Cisco App Store.
7. True or False? The ISE admin may log in to the MyDevices portal to manage all the registered devices.
a. True
b. False
8. Which of following lists most accurately describes the portions of BYOD onboarding that can be verified within Live Log?
a. An entry will exist for the initial authentication, CoA, and final authentication.
b. An entry will exist for the initial authentication, successful launch of the NSA app, and the final authentication.
c. An entry will exist for the initial authentication, successful endpoint registration, download of the NSA app, and the final authentication.
d. An entry will exist for the initial authentication, successful endpoint registration, CoA, and the final authentication.
9. As it relates to ISE 1.2, from where do Windows and Mac OSX endpoints download their Network Setup Assistant applications?
a. Windows downloads the NSA app from the Microsoft App Store. Mac OSX uses the native OTA.
b. Neither Windows nor Mac use NSA; they use native capabilities instead.
c. Windows uses native capabilities, but the Mac will use a Java applet downloaded from the CPP.
d. Windows and Mac will use a Java applet that is downloaded from the CPP hosted on ISE.
10. At which one of the following locations does an ISE admin determine which NSP to send to a client based on any number of attributes, including operating system?
a. Policy > Onboarding
b. Policy > Client Provisioning Policy
c. Policy > Policy Elements > Results > Client Provisioning
d. Policy > BYOD
Foundation Topics
BYOD Challenges
Because user identity is typically based on a single identity credential, IT does not possess the ability to create and enforce a rigorous secure access policy. Although the user might be authorized, the device, location, time, and access medium can pose a company policy violation or even regulatory compliance violation that cannot be adequately detected or enforced.
In this chapter, you are focusing on the technical challenges of providing a secure BYOD access model. One of the most common challenges is what the industry refers to as onboarding. A user buys his new tablet or device and decides he wants to connect it to the corporate Wi-Fi and be productive on that consumer device. IT has the challenge of identifying the device as a noncorporate device and providing a limited set of access to the device.
Figure 17-2 illustrates what many companies used ISE to do, originally (back in the 1.0 days).
Figure 17-2 Old-style policy.
Then mobile device management (MDM) solutions came into play. These MDM solutions were able to manage these mobile platforms to some extent. MDM policies would ensure that devices had security enabled, such as encryption, remote wipe capabilities, screen lock (pin lock), and so forth. The MDM would even provision certificates down to the device as well as configurations for the device’s supplicant to preconfigure the device to have network access. Then ISE would provide the correct level of access for each device based on the certificate the device had.
Figure 17-3 illustrates this type of policy logic.
Figure 17-3 Using certificates to differentiate access.
MDMs typically cost money per device, and many companies were only looking for a good way to provision certificates and configure the device supplicant to use that certificate with 802.1X. The MDM cost was often prohibitive just to provision the certificate and get the device on the network. Cisco customers were looking for a much easier and cheaper way to accomplish the onboarding aspect of network access.
Onboarding Process
There are two types of onboarding that we will focus on. The first is what Cisco calls BYOD onboarding, which includes registering the device with ISE, provisioning the certificate to the device, and configuring the device’s supplicant. This is using the native supplicant within the operating system, not installing a new one.
The second is MDM onboarding, which is the process of registering the device with the Mobile Device Manager, installing the MDM client software, and enforcing the security policy on that device. The key to successful onboarding within a company is to make it self-service and not require involvement of IT.
BYOD Onboarding
As introduced in Chapter 14, “Deploying Guest Services,” ISE provides a My Devices portal that allows users to register devices and manage those devices they have registered. It’s possible for a device to simply be registered, which can provide one level of authorization, such as Internet-only access. It’s also possible for the device to go through the full-blown onboarding and provisioning process where the supplicant configuration is installed into the device along with the optional certificate (for EAP-TLS connectivity).
Regardless of your choice to use device registration only or to use the full onboarding process, there can be a single-SSID or dual-SSID approach to the onboarding, plus a wired option (of course).
Figure 17-4 depicts the dual-SSID approach, while Figure 17-5 depicts the single-SSID approach. A quick comparison of the approaches follows.
Figure 17-4 Dual-SSID flow.
Figure 17-5 Single-SSID flow.
Dual SSID
With the dual-SSID approach to onboarding:
The employee does not need to configure the supplicant on the device.
The employee authenticates to a web form.
The employee connects to the Open SSID before the provisioning process, and the employee must connect to the corporate SSID after the process (may be automated or manual).
Figure 17-4 depicts the dual-SSID approach.
Single SSID
With the single-SSID approach to onboarding:
The employee must configure the supplicant on the device to connect to the corporate SSID.
The authentication used to connect to the corporate SSID is used for Single Sign-on to the onboarding and provisioning process.
A change of authorization (CoA) is used to provide full access after the provisioning process without requiring the employee to reconnect to the network.
Figure 17-5 depicts the single-SSID approach.
Configuring NADs for Onboarding
In this section you are configuring the NADs for both dual- and single-SSID onboarding, beginning with the dual-SSID flow.
Configuring the WLC for Dual-SSID Onboarding
Dual-SSID onboarding uses an open WLAN configured for NAC RADIUS, and the security settings will only use Mac Filtering (also called Wireless MAB). This network should have been created already in Chapter 12, “Implement Wired and Wireless Authentication,” and reviewed again in Chapter 13, “Web Authentication,” but you will verify the WLC settings briefly in this section, to be certain.
Reviewing the WLAN Configuration
From the WLC GUI, edit the Open WLAN (named CP-Guest with an SSID of CiscoPress-Guest, in this example) and ensure that the RADIUS server definitions are configured for RFC 3576 (CoA).
The General tab of the WLAN should provide an SSID and profile name. CiscoPress-Guest is used in this example, as shown in Figure 17-6.
Figure 17-6 Open WLAN General tab.
Under Security > Layer 2, Layer 2 security should be set to None. The Mac Filtering check box should be enabled, as shown in Figure 17-7.
Figure 17-7 Layer 2 Security tab.
Under Security > Layer 3, Layer 3 security should be set to None, as shown in Figure 17-8.
Figure 17-8 Layer 3 Security tab.
For both the Open SSID named CiscoPress-Guest and the secured SSID named CiscoPress, you should validate that the next three items are configured correctly. Under Security > AAA Servers, the ISE Policy Service Node(s) must be selected for authentication and accounting servers, as shown in Figure 17-9.
Figure 17-9 AAA Servers Security tab.
For the Advanced tab, the following should be configured: Allow AAA Override must be enabled and NAC State should be configured for Radius NAC, as shown in Figure 17-10.
Figure 17-10 Advanced tabs.
You should also double-check that each RADIUS Server Definition under Security > AAA > RADIUS > Authentication is configured to allow CoA, which is the RFC 3576 drop-down shown in Figure 17-11.
Figure 17-11 RADIUS Authentication Servers tab.
Verifying the Required ACLs
You should have an access control list (ACL) on the switches and the wireless controllers already named ACL-WEBAUTH-REDIRECT that permit DHCP, DNS, and traffic to ISE and denies most other traffic. We added that in Chapter 14.
When onboarding with iOS, Windows, and Mac OSX, the endpoint need only communicate with ISE. iOS uses its native Over the Air (OTA) provisioning process. Windows and Mac both use a Java-based wizard that is downloaded from ISE through the devices browser. Because the communication is limited to ISE only, the ACL-WEBAUTH-REDIRECT ACL is sufficient to be repurposed for the onboarding ACL as well.
However, Android is a different story altogether. Android devices inherently do not trust apps being installed from an app store other than those trusted during the factory install; therefore, ISE would not be allowed to host the app for Android devices by default. To keep the process simple for the end user, we will have to open up the ACL to allow access to a range of addresses for Google Play.
The Google Play app store (play.google.com) is a cloud service, and the addresses it uses can change regularly. This presents a bit of a challenge for us to permit access to those ranges. Depending on the version of Cisco WLC you are implementing, the solution might be to use a DNS-snooping ACL (7.6 and newer). For the WLC versions older than 7.6, the solution is to permit a series of blocks of addresses that are known to be used by the Android Marketplace:
74.125.0.0/16
173.194.0.0/16
173.227.0.0/16
206.111.0.0/16
8.35.0.0/16
These ACLs will be used for both single- and dual-SSID onboarding.
Note
It is quite possible that these address blocks will change, or that additional blocks may need to be added. Google is very dynamic in its content location(s).
Creating the Android ACL on the Wireless LAN Controller
From the WLC GUI, under Security > Access Control Lists, add a new ACL named Android-Marketplace; then configure the ACL as the one in Figure 17-12.
Figure 17-12 Android Marketplace ACL.
Our sample ACL is permitting all traffic from the inside network to speak to the client and is allowing the client to communicate into the network for DNS and DHCP, as well as TCP traffic destined to the ISE servers. Next will be the lines that permit TCP traffic to the Android Market IP address ranges.
Adding the DNS Values to the Android ACL on the WLAN Controller
The DNS ACLs added to the WLC in version 7.6 work in an interesting way. The wireless access point (WAP) itself performs DNS snooping to see the response that is sent to the endpoint. The WAP does not have to examine all DNS requests and responses; instead, it is configured to consider only certain domain names as “interesting.”
The WAP updates the controller to allow the specific IP address through the ACL. Figure 17-13 illustrates the DNS snooping functionality.
Figure 17-13 DNS snooping ACL.
Click the blue down arrow next to the ACL, and select Add-Remove URL, as shown in Figure 17-14.
Figure 17-14 Add-Remove URL.
Adding the URL strings to this automatically puts a wildcard (*) in front of the domain. So google.com will actually match *.google.com. Entering google.* is a way to ensure the DNS snooping will match for all country codes (that is, *.google.co.uk, and so on). The two DNS names you should have for the play store (at a minimum) are google.com and android.clients.google.com. If you are outside the United States, use an asterisk (*) instead of “.com”.
Figure 17-15 shows the URL strings for the ACL.
Figure 17-15 Adding URL strings to the ACL.
Creating the ACL on the IOS-based NADs
From Global-Configuration mode, add a new extended ACL named Android-Marketplace and configure the ACL as the one in Example 17-1. This ACL allows DNS to bypass redirection, along with all four of the known common Play Store address ranges; all other web traffic will be redirected to ISE.
Example 17-1 Android-Marketplace ACL for Switches
ip access-list extended Android-Marketplace
deny udp any any eq domain
deny tcp any 74.125.0.0 0.0.255.255
deny tcp any 173.194.0.0 0.0.255.255
deny tcp any 173.227.0.0 0.0.255.255
deny tcp any 206.111.0.0 0.0.255.255
permit tcp any any eq www
permit tcp any any eq 443
ISE Configuration for Onboarding
With the NADs prepared for the onboarding process, it’s time to build the logic within the ISE Authorization Policy for both the dual- and single-SSID onboarding models.
The easier one to set up and understand first is the single-SSID model. This model assumes that in order for a user or an endpoint to be successfully admitted to the network, it must have authenticated with a certificate via EAP-TLS. If an authentication occurs with only a username and password (say, using an MSChapV2 inner method), then we know the device must not have been onboarded yet.
This way, when an employee shows up to work with her new mobile device and decides to try to connect to the corporate Wi-Fi, it prompts her for a username and password. The employee will enter her Active Directory credentials (as would be expected), and when she opens the browser on her mobile device, she will be redirected to the MyDevices portal where she can begin the onboarding process. ISE is using the single-sign-on credentials from the MSChapV2 authentication and does not need to prompt the end user for her credentials again during the onboarding. The process is simple, quick, and intuitive to most end users in the today’s world.
Dual-SSID onboarding takes a bit of a different approach. Instead of joining an SSID that is protected with 802.1X and WPA, the end user joins an open wireless network. That open network redirects the user to a Centralized Web Authentication (CWA) portal, where she will enter her credentials. If the end user is a Guest, she will not be permitted to enter the provisioning process. This is hard-coded in ISE.
However, if the end user is not a Guest user, she will be prompted to register the device and begin the onboarding process. ISE will use the credentials entered into the CWA portal for the entire process, so the end user does not have to authenticate again.
The End User Experience
To fully understand the configuration of ISE, it is best that you experience the end user experience for both single- and dual-SSID onboarding. That will aid you in your understanding of each policy that must be created and each choice you will have to make. To demonstrate multiple user experiences, the following examples use Apple iOS for one and Android for the other. However, each onboarding method could be used with any of the supported clients (iOS, Android, Mac OSX, and Windows).
Single-SSID with Apple iOS Example
For this example, you will see an Apple iOS device (an iPad) connecting to a secured network with the SSID of “CiscoPress-Corp.” This does not match the SSID you have been using so far because you have not completed the entire configuration. For this example, don’t worry about following along with your own lab. Instead, just try to see and understand the demonstrated end user experience and why it is happening.
Step 1. The user comes in with his iOS device. He opens Settings and connects to the corporate Wi-Fi, as shown in Figure 17-16.
Figure 17-16 iOS: Choose a Wi-Fi network.
Step 2. The user is prompted to input a username and password. He will use his Active Directory username and password, just like in Figure 17-17.
Figure 17-17 iOS: Enter credentials.
Step 3. If ISE’s certificate is not signed by a trusted root, the user will be prompted to accept (trust) the certificate used by ISE, as shown in Figure 17-18.
Figure 17-18 iOS: Trust the ISE certificate.
Step 4. The user will now see that he is successfully connected to the corporate network. He will not know that his access is actually limited, similar to what is shown in Figure 17-19.
Figure 17-19 iOS: Connected to corporate Wi-Fi.
Step 5. When the end user opens a web browser, he is redirected to the Client Provisioning Portal, where OTA provisioning begins.
Step 6. The first step with OTA is to send the root CA’s certificate to the iOS device to be trusted for OTA, as shown in Figure 17-20.
Figure 17-20 iOS: OTA trust the root CA.
Step 7. The user clicks Install. A warning message is displayed about the root CA being added to the list of trusted certificates on the device, along with a warning about the profile itself (if the certificate was not in the trusted store already). This is displayed in Figure 17-21.
Figure 17-21 iOS: OTA warning message.
Step 8. The Certificate and Profile to allow OTA are successfully installed. The user clicks Done, as shown in Figure 17-22.
Figure 17-22 iOS: OTA profile installed.
Step 9. The user is returned to his browser window, which displays the Device Registration page within the MyDevices portal. The device’s MAC address will be prepopulated and not editable. A description field will be displayed for the user to fill out, as shown in Figure 17-23.
Figure 17-23 iOS: Device registration page.
Step 10. When Register is clicked, the screen immediately changes to the Install Profile page, as shown in Figure 17-24.
Figure 17-24 iOS: Install the profile.
Step 11. The user is warned that clicking Install will actually install a profile. The user must click Install Now, as shown in Figure 17-25.
Figure 17-25 iOS: Redundant warning message.
Step 12. The profile begins to install, generates a certificate using SCEP, and prepares the device to be connected to the corporate SSID.
Figures 17-26 through 17-29 illustrate what the end user will see on the screen automatically. No user action is taken until the end user clicks Done in Step 13.
Figure 17-26 iOS: Gathering device information.
Figure 17-27 iOS: Generating a certificate request.
Figure 17-28 iOS: Installing the profile.
Figure 17-29 iOS: Profile is installed.
Step 13. When the profile is installed, the user must click Done. Then he is returned to his web browser where the success message is waiting for him, as shown in Figure 17-30.
Figure 17-30 iOS: Success message.
Step 14. The user is now able to browse resources on the network, which is shown in Figure 17-31.
Figure 17-31 iOS: Final network access.
That concludes the onboarding process for iOS with a single SSID. The user’s iOS device is now ready to be used regularly on the corporate network. The onboarding was a one-time thing. Future attempts to access the network will happen automatically using the downloaded certificate as authentication.
Next, we will examine the user experience with dual SSID by using an Android example.
Dual SSID with Android Example
For this example, you will see an Android device connecting to secured network with the SSID of “CiscoPress-Corp.” This does not match the SSID you have been using so far because you have not completed the entire configuration. For this example, don’t worry about following along on your own; instead just try to see and understand the demonstrated end user experience and why it is happening.
Step 1. The user comes in with her Android device. She opens Settings and connects to the Guest Wi-Fi, such as what is shown in Figure 17-32.
Figure 17-32 Android: Choose a Wi-Fi network.
Step 2. Because you have protected the Guest Wi-Fi by requiring a login (Guest or Active Directory), any attempts to browse the Internet will result in the user being redirected to the Web Authentication page, as is displayed in Figure 17-33.
Figure 17-33 Android: Web Auth portal.
Step 3. After the user logs in to the WebAuth portal, she is redirected to the device registration page and the device ID is predefined, as shown in Figure 17-34.
Figure 17-34 Android: MyDevice registration.
Step 4. When the user clicks Register, she is prompted to connect to the Android Marketplace (play.google.com) and is given the choice between the Internet and the Play Store App, which is shown in Figure 17-35.
Figure 17-35 Android: Connect to Android Marketplace.
Step 5. The user then downloads the app from the marketplace, similar to what is shown in Figure 17-36.
Figure 17-36 Android: Download the Cisco Network Setup Assistant.
Step 6. The user runs the app, and a screen like the one shown in Figure 17-37 appears, where the user must click Start.
Figure 17-37 Android: Run the NSP app.
Step 7. The NSP app downloads the profile from ISE, as shown in Figure 17-38.
Figure 17-38 Android: NSP app downloading profile.
Step 8. As displayed in Figure 17-39, the user must name the user identity certificate.
Figure 17-39 Android: Name the certificate.
Step 9. The user must now provide a name for the CA’s public certificate, as shown in Figure 17-40.
Figure 17-40 Android: Name the CA certificate.
Step 10. The NSP app automatically changes the network connection to the Corporate SSID and authenticates with the new certificate using EAP-TLS, as shown in Figure 17-41.
Figure 17-41 Android: Connect to the corporate SSID.
Step 11. As shown in Figure 17-42, the process is now complete. The user’s Android device is now ready to be used regularly on the corporate network. The onboarding was a one-time thing. Future attempts to access the network will happen automatically using the downloaded certificate as authentication.
Figure 17-42 Android: Done.
Unsupported Mobile Device—Blackberry Example
You have now seen both single-SSID and dual-SSID onboarding with supported devices. You will now see a brief example of a device that is not supported. Figures 17-43 through 17-47 show screen captures from an unsupported BlackBerry device.
Step 1. A user brings his Blackberry mobile device to work and selects the GUEST Wireless network, as shown in Figure 17-43.
Figure 17-43 Blackberry: Selecting the GUEST SSID.
Step 2. The web browser is redirected to the Web Authentication page, where the employee enters his Active Directory credentials, as shown in Figure 17-44.
Figure 17-44 Blackberry: Web authentication.
Step 3. If the Global setting is Apply Defined Authorization Policy, the user receives the message shown in Figure 17-45 and is not able to gain network access (this is covered in more detail later in the chapter).
Figure 17-45 Blackberry: Unable to register.
Step 4. If the Global setting is Allow Network Access, the user receives a notification that he can register the device through the web portal (this is covered in more detail later in the chapter).
Figure 17-46 Blackberry: Registration permitted.
Step 5. The user is now allowed to register the device and gain network access by manually configuring his supplicant, as shown in Figure 17-47.
Figure 17-47 Blackberry: Registering the BlackBerry.
Configuring ISE for Onboarding
The end user experience is designed to be very straightforward and easy for a typical user to be able to follow without any interaction with the IT department. To keep things so easy for the end user, there is quite a bit of up-front work you will need to do on the configuration side. We will cover that configuration in this section.
The first step is to create the Native Supplicant Profile (NSP) that will be sent to the end user’s device. From there, you will configure the Client Provisioning Portal so the correct profiles are sent for the correct operating systems. Next, you will configure the default action that should be taken when an unsupported device attempts to connect and cannot be provisioned (such as the BlackBerry example you just saw).
Creating the Native Supplicant Profile
The NSP is a required object for BYOD onboarding. The NSP defines the following:
The wireless SSID
The EAP type to use (PEAP or EAP-TLS)
The key size for certificates
The level of wireless security
If the profile applies to wired, wireless or both
From the ISE GUI, do the following:
Step 1. Navigate to Policy > Policy Elements > Results > Client Provisioning > Resources.
Step 2. Click Add > Agent Resources from Cisco site.
Step 3. Select the latest versions of the clients and wizards.
Step 4. Click Save.
Figure 17-48 displays the screen to download agent resources from Cisco’s site.
Figure 17-48 Agent resources from Cisco site.
Step 5. Click Add > Native Supplicant Profile.
Step 6. Name the NSP CiscoPress-TLS.
Step 7. The operating system can remain the default of ALL.
Step 8. Ensure that Wireless is checked.
Step 9. Wired is optional, so select it if you want.
Step 10. Provide the SSID for the corporate wireless network.
Step 11. Select the security level (such as WPA2).
Step 12. Select TLS for the Allowed Protocol.
Step 13. Select the certificate size (such as 2048).
Step 14. Click Submit.
Figure 17-49 shows the completed NSP using EAP-TLS.
Figure 17-49 NSP for EAP-TLS.
Configuring the Client Provisioning Policy
You configure a client provisioning policy to dictate the software and profiles that should be downloaded and installed based on the operating system of the endpoint as well as a multitude of other possible attributes.
For example, you might configure a policy for Android to be provisioned for the CORP-SSID wireless network when an employee is going through the provisioning process while configuring the CONTRACTOR-SSID for all vendors and contractors who are going through the provisioning process.
For our example, we will create one client provisioning policy per OS. Do the following:
Step 1. Navigate to Policy > Client Provisioning.
Step 2. Name a new rule iOS.
Step 3. Set the operating system as Apple iOS All.
Step 4. Set the result to be the CiscoPress-TLS supplicant profile from the drop-down.
Note
The ISE Client Provisioning Portal will automatically use the OTA provisioning process that is native to iOS for Apple iOS, so there is no need to specify that here.
Figure 17-50 is a composite image that has been cropped to display the completed client provisioning policy for iOS.
Figure 17-50 Client provisioning policy for iOS.
Step 5. Insert a new rule below the iOS rule, and name that rule Android.
Step 6. Set the operating system as Android.
Step 7. Set the result to be the CiscoPress-TLS supplicant profile from the drop-down.
Note
The ISE Client Provisioning Portal will automatically redirect Android devices to play.google.com to download the supplicant provisioning app. There is no ability to specify a different app store at this screen.
Step 8. Insert a new rule below the Android rule, and name that rule Windows.
Step 9. Set the operating system as Windows All.
Step 10. Configure the results to use the WinSPWizard and CiscoPress-TLS.
The results drop-down provides many more possibilities for Windows. This is due to the ability to also provision the NAC Agent or Web Agent to the Windows operating system. Windows will use the Cisco Supplicant Provisioning Wizard (a Java applet) to do the provisioning, and that must be specified here.
Figure 17-51 is a composite image that has been cropped to display the completed Client Provisioning Policy for Windows.
Figure 17-51 CPP results for Windows operating systems.
Step 11. Insert a new rule below the Windows rule, and name that rule Mac OS.
Step 12. Set the operating system as Mac OSX.
Step 13. Configure the results to use the MacOsXSPWizard and CiscoPress-TLS.
Like Windows, the results choices for Mac OSX provide many more possibilities. This is due to the ability to also provision the NAC Agent to the Mac OSX operating system. Mac OSX will use the Cisco Supplicant Provisioning Wizard (a Java applet) to do the provisioning, and that must be specified here.
Note
In ISE 1.2 patch 11, the Java-based applet was replaced with a native application for both Windows and Mac OSX. However, it is not relevant for the purposes of the exam, and therefore is not included in this book.
Step 14. Click Save.
Figure 17-52 is a composite image that has been cropped to show the final Client Provisioning Policy, with all four OSes configured.
Figure 17-52 Client provisioning policy.
Configuring the WebAuth
The CPP is now created, and it will be used with both dual-SSID and single-SSID provisioning. However, we must ensure that the WebAuth Portal Page is ready for the Dual SSID flow.
There is a plethora of options when it comes to Web Authentication and supplicant provisioning. For instance, you can configure different web portals based on a number of attributes available from the authentication request (such as source SSID). This way, you can enable the device registration and supplicant provisioning to occur per use case, if you so chose.
For simplicity, we will use DefaultGuestPortal for our example. Do the following:
Step 1. Navigate to Administration > Web Portal Management > Settings.
Step 2. Select Guest > Multi-Portal Configuration > DefaultGuestPortal.
Step 3. Click the Operations tab.
Step 4. Ensure the Enable Self-Provisioning Flow check box is selected.
Step 5. Click Save.
Figure 17-53 shows the portal configuration with the Enable Self-Provisioning Flow check box enabled.
Figure 17-53 Web portal configuration.
Verifying Default Unavailable Client Provisioning Policy Action
ISE 1.2.x supports iOS, Android, Windows, and Mac OSX. However, it is quite possible for an end user to attempt access with a client that is not supported by ISE NSP (such as attempting with a BlackBerry or Windows mobile device). ISE offers two options for that situation:
Allow Network Access—With this option, a user is allowed to register her device through the MyDevices Portal and gain network access without having to install and launch a native supplicant wizard. This assumes the user will have to interact and configure the supplicant in an out-of-band fashion. In other words, she must configure her supplicant herself. This option can be very attractive if the end users are capable of requesting and installing their own certificates.
Apply Defined Authorization Policy—Basically, this option leave the client in the current state, which is a state of limited access. This is also the default setting.
Figure 17-54 shows the unavailable CPP action.
Figure 17-54 Default unavailable CPP action.
Creating the Authorization Profiles
As described previously, you will create two authorization profiles. One of the authorization profiles is used for Android to accommodate a different ACL that permits Android devices to reach the Google Play Store. The second profile is used for all other applicable OSes that do not need to reach Google’s Play Store. Do the following:
Step 1. Navigate to Policy > Policy Elements > Results > Authorization > Authorization Profiles.
Step 2. Add a new authorization profile, named Android NSP.
Step 3. Select Web Redirection (CWA, DRW, MDM, NSP, CPP).
Step 4. From the drop-down, select Native Supplicant Provisioning.
Step 5. Enter the Android-Marketplace in the ACL field.
Step 6. Click Submit.
Figure 17-55 shows the completed Android NSP authorization profile.
Figure 17-55 Android NSP authorization profile.
Step 7. Add a new authorization profile, named NSP.
Step 8. Select Web Redirection (CWA, DRW, MDM, NSP, CPP).
Step 9. From the drop-down, select Native Supplicant Provisioning.
Step 10. Enter the ACL-WEBAUTH-REDIRECT in the ACL field.
Step 11. Click Submit.
Figure 17-56 shows the completed NSP authorization profile.
Figure 17-56 NSP authorization profile.
Creating the Authorization Rules for Onboarding
Now that the authorization profiles are ready, you will create two different authorization rules. The first rule is used for Android, and the second rule is used for the other devices. Do the following:
Step 1. Navigate to Policy > Authorization.
Step 2. Add a new rule, just above the default rule.
Step 3. Name the rule Android NSP.
Step 4. Set the conditions as:
Network Access:AuthenticationMethod EQUALS MSCHAPV2
AND
Session:Device-OS EQUALS Android
Step 5. Set the authorization result to be the Android NSP created earlier.
Step 6. Click Done.
Step 7. Click Save.
Figure 17-57 shows the Android NSP conditions. You optionally can save the conditions individually or together into the library for reuse in other rules.
Figure 17-57 Android NSP authorization conditions.
Step 8. Add the NSP rule for non-Android.
Step 9. Add a new rule, just above the default rule and below the Android rule.
Step 10. Name the rule NSP.
Step 11. Set the conditions as:
Network Access:AuthenticationMethod EQUALS MSCHAPV2
Step 12. Set the authorization result to be the NSP authorization profile created earlier.
Step 13. Click Done.
Step 14. Click Save.
Figure 17-58 shows the NSP condition.
Figure 17-58 NSP authorization conditions.
Creating the Authorization Rules for the EAP-TLS Authentications
You have just created two different authorization rules that will result in the onboarding of the endpoints. After these endpoints are onboarded, they will be authenticating with EAP-TLS and certificates.
You created an authorization rule in Chapter 16, “Certificate-Based Authentications,” that authorizes employees using certificates. That rule is named Employee Limited_Certificate. There is no reason this same rule cannot be used because it will certainly match any employee onboarded device that is authenticating with a certificate.
However, you are going to add a new rule that looks for certificate-based authentications and is also ensuring that the MAC address of the endpoint matches the MAC address burned into the certificate during the onboarding process. As an additional metric for the rule, it will also ensure that the endpoint has been through the BYOD registration process. This is a Cisco recommended configuration for BYOD with Cisco ISE.
From the ISE GUI, do the following:
Step 1. Navigate to Policy > Authorization.
Step 2. Add a new rule, just above the Employee SmartDevice rule.
Step 3. Name the rule Employee BYOD.
Step 4. Set the conditions as:
Network Access:AuthenticationMethod EQUALS x509_PKI
AND
CERTIFICATE:Subject Alternative Name CONTAINS Radius:Calling-Station-ID
AND
Endpoints:BYODRegistration EQUALS Yes
AND
AD1:ExternalGroups EQUALS ise.local/Users/Employees
Step 5. Set the authorization result to be Employee Limited.
Step 6. Click Done.
Step 7. Click Save.
Figure 17-59 shows the Employee BYOD conditions. As shown in that figure, you optionally can save the conditions individually or together into the library for reuse in other rules.
Figure 17-59 Employee BYOD conditions.
A composite screen shot of the authorization policy is shown in Figure 17-60.
Figure 17-60 Final authorization policy.
Configuring SCEP
ISE will act as a registration authority (RA) for the certificate enrollment and provisioning of the devices that are being onboarded. So, with ISE 1.2, ISE is not the certificate authority (CA); instead it is a “broker” of sorts that uses Simple Certificate Enrollment Protocol (SCEP) to request and provision a certificate to the client from the CA of your choice.
There are multiple CAs that could be used. The single most common CA deployed is the Microsoft Active Directory Certificate Authority. The Microsoft CA has support for SCEP and is referred to as Network Device Enrollment Services (NDES). It requires Windows 2008 R2 Enterprise or newer, and that server must be part of a domain.
The authors have worked with companies who created a new Active Directory domain with only the one server in it, just for the CA and NDES functionality to be separate from their production AD. This is not necessarily recommended—we are just using the example to show the level of flexibility you might have, if needed. For more details on the configuration of a Microsoft CA, please see Appendix B, “Configuring the Microsoft CA for BYOD.”
Some companies have a strict “no Microsoft” policy. The authors have worked with several companies that either have that policy or their AD team will not configure the CA services. Another fairly common CA to deploy for ISE is the Open Source Dogtag CA. There is also an Enterprise version of Dogtag, known as the Red Hat Enterprise CA. For more details on the configuration of a Dogtag CA, please see Appendix C, “Using the Dogtag CA for BYOD.”
Note
It’s also good to note that ISE 1.3 provides a built-in CA. However, that is not applicable to this exam and therefore is out of scope for this book.
Although not all CAs have been tested, you theoretically can use any CA of your choosing, just as long as it meets these requirements:
Must support SCEP
Must support an automated or automatic issuing of the requested certificates
Does not require a shared secret to be configured between the RA and the CA
The configuration of ISE to use the CA does not have too many steps. There is really just one setting to be made.
From the ISE GUI, do the following:
Step 1. Navigate to Administration > System > Certificates.
Step 2. Click SCEP RA Profiles.
Step 3. Click Add.
Step 4. Name the CA (our example is CP_AD_CA).
Step 5. Add the URL, such as http://ip-address-of-ca/certsrv/mscep/.
Step 6. Click Test Connectivity.
Step 7. Click Submit.
Figure 17-61 shows the completed SCEP RA profile.
Figure 17-61 Completed SCEP RA profile.
When you add a new SCEP profile to ISE, the CA’s public key will automatically be imported into the Certificate Store and the Trust for Client Authentication or Secure Syslog Services setting will be enabled. This means that for any endpoints that are provisioned a certificate from the CA will be trusted. If you choose to use CRL or OCSP, you will need to edit this certificate and set that configuration. See Chapter 16 for more details around the Certificate Store and trust and revocation settings.
Figure 17-62 shows the certificate that was automatically imported and trusted.
Figure 17-62 Automatically imported and trusted CA certificate.
Assuming the configuration on your CA was completed and accurate, your deployment is now ready to do BYOD onboarding. See Appendixes B and C for details on configuring Microsoft and Dogtag CAs, respectively. As you join the open network and authenticate or join the closed network and are directed to the onboarding process, you will experience first-hand the client experience outlined earlier in this chapter within the section titled “The End User Experience.”
BYOD Onboarding Process Detailed
Yes, this chapter is getting very long. However, it is our hope that you will find all this information useful if you ever find yourself in a spot where you need to perform any troubleshooting of this process or need to describe it as part of this certification. You have seen that the user experience is quite simple and straightforward, but the process behind the scenes is a bit more complex.
iOS Onboarding Flow
We will examine, in detail, the experience with iOS endpoints and onboarding. To do so, we are focusing on a single-SSID onboarding experience.
Phase 1: Device Registration
The first phase of the onboarding is device registration. Remember that the overall process might have a lot of steps, but the end user should have to complete only four actions, as noted in Figure 17-63. However, we will take a look at all the items that occur behind the scenes.
Step 1. The user joins the corporate SSID, and the iOS device prompts the user for credentials (Action 1 for the end user experience).
Step 2. The user enters his AD username and password (Action 2 for the end user experience).
Step 3. The EAP login request is sent to the wireless controller, which wraps the request in a RADIUS Access-Request to ISE.
Step 4. The authorization result from ISE will include a URL-Redirection to the NSP portal.
Step 5. The user opens his web browser, which is redirected to the NSP portal on ISE, displaying the device registration page with the Device ID field prepopulated with the MAC address (Action 3 for the end user experience).
Step 6. The user clicks Register (Action 4 for the end user experience), which immediately triggers three events:
Sets the BYODRegistration flag for the endpoint identity to Yes.
Adds the endpoint to the RegisteredDevices identity group.
Sends the CA’s certificate to the IOS device for it to trust for OTA.
Figure 17-63 Phase 1: Device registration.
Figure 17-63 illustrates Phase 1.
Phase 2: Device Enrollment
This phase is where the device is enrolled in the BYOD system of ISE. The device itself will get its own certificate, although the authentication will only use the user certificate that is part of Phase 3.
Step 7. ISE sends a profile service to the iOS device via OTA.
Step 8. The profile instructs iOS to generate a certificate signing request (CSR) using the unique device identifier (UDID) as the certificate’s subject and the MAC address as the subject alternative name (SAN) field:
CN=device-UDID
SAN=MAC Address
Step 9. The device CSR is sent to ISE, which uses SCEP to proxy the enrollment request to the CA.
Step 10. The CA automatically issues the certificate.
Step 11. The certificate is sent back to ISE, which sends it to the endpoint through the OTA service.
Figure 17-64 shows Phase 2.
Figure 17-64 Phase 2: Device enrollment.
Phase 3: Device Provisioning
Now that the device has a device certificate, it’s time to get a user-based certificate issued to the endpoint as well. Additionally, this is the phase where the final authentication and authorization based on the user-certificate and EAP-TLS will occur.
Step 12. The iOS device generates another CSR, using the employee’s credentials (given to iOS by ISE via the OTA service) as the certificate’s subject and the MAC address as the SAN field:
CN=Username
SAN=MAC Address
Step 13. The user CSR is sent to ISE, which uses SCEP to proxy the certificate enrollment request to the certificate authority.
Step 14. The CA automatically issues the certificate.
Step 15. The certificate is sent back to ISE, which sends it to the device through the OTA service. Included in that profile is the Wi-Fi configuration, which details the SSID and to use EAP-TLS.
Step 16. ISE sends a CoA to the NAD of the type ReAuth, which causes a new authentication.
Step 17. The endpoint will now authenticate to the corporate SSID using the certificate via EAP-TLS.
Figure 17-65 shows Phase 3.
Figure 17-65 Phase 3: Device provisioning.
Android Flow
To detail the flow of onboarding with Android, we will use the dual-SSID approach. Android is certainly capable of doing a single-SSID approach as well, but you just saw that experience with iOS. Remember that with the dual-SSID approach, the user must log in to a CWA portal. That portal is hard-coded in ISE to launch the onboarding process only if the user is not a guest user.
Phase 1: Device Registration
The first phase of the onboarding is device registration. Remember that the overall process might have a lot of steps, but the end user should have to complete only six actions in total. There are four actions in this phase, as shown in Figure 17-66. More actions are required of the end user, but that is due to the Android requirement to use an app for the onboarding, versus the native OTA with iOS.
Step 1. User joins the Open SSID (Action 1 for the end user experience).
Step 2. The WLC sends a MAC Authentication Bypass (MAB) request to ISE.
Step 3. The authorization result from ISE will include a URL-Redirection to the CWA portal.
Step 4. The user opens a browser and is redirected to the CWA portal (Action 2 for the end user experience).
Step 5. The user enters her AD username and password (Action 3 for the end user experience).
Step 6. The successful Web Auth triggers two events:
The web page changes to the NSP portal.
A CoA is sent to the WLC that includes a redirection to the NSP portal.
Step 7. The NSP portal displays the device registration page with the Device ID field prepopulated with the MAC address of the endpoint.
Step 8. The user clicks Register (Action 4 for the end user experience), which immediately triggers five events:
Sets the BYODRegistration flag for the endpoint identity to Yes.
Adds the endpoint to the RegisteredDevices identity group.
Sets the Session:Device-OS attribute to Android (this is a temporary attribute and only used for the provisioning process).
Sends a CoA to the WLC to apply the correct ACL, allowing Google Marketplace access for the Android device.
The web page sends the browser to the Google Play Store.
Figure 17-66 Phase 1: Device registration.
Figure 17-66 illustrates Phase 1 of the dual-SSID onboarding with Android.
Phase 2: Download SPW
This phase is where the end user is sent to the Google Play Store to download the NSA app. The device itself will get its own certificate, although the authentication will only use the user certificate that is part of Phase 3.
Step 9. The CoA from Phase 1 applies an ACL that permits traffic to the Google Play Store (the Android-Marketplace ACL).
Step 10. The browser was automatically sent to the Google Play Store, and the Android device prompts the user to choose the Internet browser or Play Store App to complete the request.
Step 11. The user may be prompted to log in to the Google Play Store.
Step 12. The user clicks to install the Cisco NSA app (Action 5 for the end user experience).
Figure 17-67 shows Phase 2 of the dual-SSID onboarding with Android.
Figure 17-67 Phase 2: Download NSA.
Phase 3: Device Provisioning
This final phase is where the end user runs the NSA app, which handles the CSR generation and network profile installation, in a similar fashion to what iOS devices did natively. The sixth and final end user action occurs in this phase.
Step 13. The NSA app installs, and the user runs it (Action 6 for the end user experience).
Step 14. NSA sends a discovery message to http://default-gateway/auth/discovery.
Step 15. The WLC redirects that HTTP message to the ISE NSP portal based on the URL-REDIRECT result within the authorization from ISE.
Step 16. ISE sends the Android profile based on the CiscoPress-TLS supplicant NSP to the endpoint.
Step 17. NSA generates the CSR, using the employee’s credentials as the certificate’s subject and the MAC address as the SAN field:
CN=Username
SAN=MAC Address
Step 18. The CSR is sent to ISE, which uses SCEP to proxy the certificate enrollment request to the certificate authority.
Step 19. The CA automatically issues the certificate.
Step 20. The certificate is sent back to ISE, which sends it to NSA app. Included in that profile is the Wi-Fi configuration, which details the SSID and to use EAP-TLS.
Step 21. The NSA app connects the endpoint to the corporate SSID.
Step 22. The endpoint will now authenticate to the corporate SSID using the certificate via EAP-TLS.
Figure 17-68 shows the third and final phase of the dual-SSID onboarding with Android.
Figure 17-68 Phase 3: Device provisioning.
Windows and Mac OSX Flow
Mac OSX and Windows both use a wizard to accomplish the onboarding and provisioning. It is a Java-based applet called the Cisco Native Supplicant Provisioning Wizard. The wizard takes care of triggering the CSR from the operating system and installing the supplicant profile.
Unlike the mobile operating systems, this is only a two-phase process, whereas the mobile devices required three phases. We will use the single-SSID onboarding to demonstrate this flow.
There are only five actions for the end user, in a perfect world. However, we all know this is not a perfect world. Since the initial creation of the supplicant provisioning wizards with ISE 1.1.1, security vulnerabilities in client-side Java have been under attack. In response, the security levels in the client-side Java have been tightened, making the end user experience increasingly challenging, with many security warning prompts and workarounds.
In response, Cisco has created native applications for both Mac OSX and Windows operating systems that don’t use the client-side Java. These clients became available with ISE 1.3 and were back-ported to ISE 1.2 patch 11. Neither of those versions is pertinent to this exam, which is why this book will still focus on the Java-based versions.
Phase 1: Device Registration
Phase 1 is much like the same phase within the mobile device sections. The user joins the network in the same fashion, enters his credentials, and is redirected to download a piece of software that will do the onboarding for the operating system. It’s very similar to the flows with Android, with one major difference: There is no requirement for access to an app store because the software is able to be hosted directly on ISE.
Step 1. The user joins the corporate SSID (Action 1 for the end user experience), and the Windows or Mac device prompts the user for his username and password.
Step 2. The user enters his AD username and password (Action 2 for the end user experience).
Step 3. The EAP login request is sent to the wireless controller, which wraps the request in a RADIUS Access-Request to ISE.
Step 4. The authorization result from ISE includes a URL-Redirection to the NSP portal.
Step 5. The user opens his web browser (Action 3 for the end user experience), which is redirected to the NSP portal on ISE, displaying the device registration page with the Device ID field prepopulated with the MAC address.
Step 6. The user clicks Register (Action 4 for the end user experience), which immediately triggers two events:
Sets the BYODRegistration flag for the endpoint identity to Yes.
Adds the endpoint to the RegisteredDevices identity group.
Figure 17-69 illustrates the device registration phase.
Figure 17-69 Phase 1: Device registration.
Phase 2: Device Provisioning
Phase 2 is the final phase for the Mac OSX and Windows onboarding and is much like the final phase within the Android sections. The Java applet is downloaded and executes, performing the CSR and provisioning for the endpoint. There should not be any user action.
Step 7. The Native Supplicant Provisioning Wizard is downloaded and runs.
Step 8. The user clicks Start (Action 5 for the end user experience).
Step 9. The NSP Wizard sends a discovery message to http://default-gateway/auth/discovery.
Step 10. The WLC redirects that HTTP message to the ISE NSP portal based on the URL-REDIRECT result within the authorization from ISE.
Step 11. ISE sends the NSP profile based on the CiscoPress-TLS supplicant profile to the endpoint.
Step 12. NSP Wizard generates the CSR, using the employee’s credentials as the certificate’s subject and the MAC address as the SAN field:
CN=Username
SAN=MAC Address
Step 13. The CSR is sent to ISE, which uses SCEP to proxy the certificate enrollment request to the certificate authority.
Step 14. The CA automatically issues the certificate.
Step 15. The certificate is sent back to ISE and is sent down to the NSP Wizard. Included in that profile is the Wi-Fi configuration, which details the SSID and to use EAP-TLS.
Step 16. ISE sends a CoA to the NAD of the type ReAuth, which also causes a new authentication. (If this was a dual-SSID situation, the applet would automatically connect the endpoint to the corporate SSID at this point.)
Step 17. The endpoint will now authenticate to the corporate SSID using the certificate via EAP-TLS.
Figure 17-70 illustrates the device provisioning phase.
Figure 17-70 Phase 2: Device provisioning.
Verifying BYOD Flows
In this section we will examine a few ways to verify that BYOD flows are operating successfully. This topic is covered in more depth in Chapter 22, “Troubleshooting Tools,” but this section will get you started.
There are numerous locations that an ISE admin should look to see whether something is functioning correctly. The first is Live Log, but there are also reports to examine. Plus, you can take a look in the endpoint identities database or even MyDevices portal. The MyDevices portal is covered in more detail in the “Self Management” section of this chapter.
Live Log
As described numerous times throughout this book, the first location any ISE admin should always look to verify functionality is Live Log. As it relates to single-SSID onboarding, one can see at a glance the various authentications of an endpoint and the authorization result of each.
Figure 17-71 shows a screen capture of Live Log during a single-SSID onboarding flow.
Figure 17-71 Live Log showing the single-SSID.
Examining Figure 17-71, you should see three logged events that have been pointed out. From the earliest (bottom) to the latest (top):
You see the initial authentication that uses PEAP(EAP-MSCHAPv2) for authentication and is given the NSP authorization profile. This is the authorization profile you created to redirect the user to the provisioning portal for device registration and provisioning.
The next event is a Dynamic Authorization Success message. This is the successful CoA that tells the WLC to reauthenticate the session.
Finally, you see a successful authentication that uses EAP-TLS and is assigned the Employee_Limited authorization profile.
Reports
Cisco ISE provides a number of prebuilt reports that exist under Operations > Reports. They are divided into logical groupings such as Auth Services, Deployment Status, Endpoints and Users, and Security Group Access (also called TrustSec). There is even a dedicated report to supplicant provisioning.
From the ISE GUI, do the following:
Step 1. Navigate to Operations > Reports > Endpoints and Users > Supplicant Provisioning.
Step 2. Select a time range, such as Today or Last 7 Days.
Step 3. Click Run.
Figure 17-72 shows the output of this report.
Figure 17-72 Supplicant provisioning report.
Identities
Certainly, another way to verify the onboarding is to examine the endpoint in the Endpoints database.
From the ISE GUI, do the following:
Step 1. Navigate to Administration > Identity Management > Identities > Endpoints.
Step 2. Optionally, apply a Quick Filter to make the list more manageable, as shown in Figure 17-73.
Figure 17-73 Identities > Endpoints.
Step 3. Examine the BYOD Registration Status and Portal User fields.
Figure 17-73 shows the endpoints database with a Quick Filter enabled.
MDM Onboarding
Many organizations use Mobile Device Management solutions. These solutions provide endpoint management for a plethora of devices. They help enforce specific security requirements such as endpoint encryption, PIN lock, jail-break detection, remote wipe capabilities, and more. Many MDMs will even provision supplicants and certificates to devices as part of their management package.
Typically, a user would bring in a mobile device and, to gain access to the network, she had to call the help desk to receive instructions on how to onboard the device with the MDM so she could gain access to the network. There were some significant downsides to this process, such as:
Users were required to manually connect to the MDM solution to begin the onboarding process.
There was no enforcement to help steer the user toward that solution.
An MDM license was required for every device the organization would provision and allow to have network access, which could be cost prohibitive.
However, this presented a very beneficial and strategic opportunity for Cisco and these MDM vendors. The vendors had the mobile device management capabilities, and Cisco had the onboarding, network access policy, and enforcement mechanisms.
ISE 1.2 adds the integration of many of the industry’s top MDM vendors. The list is inclusive of VMware AirWatch, Mobile Iron, Citrix ZenPrise, Good Technologies, Fiberlink, SAP Afaria, Symantec, and Tangoe—and the list continues to grow. These vendors have implemented an Application Programming Interface (API) written by Cisco to enable scalable bidirectional communication between their solution and ISE. By utilizing the same API for all vendors instead of a custom integration with each vendor, Cisco can ensure consistency and quality.
Integration Points
The API provides ISE with the ability to use MDM attributes in the authorization policies. The authorization can use a macro-level attribute stating that the device is in compliance with the MDM policy or a micro-level attributes such as jail-break status, PIN lock, or even endpoint encryption.
Table 17-2 lists the MDM attributes and what their possible values are.
Table 17-2 MDM Attributes and Values
Configuring MDM Integration
Before you can configure ISE to communicate with the MDM, ISE must trust the certificate of the MDM for the SSL-encrypted communications.
From the ISE GUI, do the following:
Step 1. Navigate to Administration > System > Certificates.
Step 2. Select Certificate Store.
Step 3. Import the certificate of the MDM as a trusted certificate.
Note
If the MDM will be provisioning certificates to endpoints with their own CAs, instead of using the BYOD onboarding with ISE and your CA, then you will also need to trust the certificate for client authentication. Additionally, you might need to import ISE’s public certificate into the MDM so the MDM will also trust ISE.
Now that the certificate is trusted, we can add the MDM Server to ISE. ISE 1.2 can be configured with the knowledge of many MDMs, but only one can be active at a time.
Step 4. Navigate to Administration > Network Resources > MDM.
Step 5. Click Add.
Step 6. Input a name for the connection to the MDM.
Step 7. Input the hostname of the server (should be DNS resolvable).
Step 8. The port should be 443, unless otherwise instructed by your MDM vendor.
Step 9. An instance name is used in some cases when the vendor is multitenant capable (such as a cloud-based MDM solution).
Step 10. Use the Administrator Name that the API will connect with to enroll all the mobile devices.
Step 11. Enter the Password for the API account.
Step 12. Add an optional description.
Step 13. Click Test Connection.
Step 14. Click Submit.
Figure 17-74 shows a sample MDM definition.
Figure 17-74 Add MDM.
Configuring MDM Onboarding Rules
Now that the MDM has been added to ISE, the dictionaries for MDM attributes have been added for use in ISE authorization policies. So it is now time to create the MDM onboarding authorization rules.
MDM onboarding rules are configured much like the ISE BYOD onboarding rules. The authorization rules need to be configured to redirect the appropriate endpoints to an onboarding portal, only this time the destination is the MDM onboarding portal.
One example of where to place an MDM onboarding policy is just below the BYOD onboarding rules, but above the rule that would permit final access. Some organizations would not want to send all devices to the MDM but would want only specific devices to be included. One such way to achieve this is to maintain a separate list of MAC addresses belonging to corporate-owned assets and add that list to an endpoint identity group. This type of methodology is commonly referred to in the industry as MAC address Management (MAM). Another option would be to use a logical profile that includes the relevant mobile device vendors and device types (that is, Apple or Android). In this second scenario, you can choose to send only mobile phones and/or tablet devices to the MDM for provisioning, allowing Windows and Mac OSX laptops to not leverage the MDM.
The example in this section will use those endpoint identity groups because it is something that the authors have seen used in production at a number of installs.
Creating the Authorization Profile
The first step is to create the authorization profile that redirects the endpoint to the MDM’s provisioning portal for onboarding.
From the ISE GUI, do the following:
Step 1. Navigate to Policy > Policy Elements > Results > Authorization.
Step 2. Select Authorization Profiles.
Step 3. Add a new authorization profile named MDM Onboard.
Step 4. The access type should be ACCESS_ACCEPT.
Step 5. Select Web Redirection.
Step 6. Select MDM Redirect.
Step 7. The Web Redirection ACL should reference an ACL that permits access to the MDM and ISE but denies access to the rest of the Internet (you might need to create a new one for use in this policy).
Step 8. Click Submit.
Figure 17-75 shows a sample authorization profile.
Figure 17-75 MDM onboard authorization profile.
Figures 17-76 and 17-77 show a sample ACL with DNS snooping.
Figure 17-76 ACL-MDM-REDIRECT.
Figure 17-77 ACL-MDM-REDIRECT URLs for DNS snooping.
Creating the Authorization Rules
The authorization results are ready for the onboarding, so now you will create an authorization rule to send devices to the MDM vendor’s provisioning portal for onboarding. As mentioned at the beginning of the “Configuring MDM Onboarding Rules” section, the placement of these rules is important. For this example, you will place the redirection rule above the Employee BYOD rule.
From the ISE GUI, do the following:
Step 1. Navigate to Policy > Authorization.
Step 2. Insert the new rule above the Employee BYOD rule.
Step 3. Name the rule MDM Onboard.
Step 4. (Optional) Select an identity group that matches your corporate assets (CorpAssets in this example).
Step 5. Add the conditions as follows:
Employees
AND
x509_PKI
AND
SAN_is_Mac
AND
Endpoints:BYODRegistration EQUALS Yes
AND
MDM:DeviceRegisterStatus EQUALS Unregistered
Step 6. Set the result to the MDM Onboard authorization profile.
Step 7. Click Done.
Figure 17-78 show the completed rule.
Figure 17-78 MDM onboard rule.
Add another rule below it that permits access to devices that are registered and meet the MDM compliance and that therefore should be provided with full access to the network.
Step 8. Navigate to Policy > Authorization.
Step 9. Click the down arrow for the MDM onboard rule and select Duplicate Below.
Step 10. Name the rule MDM Permit.
Step 11. Delete the BYODRegistration condition.
Step 12. Change the MDM:DeviceRegisterStatus to EQUALS Registered.
Step 13. Add a new condition for MDM:ComlianceStatus EQUALS Compliant:
The final condition set should look like this:
Employees
AND
x509_PKI
AND
SAN_is_Mac
AND
MDM:DeviceRegisterStatus EQUALS Registered
AND
MDM:DeviceComplianceStatus EQUAL Compliant
Step 14. Set the result to Permit Access.
Step 15. Click Done.
Step 16. Click Save.
Figure 17-79 shows the completed rule.
Figure 17-79 MDM permit rule.
When using MDM attributes as part of the authorization policy, ISE will check with the MDM at every authorization. So, if the MDM is unavailable, the rule will never match. In addition, a bulk download of data from the MDM occurs every four hours, detailing endpoint status. If an endpoint is marked noncompliant during that download, a CoA is sent and the device is forced to reauthenticate, providing a different result (such as quarantine).
Managing Endpoints
Each user can manage the devices she has personally onboarded from the MyDevices portal, or the administrator can manage the devices from the endpoints screen. The options for the device are shown in Table 17-3.
Table 17-3 MyDevices Registered Device Options
Self Management
The MyDevices portal is where end users can manage any endpoints that they have registered and register new endpoints.
An employee can log in to the MyDevices portal by navigating to either the default URL of https://[ISE_fqdn]:8443/mydevices/ or the friendly URL configured at Administration > Web Portal Management > Settings > General > Ports, as shown in Figure 17-80.
Figure 17-80 Settings > General > Ports.
Figure 17-80 shows the Ports page, where the friendly URL is configured.
By default, the MyDevices portal uses an identity source sequence (ISS) called MyDevices_Portal_Sequence, which includes only internal users by default in 1.2. To allow employees to log in successfully, you need to add Active Directory to the ISS.
From the ISE GUI, navigate to Administration > Identity Management > Identity Source Sequences. Select the MyDevices_Portal_Sequence, and add the AD1 identity source, as shown in Figure 17-81.
Figure 17-81 MyDevices_Portal_Sequence.
After logging in to the MyDevices portal, the list of registered devices is displayed. As displayed in Figure 17-82, if an MDM is being used, the user can select her device and initiate one of the options, such as Corporate Wipe.
Figure 17-82 MyDevices portal.
Administrative Management
From an administrative perspective, BYOD registered endpoints are administered just like any other endpoint at Administration > Identity Management > Identities > Endpoints. From here, an administrator can initiate actions against the registered devices, as shown in Figure 17-83.
Figure 17-83 Endpoint identities.
The Opposite of BYOD: Identify Corporate Systems
For many years, Cisco has had customers explain their business need to identify the machine as an authorized asset, in addition to the user being an authorized user. Given that Microsoft Windows has both a user and a machine state, the device can be authenticated to the network with what is commonly known as machine auth, as well as have the ability to have the interactive user authenticated to the network.
The issue is that EAP was always designed to transport a single credential. The machine authentication occurs when there is no interactive user or if the supplicant profile is configured to only issue the machine’s credentials. When the user logs in to the system, it changes to a user state and issues the credentials associated to the user. With standard RADIUS and standard EAP, there was no way to join those authentications together.
To resolve the issue, Cisco enhanced EAP-FAST with the ability to do EAP Chaining. EAP Chaining is a capability to authenticate both the machine and the user within the same authentication session. EAP-FASTv2 has been standardized in the IETF and is known as EAP-TEAP (RFC7170). At the time this book was being written, no known vendor (OS or RADIUS server) has implemented TEAP, but the majority of vendors do have plans to implement it.
With EAP-FASTv2 and EAP-Chaining, both the machine and the user are issued a protected access credential (PAC), similar to a secure cookie. Thus, ISE may request the machine PAC during the user authentication process, and the authorization policy is capable of using the results of either or both authentications.
The authorization condition is NetworkAccess:EAPChainingResult, and the options are
No chaining.
User and machine both failed.
User and machine both succeeded.
User failed and machine succeeded.
User succeeded and machine failed.
With that level of flexibility, an authorization result can be provided that permits limited access to remediate a single failure, no access if neither succeeds, and full access if both succeed (for example).
A practical example from a real-world deployment was to use EAP Chaining to identify corporate-owned and -managed devices; the authorization rule acted like this:
IF
the device and user authentication both succeed
and the endpoint posture is compliant
and the user is a member of the PCI group in Active Directory
and the location of the endpoint is on a corporate campus
THEN
Permit Full Access
and assign the PCI Security Group Tag (SGT)
That authorization rule allowed only those devices to communicate to the servers housing credit card data.
Exam Preparation Tasks
Review All Key Topics
Review the most important topics in the chapter, noted with the key topics icon in the outer margin of the page. Table 17-4 lists a reference of these key topics and the page numbers on which each is found.
Table 17-4 Key Topics for Chapter 17
Define Key Terms
Define the following key terms from this chapter and check your answers in the glossary:
onboarding
MDM mobile Device Management (MDM)