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.

[ahurtadove]

Hello Eric and Todd,

I'm having trouble configuring ISE with an WLC that is managing AP's in flexconnect mode, normally the CoE ACLs are not being acknowledged(?) by the WLC and not applied to the devices, there are at least two different methods through Cisco.com documentation and would like some type of general type of configuration for this.

Another question would be if Cisco has any documentation regarding the Cisco Network Assistant for Android which seems to be a little difficult to find, like what can be the meaning of the errors that are thrown by this tool in any given scenario.

And the last is to see if there is any chance that ISE will have TACACS+ and a Cisco built-in MDM included in future releases.

Thank you for your answers and best regards.

[Todd Pula]

Hi Antonio,

Many great questions to start this series.  For the situation that you are observing with your FlexConnect configuration, is the problem 100% reproducible or is it intermittent?  Does the problem happen for one WLAN but not another?  As it stands today, the CoA-Ack needs to be initiated by the management interface.  This limitation is documented in bug CSCuj42870.  I have provided a link for your reference below.  If the problem happens 100% of the time, the two configuration areas that I would check first include:

• On the WLC, navigate to Security > RADIUS > Authentication.  Click on the server index number for the associated ISE node.  On the edit screen, verify that the Support for RFC 3576 option is enabled.
• On the WLC, navigate to the WLANs tab and click on the WLAN ID for the WLAN in question.  On the edit screen, navigate to Security > AAA and make sure the Radius Server Overwrite interface is unchecked.  When this option is checked, the WLC will attemp to send client authentication requests and the CoA-Ack/Nak via the dynamic interface assigned to the WLAN vs. the management interface.  Because of the below referenced bug, all RADIUS packets except the CoA-Ack/Nak will actually be transmitted via the dynamic interface.  As a general rule of thumb, if using the Radius NAC option on a WLAN, you should not configure the Radius Server Overwrite interface feature.
• Bug Info:  https://tools.cisco.com/bugsearch/bug/CSCuj42870

For your second question, you raise a very valid point which I am going to turn into a documentation enhancement request.  We don't currently have a document that lists the possible supplicant provisioning wizard errors that may be encountered.  Please feel free to post specific errors that you have questions about in this chat and we will try to get you answers.  For most Android devices, the wizard log file can be found at /sdcards/downloads/spw.log.

As for product roadmap questions, we won't be able to discuss this here due to NDA.  Both are popular asks from the field so it will be interesting to see what the product marketing team comes up with for the next iterration of ISE.

Related Info:

Wireless BYOD for FlexConnect Deployment Guide

[ahurtadove]

Thank you very much for your answer Todd.

The link you provided seems to explain the problem I faced many times, but I can't see the real fix or workaround for this. Do I have to disable Radius Overwrite on all SSIDs and only enable it on the management? Will this work?

Also I forgot one question. I know that SCEP is used for validating identities and know how important this can be in a production environment. I have been installing ISE demos for some clients and sometimes it's difficult for them to configure this on a router or server. I have tried different things like putting it on a VM on my laptop and this definitely works. But I wanted to know if there is some way that you could "bypass" or not use SCEP or any certificate type?

Thank you once more.

[Todd Pula]

As it stands right now, if using the Radius NAC option on a WLAN, you should not configure the Radius Server Overwrite interface feature.  This will allow the WLC to use the management interface as the source of all RADIUS packets including the CoA-Ack/Nak.  The ultimate "fix" will need to come as an enhancement to the WLC code.

BYOD proof-of-concepts can be a challenge on the SCEP front.  It isn't always easy to just spin up a licensed Server 2008 R2 SCEP machine and connect it to a customer's enterprise CA.  Can you expand on the BYOD flow that you would like to demonstrate to a customer?  You can certainly manually add BYOD demo devices to the ISE endpoint database using the My Devices Portal.  In ISE 1.2, doing so will update a new endpoint attribute flag called BYODRegistration which you could then use as a condition in your authZ policy.  If you can provide some additional color around what you would like to achieve, Eric and I can offer up some ideas. 

[ahurtadove]

Thank you Todd, your answer certainly helped me with the SCEP process, the BYODRegistration flag was indeed updated and then was used in an authZ policy afterwards.

[Todd Pula]

Glad to hear it worked for you.  As for your other question, you don't need to install the MDM API into ISE 1.2  Once you enable an MDM server for the first time, the related MDM conditions will become available for you to use in the authZ rules.  Matching an MDM condition is what triggers the API call to the configured MDM provider.  I am including a link to a sample MDM config doc from Cisco.com.  This one speaks to MobileIron but the process is similar for others.

http://www.cisco.com/en/US/docs/solutions/Enterprise/Borderless_Networks/Unified_Access/MobileIronISE.html

[John Ventura]

