Ask the Expert: Integrating Cisco Identity Service Engine (ISE) 1.2 for BYOD

[ciscomoderator]

With Eric Yu and Todd Pula 

Welcome to the Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions  about integrating Cisco ISE 1.2 for BYOD with experts Eric Yu and Todd Pula.

Cisco Bring Your Own Device (BYOD) is an end-to-end architecture that orchestrates the integration of Cisco's mobile and security architectures to various third-party components. The session takes a deep dive into the available tools and methodologies for troubleshooting the Cisco BYOD solution to identify root causes for problems that stem from mobile device manager integration, Microsoft Active Directory and certificate authority services, and Cisco Enterprise Mobility integration to the Cisco Identity Services Engine (ISE). 

Todd and Eric recently delivered a technical workshop that helps network designers and network engineers understand integration of the various Cisco BYOD components by taking a deep dive to analyze best practice configurations and time-saving troubleshooting methodologies. The content consisted of common troubleshooting scenarios in which TAC engineers help customers address operational challenges as seen in real Cisco BYOD deployments.

Eric Yu is a technical leader at Cisco responsible for supporting our leading-edge borderless network solutions. He has 10 years of experience in the telecommunications industry designing data and voice networks. Previous to his current role, he worked as a network consulting engineer for Cisco Advance Services, responsible for designing and implementing Cisco Unified Communications for Fortune 500 enterprises. Before joining Cisco, he worked at Verizon Business as an integration engineer responsible for developing a managed services solution for Cisco Unified Communications. Eric holds CCIE certification in routing and switching no. 14590 and has two patents pending related to Cisco's medianet.   

Todd Pula is a member of the TAC Security and NMS Technical Leadership team supporting the ISE and intrusion prevention system (IPS) product lines. Todd has 15 years of experience in the networking and information security industries, with 6 years of experience working in Cisco's TAC organization. Previous to his current role, Todd was a TAC team lead providing focused technical support on Cisco's wide array of VPN products. Before joining Cisco, he worked at Stanley Black & Decker as a network engineer responsible for the design, configuration, and support of an expansive global network infrastructure. Todd holds his CCIE in routing and switching no. 19383 and an MS degree in IT from Capella University.

Remember to use the rating system to let Eric and Todd know if you have received an adequate response.

Because of the volume expected during this event, Eric and Todd might not be able to answer every question. Remember that you can continue the conversation in the Security community, subcommunity AAA, Identity and NAC, shortly after the event. This event lasts through November 15, 2013. Visit this forum often to view responses to your questions and the questions of other Cisco Support Community members.

[Jackson Braddock]

Hello experts,

What are the certificate exented key usage and subject alternative name requirements for Cisco ISE BYOD Endpoints?  Thank you in advance.

JB

[Todd Pula]

The minimum required EKU for BYOD endpoints is Client Authentication.  On the Microsoft CA side, you can either use the existing User template or you can clone this template and build a custom one.  From a certificate subject standpoint, the template should be configured so that the subject is supplied in the request.  During the suplicant provision process, the SAN filed will typically be auto-populated with the MAC address of the endpoint.  Normally we don't do much tweaking of the SAN field of the client certificates.  We do, however, need to properly plan for the SAN field on the identity certificates of the ISE policy nodes handling endpoint authC requests.  A typical use case is when there is a load balancer sitting between the endpoint and the ISE policy node(s).  The user may be initially redirected to a URL that resolves to the virtual IP of the load balancer.  The load balancer then redirects the session to an available policy node.  The policy node then responds directly to the endpoint using its own certificate.  Without taking the SAN field into account, the endpoint operating system may not be able to validate the identity certificate of the policy node resulting in a certificate authentication failures or unexpected user prompts. 

• User 1 tries to connect to ise.abc.com, resolves to load balancer VIP of 10.10.10.1
• Load balancer sends the inbound request to ise-psn1.abc.com
• ise-psn1 responds directly to the endpoint presenting its own identity certificate with subject name ise-psn1.abc.com
• Because the originating request was to ise.abc.com and the responding certificate subject was ise-psn1.abc.com, most operating systems will be unable to authenticate this certificate
• To resolve, the identity certificates of the policy nodes should be corrected to include their own subject name, the SAN field should then include their own subject name as well as the alternative names in use (ie. ise-psn1.abc.com, ise.abc.com, guest.abc.com, sponsor.abc.com, mydevices.abc.com, etc.)
• Other use cases may see IP addresses being used in the subject as opposed to a FQDN so the SAN field may need to include IPs as well
• The use of wildcard certificates is now possible with ISE 1.2

