Transcription
Integrating MobileIron withCisco Identity Services EngineRevised: August 6, 2013
2
ALL DESIGNS, SPECIFICATIONS, STATEMENTS, INFORMATION, AND RECOMMENDATIONS (COLLECTIVELY, "DESIGNS") IN THIS MANUAL ARE PRESENTED"AS IS," WITH ALL FAULTS. CISCO AND ITS SUPPLIERS DISCLAIM ALL WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT ORARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NOEVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL,CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USEOR INABILITY TO USE THE DESIGNS, EVEN IF CISCO OR ITS SUPPLIERS HAVEBEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.THE DESIGNS ARE SUBJECT TO CHANGE WITHOUT NOTICE. USERS ARESOLELY RESPONSIBLE FOR THEIR APPLICATION OF THE DESIGNS. THEDESIGNS DO NOT CONSTITUTE THE TECHNICAL OR OTHER PROFESSIONALADVICE OF CISCO, ITS SUPPLIERS OR PARTNERS. USERS SHOULD CONSULTTHEIR OWN TECHNICAL ADVISORS BEFORE IMPLEMENTING THE DESIGNS.RESULTS MAY VARY DEPENDING ON FACTORS NOT TESTED BY CISCO.The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’spublic domain version of the UNIX operating system. All rights reserved. Copyright 1981, Regents of the University of California.Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliatesin the U.S. and other countries. A listing of Cisco's trademarks can be found athttp://www.cisco.com/go/trademarks. Third party trademarks mentioned are theproperty of their respective owners. The use of the word partner does not imply apartnership relationship between Cisco and any other company. (1005R)Any Internet Protocol (IP) addresses and phone numbers used in this document arenot intended to be actual addresses and phone numbers. Any examples, commanddisplay output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses orphone numbers in illustrative content is unintentional and coincidental.Integrating MobileIron with Cisco Identity Services Engine 2013 Cisco Systems, Inc. All rights reserved.Integrating MobileIron with Cisco Identity Services Engine3
Integrating MobileIron with Cisco IdentityServices EngineThis document supplements the Cisco Bring Your Own Device (BYOD) rprise/Borderless Networks/Unified Access/BYODDesign Guide.html) and provides mobile device management (MDM) partner-specific information asneeded to integrate with Cisco ISE. In an effort to maintain readability, some of the informationpresented in the CVD is repeated here. However this document is not intended to provide standaloneBYOD guidance. Furthermore, only a subset of the MobileIron MDM functionality is discussed.Features not required to extend ISE’s capabilities may be mentioned, but not in the detail required for acomprehensive understanding. The reader should be familiar with the MobileIron Administrator’s guide.This document is targeted at existing MobileIron customers. Information necessary to select an MDMpartner is not offered in this document. The features discussed are considered to be core functionalitypresent in all MDM software and are required to be compatible with the ISE API.OverviewMobileIron is a leading provider of MDM software used to establish and enforce device policy onhand-held endpoints. This could include corporate- or employee-owned phones and tablets. Devicesmanufactured by all the major equipment providers are supported at some level. Apple iOS and Androiddevices are the primary focus, but MobileIron also supports Blackberry, Win8, and Apple’s OS X Lionand Mountain Lion software (10.7 and 10.8, respectively).Mobile Device management is a relatively new phenomenon and is in a constant state of expansion.Features can be grouped into several categories: Device Restrictions—There are two common types of restrictions. Either some feature of the deviceis disabled, such as the camera, or there are additional requirements for basic usage, such as a PINlock or storage encryption. When a restriction is in place, the user is not offered the choice ofnon-compliance. Restrictions are used to reduce security risks to the enterprise. Device Compliance—This may also be referred to as posture enforcement. The MDM will checkthe attributes of the device against a list of acceptable operational conditions. Compliance checkscan be enforced based on their severity. For example, an email could be sent to the user when theyhave exceeded 80% of their data plan or MobileIron can automatically issue a corporate wipe if theCorporate Headquarters:Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USACopyright 2013 Cisco Systems, Inc. All rights reserved.
device has been compromised. A compliance check is different from a restriction because theuser can take the device out of compliance. Compliance can be used to increase security orreduce operational costs. Notifications—Administrators can send a message to a large population of devices. This couldbe a push message to the device notification page. For example, “The fire drill is complete,you may return to the building” could be sent to all devices on a particular campus.Notifications are used to increase productivity. Content Distribution—Bookmarks, documents, and other content can be pushed to devices inthe background, with out without the user intervention, or made available on demand. Thisdata is then stored in a corporate container. Content distribution is used to increaseproductivity. Application Distribution—The MDM can offer a company catalog of available software orinstall required software. The software can come from public repositories or can be corporatedeveloped applications. Application distribution has both a security and productivity gains.Security is enhanced because any software distributed by the MDM, including local storageassociated to the software, is removed as part of a corporate wipe. This is not true if the userinstalls the same software from the Apple App Store.MobileIron’s MDM solution has three main components: Policy server Device OS API Device client softwareBeyond these, there are additional components for enterprise integration with systems such asemail, Web, and secure corporate data. The majority of the base functionality is available throughthe MDM API built into the mobile device operating system. MobileIron requires the clientsoftware to detect some conditions such as jail-broken1 or rooted devices. Because ISE tests forthese conditions, the MobileIron server is configured to treat the client software as a requiredapplication and will install the software during the onboarding process.MobileIron also offers a scripting engine (Assemble) that can provide additional flexibilitybeyond what is shown here. This is an advanced tool appropriate in specific scenarios. It ismentioned here to reinforce that this document is not a full exploration of all of MobileIron’scapabilities.Deployment ModelsMobileIron offers its Virtual Smartphone Platform (VSP) as both an on-premise model and a cloudservice model. The two models are functionally equivalent. The CVD explores the advantages anddisadvantages of each of the models. An obvious difference is the topology. An on-premise modelis defined when the MDM server is located in the enterprise DMZ and managed directly by theenterprise. A cloud model places the MDM server in the cloud and is offered as a softwaresubscription. Both models support integration with corporate services such as corporatedirectories, exchange, or a Blackberry Enterprise Server. The cloud model provides directoryintegration with MobileIron'’ Connector Server. Currently Connected cloud does not supportSCEP. Although the use cases in the CVD do not require SCEP from the MDM, other scenariosnot covered here could benefit from this functionality. With VSP 5.6, an on-premises deploymentwould be required if SCEP via the MDM is a requirement.1. Apple prefers the term “compromised OS” when referring to systems where the user has gained root access tothe operating system.Integrating MobileIron with Cisco Identity Services Engine5
Getting MobileIron Ready for ISEThe first requirement is to establish basic connectivity between the Cisco ISE server and the MobileIronMDM server. In both the on-premise and the cloud model, a firewall is typically located between thesetwo components. The firewall should be configured to allow an HTTPS session from ISE located in thedata center to the MDM server located in either the corporate DMZ or public Internet. The session isestablished outbound from ISE towards the MDM where ISE takes the client role. This is a commondirection for Web traffic through corporate firewalls.Import VSP Certificate to ISEThe MobileIron MDM server incorporates an HTTPS portal to support the various users of the system.In the case of a cloud service, this website will be provided to the enterprise. ISE must establish trustwith this website. Even though the cloud website is authenticated with a publicly signed certificate, ISEdoes not maintain a list of trusted root CAs. Therefore, the administrator must establish the trustrelationship. The simplest approach is to export the MDM site certificate then import the certificate intolocal cert store in ISE. Most browsers allow this. Firefox is shown in Figure 1. Note that MobileIronsupports Firefox 14 and Internet Explorer 8.Figure 1Export MobileIron Web CertificateIn case of an on-premise deployment, the site certificate will need to be signed by a trusted CA andinstalled on the MDM server prior to importing the certificate to ISE. This task is completed from theSystem Manager portal and is well documented by MobileIron.6Integrating MobileIron with Cisco Identity Services Engine
Grant ISE Access to the MobileIron APIThe MobileIron MDM API is protected by HTTPS and requires a user account that has beengranted permission to the API. Ideally a specific account would be configured for ISE with a verystrong password. In addition to this account, only a limited number of administrator accountsshould be granted the ability to create new administrators or assign administrator roles. Creatinglocal user accounts is accomplished in the User and Device section of the administrator console,as shown in Figure 2.Figure 2Create ISE User AccountOnce the account has been created, it is assigned roles to allow ISE access to the MDM API.Integrating MobileIron with Cisco Identity Services Engine7
Figure 3Assign API Role to ISE AccountAdd MDM Server to ISEOnce the account has been defined on the MobileIron MDM server with the proper roles, ISE can beconfigured to use this account when querying the MDM for device information. ISE will contact theMDM to gather posture information about devices or to issue device commands, such as corporate wipeor lock. The session is initiated from ISE towards the MDM server. The URL for the MobileIron serveris the same as the admin page and used earlier to export the certificate. The directory path is handledautomatically by the system and is not specified as part of the configuration. The Instance Name field isused when subscribing to a MobileIron cloud service and uniquely identifies the cloud partition.MobileIron will provide the Instance to be used. The field should be left blank for an on-premisedeployment. The port will should be configured for (TCP) 443 for HTTPS. The MDM cannot beconfigured to listen on a specific port for API users and any change will also impact both the admin anduser portal pages.8Integrating MobileIron with Cisco Identity Services Engine
Figure 4Configure the MDM API on ISEThe polling interval specifies how often ISE will query the MDM for changes to device posture.Setting the value to zero will disable polling. Polling is used to periodically check the MDMcompliance posture of an end station. If the device is found to be out of MDM compliance and thedevice is associated to the network, then ISE will issue a CoA, forcing the device tore-authenticate. Likely the device will need to remediate with the MDM although this will dependon how the ISE policy is configured. Note that MDM compliance requirements are configured onthe MDM and are independent of the policy configured on ISE. It is possible, although notpractical, to set the polling interval even if the ISE policy does not consider the MDM Compliantdictionary attribute.The advantage of polling is that if a user takes the device out of MDM compliance, they will beforced to reauthorize that device. The shorter the window, the quicker ISE will discover thecondition. There are some considerations to be aware of before setting this value. The MDMcompliance posture could include a wide range of conditions not specific to network access. Forexample, the device administrator may want to know when an employee on a corporate device hadexceeded 80% of the data plan to avoid any overage charges. In this case, blocking network accessbased solely on this attribute would aggravate the MDM compliance condition and run counter thedevice administrator’s intentions. In addition, the CoA will interrupt the user WiFi session,possibly terminating real-time applications such as VoIP calls.The polling interval is a global setting and cannot be set for specific users or asset classes. Therecommendation is to leave the polling interval at 0 until a full understanding of the MDM’sconfiguration is attained. If the polling interval is set, then it should match the device check-inperiod defined on the MDM. For example, if the MDM is configured such that devices will reporttheir status every four hours, then ISE should be set to the same value and no less than half of thisvalue. Over sampling the device posture will create unnecessary loads on the MDM server andreduced battery life on the mobile devices. There are other considerations with respect to scanintervals. Changing MDM timers should be done only after consulting with MobileIron’s bestpractices.Integrating MobileIron with Cisco Identity Services Engine9
Verify Connectivity to MDMThe Test Connection button shown in Figure 4 can be used to isolate and resolve common problems priorto developing MDM-based authorization policy. ISE will attempt to log in to the API and report backthe result. Completing the test successfully is required prior to saving the settings. If the test does notcomplete successfully, the settings can still be saved, but the Enable box will be deselected and theMDM will not be active.Some common problems found while testing the connection to the MDM server are shown in Table 1.Table 1Connection MessagesMessageExplanationA routing or firewall problem exists between theISE located in the data center and the MDMlocated in either the DMZ or Cloud. Thefirewall’s configuration should be checked toconfirm HTTPS is allowed in this direction.The most likely cause of an HTML 404 error codeis that an instance was configured when it was notrequired or that the wrong instance has beenconfigured.The user account setup on the MobileIron serverdoes not have the proper roles associated to it.Validate that the account being used by ISE isassigned the REST API MDM roles as shownabove.The user name or password is not correct for theaccount being used by ISE. Another less likelyscenario is that the URL entered is a valid MDMsite, but not the same site used to configure theMDM account above. Either of these could resultin the MobileIron server returning an HTML code401 to ISE.ISE does not trust the certificate presented by theMobileIron website. This indicates the certificatewas not imported to the ISE certificate store asdescribed above or the certificate has expiredsince it was imported.The connection has successfully been tested. Theadministrator should also verify the MDMAUTHZ dictionary has been populated withattributes.10Integrating MobileIron with Cisco Identity Services Engine
Review MDM DictionariesWhen the MobileIron MDM becomes active, ISE will retrieve a list of the supported dictionaryattributes from the MDM. Currently MobileIron supports all of the attributes that ISE can query.The dictionary attributes are shown in Figure 5.Figure 5Dictionary AttributesEnterprise IntegrationBoth ISE and MDM must be integrated into a common enterprise environment. At the basic level,this involves sharing the same directory structure. A common directory simplifies the operationalaspects of the overall system, but also allows a consistent policy structure around AD groupmembership. For example, if a user is a member of the AD group FULL ACCESS, thatmembership should result in a policy from both ISE and MDM that is consistent with the groupand cognizant of the other component. If the MDM installs an application on a device, then ISEshould allow the application on the network for members of that AD group.MobileIron offers a Connector component. This is ideally suited for a cloud model, but could alsobe used in on-premise scenarios where the MobileIron server resides in the DMZ, but does nothave access to all enterprise services, such as LDAP. The service establishes outbound HTTPSconnections to the MobileIron server running in the cloud. The connector will periodically updatethe VSP with directory information that can be used to develop an integrated device policy. Theinstallation is straightforward and fully documented by MobileIron.On-premise deployment models can also make use of the Connector server. Most often, theMobileIron VSP server is located in the DMZ. However this requires that the enterprise allowLDAP from the DMZ through the firewall. Company policy may not permit this. In this case, theIntegrating MobileIron with Cisco Identity Services Engine11
Connector is deployed behind the firewall, eliminating the need to allow LDAP inbound from the DMZ.In addition to LDAP, the VSP server will establish outbound connections to the Apple Push NotificationServices (APNS) and Google Cloud Messaging (GCM). The MobileIron Administrator’s guide providesinformation on what firewall policies are required to provide access to the Internet push servers.Figure 6MobileIron Topology with On-Prem ConnectorData reApplicationand FileServersWLCsCAADDNSDHCPEthernet-over-IP (EoIP)Guest Anchor nternetInternet 799GuestVLANOuterASASocket RequirementsThere are several flows that need to be allowed between the various components. The full list is availablefrom MobileIron or the device vendors. Table 2 summarizes the required sessions.Table 212Common Socket RequirementsSourceDestinationTCP PortPurposeCommentMDMAPNS2195Apple PushNotificationCert RequiredMDMAPNS2196Apple PushFeedback ServiceAPNs MessageStatusIntegrating MobileIron with Cisco Identity Services Engine
Table 2Common Socket RequirementsSourceDestinationTCP PortPurposeCommentMDMGCN5228Google PushMDMLDAP (sLDAP)389 (636)DirectoryMobile DeviceISE8443Captive PortalOn-Boarding,RemediationMobile DeviceMDM8080ProvisioningConfigurableMobile DeviceMDM9997Sync TLSConfigurableMobile DeviceMDM9998Help DeskConfigurableMobile DeviceMDM9999Sync ServiceConfigurableMobile AndroidDeviceGCM5228Google CloudMessagingMobile iOSDeviceAPNS5223Apple PushNotificationAD/LDAP IntegrationWith either an on-premise or cloud model, integrating ISE and the MDM to a common directoryis important for the overall operations. One benefit is the ability to set a requirement that a userperiodically change their directory password. If the MDM were using a local directory, it wouldbe nearly impossible to keep the accounts in synchroniza
The URL fo r the MobileIron server is the same as the admin page and used earlier to export the certificate. The directory path is handled automatically by the system and is not specified as pa rt of the configuration. Th e Instance Name field is used when subscribing to a MobileIron cloud service and uniquely identifies the cloud partition.