Eric/Todd,

Thank you for covering this topic.  Just a quick question. I have an existing MDM service, and we're integrating this to Cisco ISE 1.2, what are the pro's and cons for deploying certificate and wireless profiles using MDM vs ISE?

Thanks for your help on this.

John

[Eric Yu]

Hi John,

Your question raises a few considerations when planning for an ISE 1.2 deployment.

1. MDM vendors typically offers an advance certificate provisioning service that will free the BYOD solution operator from supporting an extra layer of complexity such as an extra MS SCEP server as Todd noted in the previous post.

2. If your enterprise has already implemented an MDM solution with existing defined business policies, the general recommendation is to integrate ISE AuthZ rules that checks MDM policies for access control.

3. There is an agent cost for all mobile devices managed by any MDM solution, so if there are wireless endpoints that do not require MDM features to help reduce costs, Cisco ISE policies based context may be sufficient to enforce policies for these devices.

4. Not all MDM providers will support Windows/MacOS/Linux in addition to Android/Apple iOS devices, this means context rules on Cisco ISE can bridge any gaps that is beyond the span of MDM features.

5. MDM offers a great solution to enforce application management on mobile devices; however in scenarios where app management is not applicable on wireless devices for example game consoles, irobot Ava 500; Cisco ISE provides a web-portal that enables end user for self-help.

When maximizing the benefits of integrating Cisco ISE with an existing MDM solution, one objective is to figure out how Cisco ISE can enforce contextual policies that maybe beyond the scope of the existing MDM features.

[Todd Pula]

Hi John,

In addition to some of the points that Eric raised, I think the overall user interactive experience plays into the decision to use ISE vs. MDM for the certificate and wireless profile distribution.  For example, some environments may have very restricitve endpoint OS policies with strict control over what if any Java applications may be executed.  Because we use Java to execute some of our supplicant provisioning wizards, this may be an example of where the MDM and endpoint agent can be used to distribute some of the configuration.  Trying to stay on top of endpoint OS  features and functionality is a continuous process requiring a significant amount of testing in between release cycles.  We are always looking for ways to streamline the user experience to minize prompts and clicks but sometimes we are bound to what the endpoint OS will allow us to do.     

[egordon310]

Hello Eric, Todd -

What are the pre-requisites for integrating Cisco 1.2 to a Mobile Device Manager? Appreciate your help on this.

Evan

[Eric Yu]

Hi Evan,

Cisco ISE 1.2 integrates to MDM  by establishing an HTTPS connection to the MDM provider's API. This implies that firewall rules and/or web proxy configurations on Cisco ISE enabled to allow web access to the MDM provider's API server. HTTPS connectivity from ISE to MDM requires a username that is  provisioned on  MDM  with API rights.  The username will be configured  on Cisco ISE to establish context inquiries to check policies.

In addition, because  ISE uses HTTPS for transport, the  MDM site certificate must be  imported into  ISE Certificate Repository to ensure connectivity.

Please Note: Specific MDM providers have successfully enabled API's that will integrate with Cisco ISE. These validated MDM partners are listed here:

http://tools.cisco.com/squish/9d3e5

To see an example of integrating Cisco ISE 1.2 to Airwatch, please reference the link below:

http://tools.cisco.com/squish/aA3Fd

[hellomike99]

How does ISE 1.2 verify MDM profiles if the MDM vender is in the cloud?

Thx

[Todd Pula]

The majority of the cloud-based MDM offerings use HTTPS to terminate API sessions.  Because of this, you will need to investigate what 3rd party CA the MDM provider is using on their cloud servers.  You can quickly validate this with a web browser.  Most browsers will allow you to export the CA certificates which you can then manually import into the ISE certificate store via Administration > System > Certificates.  In this design, the ISE policy node(s) will need to be able to communicate with Internet hosts on TCP 443 either directly or via proxy.  Once both of these initial tasks have been completed, you will add the MDM server to ISE via Administration > Network Resources > MDM.  This will enable MDM conditions such as

MDM:DeviceRegisterStatus and MDM:DeviceCompliantStatus that you can then apply to your authorization policies.  This last step is important as the API queries to the configured/enabled MDM server are triggered when an authorization policy with MDM condition(s) is matched. 

[Eric Yu]

Cisco ISE 1.2 verifies MDM profiles using REST API services transported over HTTPS. What this means is that it does not matter if the MDM solution deployed as a cloud service or  on-premise solution, ISE 1.2  simply requires a web connection established from ISE 1.2 to check MDM for compliance context. The results of the MDM inquiry is provided back to ISE in a XML format that is consumed by ISE to trigger an administratively defined set of authorization rules.

The list of ISE 1.2  API's  where validated MDM partners have implemented can be found here:

http://tools.cisco.com/squish/1D7A7