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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
Hello Eric, Todd -
What are the pre-requisites for integrating Cisco 1.2 to a Mobile Device Manager? Appreciate your help on this.
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:
To see an example of integrating Cisco ISE 1.2 to Airwatch, please reference the link below:
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.
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:
What are the certificate exented key usage and subject alternative name requirements for Cisco ISE BYOD Endpoints? Thank you in advance.
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.
Also can you help me understand;
What are the best practices for building authorization rules for integrating MDM to Cisco ISE?
Here are the three most common ways I see people defining ISE authZ policies in support of MDM:
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".
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.
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?
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:
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.
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?
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 184.108.40.206 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.
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.
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.
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.
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.
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.