[hellomike99]

Also can you help me understand;

What are the best practices for building authorization rules for integrating MDM to Cisco ISE?

[Todd Pula]

Here are the three most common ways I see people defining ISE authZ policies in support of MDM:

• ISE BYOD onboarding for certificate and network profile deployment followed by MDM registration/compliance verification
• MDM registration/compliance verification followed by ISE BYOD onboarding for certificate and network profile
• MDM registration/compliance check only (when certificates and network profiles are deployed via MDM or other means), BYOD devices manually added to ISE using My Devices Portal

Some of the more commonly used conditions that you can use in authZ policies are listed below.  These are not all inclusive and ISE gives you the flexibility to mix and match conditions to be as specific as possible.  Before trying to configure a policy on ISE, take a few minutes to break down the requirements into simple If Then statements.  For example, "IF user is a part of the AD group BYOD_Users and BYODRegistration is not equal to yes THEN match supplicant provisiong rule".

• EndPoints:BYODRegistration - can be yes, no, or unkown
• MDM:DeviceRegisterStatus - can be registered or unregistered
• MDM:DeviceCompliantStatus - can be compliant or noncompliant

[Eric Yu]

Hi Mike,

The AuthZ configuration, as Todd described,  assumes the existing MDM deployement is provisioned to reflect your organization's most current BYOD policy. Thus, the general recommendation is to build AuthZ rules on ISE to enforce MDM registrationa and compliance rules prior to allowing the device to access network resources.

-Eric

[grabonlee]

Hello Todd and Eric,

I have a peculiar situation. I initially configured authentiation, autorization and client provisioning policies on ISE 1.2 during SCEP implementation for Android and Iphones. The result was successful. However, I later revoked the user certificates for both the Iphone and Android moibles that I used for testing and removed the certs from the phones' store. 2 days later, I tried to perform SCEP enrollement, but the ISE URL redirect wouldn't come up. I wiped the whole configuration on ISE and started afresh using Policy Set and Client provisioning. The result was still as before. I have done a Wireshark trace and could see the Accept-Accept response from ISE to the WLC with the URL redirect but that is where it stops. No further logs. Even the TCP dump from ISE showed the same result as the Wireshark

I am considering applying the command "config network web-auth secureweb disable on the WLC 7.4, but I doubt if this would work as the URL redirect is coming from ISE and not the WLC.

Please any suggestions on how to resolve this problem?

[Todd Pula]

If you are testing from the same client over and over again, you should get in the habit of either removing the client from the ISE endpoint database or initiate a session terminate CoA from the live sessions view.  You may also want to clear the browser cache and forget the SSID but this is not always necessary.  I don't have enough details from your problem description so I will ask some questions for you to consider:

