You are here
ISE 1.2 MDM Integration Consideration
Submitted by admin on Sun, 09/15/2013 - 21:30
As you all know, Cisco ISE 1.2 supports MDM integration, although it might still be unclear to many people on how ISE and MDM play together as they might be viewed as completing products with overlapping functions. Here we have compiled a list of bullet points that you might find useful and need to consider to decide whether this is the right strategy for you. Please note that there are many MDM vendors that ISE supports and their functionalities may vary so the list provided here is generic and not specific to any MDM vendor.
Supported MDM Vendors (as of ISE 1.2)
- Airwatch, Inc.
- Good Technology
- MobileIron, Inc.
- Zenprise, Inc.
- SAP Afaria
- FiberLink Maas360
- Cisco Mobile Collaboration Management Services (MCMS)
- MDM is still the place to configure and enforce device configurations, application distribution, and security policies. Cisco ISE is not capable of any of these functions.
- MDM is primarily for managing and connecting personal mobile devices (eg. iPhone, iPad, Android, Windows Phone etc.) to corporate wireless network, but not personal computer, particularly Windows.
- MDM does not really deal with wired devices, although ISE does.
- MDM can be used to provision wireless LAN profile and user certificate but a separate authentication system, such as Cisco ISE or ACS, is still required to authenticate users to the network.
- The main overlapping functions that ISE has compared to the MDM are wireless profile provisioning and user certificate distribution via SCEP. These functions should be disabled on the MDM and let ISE carry out these functions to avoid duplication.
- ISE only has access to limited posture information and set of API (See picture below). Any information or actions that are not available on ISE still need to be obtained or performed on the MDM.
Why should I integrate ISE with MDM?
You will be able to provide differentiate access to wireless users based on their compliant status. This is due to the fact that ISE now has certain level of visibility to the device posture, which can be used to build authorization policies. For example,
- Compromised Device (ie rooted, jailbroken) = Deny Access
- Non-Compliant Device = Internet Only
- Compliant Device = Full Access
- ISE will become a unified system for onboarding especially if you plan to allow personal Windows computer (wired and wireless), instead of having two separating onboarding systems. ISE authorization policy can be built such that Windows computers get full access at the end of ISE onboarding, while all other supported mobile devices continue with MDM registration.
What are potential downsides of integrating ISE with MDM?
- Onboarding process becomes longer with users having to go through ISE and MDM registration back-to-back. This also increases likelihood of users running into problem due to the onboarding process itself or failing to follow provided instructions.
- While devices need to register at both places, the reverse is also true when it comes time to remove devices from the system.
- Users lose ability to onboard their devices from outside corporate network as ISE can most likely only be reached internally.
- Having a device registered to both ISE and MDM create additional management overhead, not to mention users also need to be aware of both user portal on MDM and MyDevices portal on ISE.
In short, you should have a good understanding of what you can gain as a result of MDM integration before considering implementing it in your environment. Otherwise, you might unnecessarily add complexity to the system and end up with negative BYOD user experience and management overhead as a result.