• Is this a single SSID or dual SSID setup?
• In your test flow, are you completing the initial authentication?
• Is the client associating to the SSID in question and getting an IP address from DHCP?
• Is the client matching the more specific NSP authZ rule (or self-provisioning flow) and is ISE sending a CoA to the WLC?
• When looking at the Radius NAC State of the endpoint session on the WLC, is the session in a CENTRAL_WEB_AUTH state and do you see the correct redirect URL and redirect ACL?
• Is the redirect ACL correctly named and configured (on WLC we permit what we don't want to redirect and deny what we do)?
• Is ISE using its FQDN in the redirect URL (default) or are you using a static hostname/IP?
• Can the endpoint resolve the ISE node FQDN using the configured DNS server?   

[grabonlee]

Hi,

I performed the tests with different clients that were connecting for the first time, hence the problem isn't peculiar to the 2 mobiles I used earlier.

1. It is a single SSID setup.

2. The Initial authentication completes (PEAP-MSCHAPv2)

3. The client gets an IP address.

4. Not sure what you mean by NSP. However, the client matches the authZ profile

5. I see the correct redirect URL and redirect ACL in the Results field under Cisco AV-Pair

6. The endpoint on the WLC shows Supplicant Provisioning under the Radius NAC state.

7. The redirect ACL is correctly named. As I mentioned earlier, it was working before. On the ACL counters on the WLC, the counters for the permit rule to ISE no longer increments, but the Deny to other IPs except ISE increments.

8. The ISE is using its FQDN

9. The ISE FQDN resolves when I copy and paste the URL redirect on my PC browser.

If you want me to send you logs, I am willing to do so. Thanks for your help.

Please see attached file, which is output from Operation (Authentication) tab. I intentionally altered part of the redirect URL, but take my word that it is the correct URL.

[Todd Pula]

Copying the URL to another browser doesn't always tell the story from the perspective of the endpoint that you are testing with.  If testing with an Apple iOS device, there are tons of free network apps out there like Ping Lite from Mocha Ping that allow you to do ping tests, nslookup, etc. to prove basic connectivity and name resolution from the endpoint in question (ACL permitting of course).  When you obvserve this issue, do you see the correct redirect URL in the endpoint browser but it's just not loading the page?  Or does the browser never display the redirect URL?

[barryfowles]

Hi Todd,

I am having a similar problem with a BYOD install to that of Osita. I am configuring BYOD for FlexConnect with dual SSIDs. I can connect to the open SSID and receive the correct IP Address as well as the redirect URL and ACL but the redirect then fails. I have connected a laptop to the guest network and can then browse to the url of the Sponsor Portal so I know that there is nothing stopping the client geting to the ISE. It's as if the ACL isn't being applied or being applied correctly. I'm running 7.4.115.0 code on the 5508 and 1.2 Patch 3 on the ISE. I have previously configured the same implementation for a different customer with 7.3 code on a WiSM  and 1.1 code on the ISE and it worked fine.

Any thoughts

Barry

[Todd Pula]

Seeing you have deployed FlexConnect before I am assuming you already have this configuration correct but I will state it here for others that may read.  With FlexConnect, the redirect ACL needs to be defined as a FlexConnect ACL vs. the traditional ACL used on the controller.  The FlexConnect ACL can be configured under Security > Access Control Lists > FlexConnect ACLs.  When defining the FlexConnect group on the controller, you then associate this FlexConnect redirect ACL to the WebPolicies tab under Wireless > FlexConnect Groups > GROUP NAME > ACL Mapping > WebPolicies.  Please confirm this to be configured to match the ACL name defined in your ISE authZ profile.  If all looks good, is this problem 100% reproducible in your case accross different endpoint OS?  Do you do something to resolve and if so does the problem manifest again?  Based on the code versions, you are running the latest and greatest on both fronts.  To your point about testing from a guest connected PC, I try whenever possible to verify connectivity from the perspective of the endpoint I am testing with.  My iPad is usually my goto and there are tons of free network apps that you can use to validate basic IP connectivity, ping tests, nslookup, etc from the endpoint itself.  The iPhone Configuration Utility comes in handy as well when I need console access to iOS (certificate issues, OTA provisioning issues).  We also need to make sure that the appropriate ports/protocols such as TCP 8443, TCP 8905, TCP 8906 are open between the endpoint and ISE in addition to the network services such as DNS and DHCP.   

[barryfowles]

Hi Todd,

I see the correct url on my iPad, the redirection starts but never gets anywhere. I have configured the redirect ACL under FlexConnect ACLs and created a FlexConnect Group with the ACL mapped to WebPolicies. I will be on site tomorrow and will test with some other endpoints.

Thanks again.

[Todd Pula]

Sounds good.  Try installing Ping Lite from Mocha Ping on your iPad and confirm that you are able to resolve the FQDN of the ISE node while in this state.

[grabonlee]

Hi Todd,

Th endpoint browser never displays the redirect URL. For example, attempting to go to a website just hangs instead of being redirected to the URL. The Deny rule on the WCL ACL increments correctly as the any other IP except the ISE IP isn't allowed. The counter for the  ACL rule permit to the ISE doesn't increment at all.

[grabonlee]

Todd,

I don't know if the comments below will shed more light.

I have run the Supplicant Provisioning report going back 7 days and noticed the message: "Error while trying to match to determine access privileges: No Matching SPW profile found." This is despite the fact that I didn't create a Client Provisioning rule for Windows. However, in the Native Supplicant Profile, the OS is set to ALL.

I also noticed that my Android and IPhone showed the same error message in the report, but when I created a new Native Supplicant profile and set OS to Android and Iphone only, no subsequent sessions showed up in the Supllicant Provisioning report, even though the authentication is successful. 

I changed the OS to ALL again and reconnected to see if the error would show up, but there was no logged session. It seems the report only records the first 2 attempts for the same user name.

The attached file is the connection attempts through the IPhone today as subsequent connection attempts didn't show up.