Common Policy Over Multiple Use Cases
The use cases presented below and the actual configurations deployed on a production network may vary considerably. More important than the actually policy is the method used to configure the system. The sections attempt to articulate not what to configure, but how to configure and set up the system.
Policy usually addresses three phases of operation, the initial on-boarding, the daily operations, and off-boarding, which includes retiring devices and employees. If each use case were presented over the three phases of operation, there would be 12 distinct policy flows. Because much of the configuration applies to common policy that is shared and applies over several use cases, it is presented here first. Additional highlights immediately follow that focus on what makes one specific configuration element unique to a particular use case.
Supported MDM Functions
Cisco ISE relies on REST API calls to query the external MDM server for additional endpoint information. The communication between ISE and the MDM is mostly unidirectional, where ISE sends different commands to the MDM. Some commands query for device information (model, compliance status, serial number, etc.) while others can invoke an action on the device (Corporate Wipe, Full Wipe, PIN lock, etc.).
The following are some of the functions that ISE performs in conjunction with an MDM server:
Device registration—Unregistered endpoints connecting to the network are redirected to a web page hosted on the MDM server to initiate the MDM enrollment process.
Device remediation—Cisco ISE imposes a captive portal on non-compliant endpoints. The user is redirected to a web page hosted by ISE but populated with device posture information obtained via the MDM API. The page informs the user about actions to take to become compliant.
Periodic compliance checks—Cisco ISE polls the MDM server periodically for a list of non-MDM compliant devices. ISE determines if any device on the list is currently associated with the network and issues a CoA against those devices.
Device instructions through the MDM server—Remote actions can be issued for users’ devices through the MDM server.
The endpoint database is updated with additional information from the MDM server that cannot be collected using the Cisco ISE Profiler. The following device attributes can be obtained from the MDM:
These attributes can be viewed by clicking Administration > Identity Management > Identities > Endpoints, as shown in Figure 3-1.
Figure 3-1 Endpoint Attributes
The integration with an MDM server allows the Cisco ISE to configure policies based on additional MDM attributes. The dictionary attributes can be found under Policy > Dictionaries > MDM > Dictionary Attributes, as shown in Figure 3-2.
Figure 3-2 MDM Dictionary Attributes
Some of these attributes are used in several authorization rules in this design guide.
Integration Process Flow
Figure 3-3 shows the integration process between ISE and the MDM:
1. The device has been on-boarded and the user connects to the BYOD_Employee SSID.
2. Cisco ISE makes an API call to the MDM server to verify that the device has been registered with the MDM.
3. If the device is not registered and is required to be registered, the user is asked to enroll with the MDM. This may include installing the appropriate application from the Apple App Store or Google Play.
4. ISE enforces some device attributes before allowing network access. If the device is not ISE Compliant, quarantine the device (explained below).
5. If the device is not compliant with the MDM policies, quarantine the device.
If the user has been on-boarded and is compliant with ISE and MDM policies, allow the proper permissions based on different rules.
Figure 3-3 Logical Policy Flow
ISE Compliance Check
Once the device has been registered with the MDM, the ISE checks for certain device attributes before allowing access to the network. This can serve as an additional check and the first opportunity to verify some device attributes.
In this design guide, two device attributes were considered as the minimum for devices to obtain access to the network:
Jailbroken or rooted devices—Not allowed into the network.
PIN lock enforcement—Devices without a device PIN lock are denied access.
ISE makes the JailBrokenStatus and PinLockStatus API calls to the MDM to verify these attributes.
A compound condition was defined in the ISE to check for these two attributes. To define this compound condition, click Policy > Policy Elements > Conditions > Compound Conditions, as shown in Figure 3-4.
Figure 3-4 ISE Non-Compliant
Additional dictionary attributes could be added to accommodate the security policies of each organization.
Note At the time of validation, the device manager was not correctly returning the PIN Lock status over the API. As a result, users may incorrectly be placed in Quarantine. As a work around, this rule should be disabled.
MDM Compliance Check
For devices that have been on-boarded and have met the ISE compliance check, an additional API call is made to the MDM to make sure the device has met all the compliance requirements established by the MDM.
If the device is not fully compliant with the MDM, ISE grants access to the Internet and denies access to all internal resources. When the user tries to access an internal resource, ISE redirects the session to a portal, highlighting the steps required to be completed to meet the MDM compliance rules.
ISE makes the DeviceCompliantStatus API call to the MDM to verify compliance. The MDM establishes what conditions result in a device being non-compliant.
Several ISE features play a role in verifying for ISE and MDM compliance before permissions can be applied. Some of them include Logical Profiles, authorization rules, ACLs, and API calls to the MDM to receive endpoint attributes.
The profiling service in the Cisco ISE is able to identify devices connecting to the network to grant the appropriate access to endpoints based on their device type. By collecting attributes of endpoints and grouping them according to their profiles, unique policies may be enforced for specific type of devices.
A logical profile is a virtual container of objects that share a common attribute. One example of a logical profile is a set of devices that includes all tablets or all smartphones. A second example is a set of all Android or Apple devices. For the purposes of this design guide, a logical profile was created to include the devices that are managed by the MDM. This allows the administrator to dynamically add or remove devices managed by the MDM.
Figure 3-5 shows the MDM Managed logical profile used to group devices allowed and managed or licensed by the MDM. This logical profile is used when defining the ISE authorization policy and includes devices profiled as Android, Samsung-Device, and Apple-Device. To configure this logical profile on the ISE, click Policy > Profiling > Logical Profiles.
Figure 3-5 MDM Managed Logical Profile
The logical profile could be easily expanded to include other devices supported and managed by the MDM without modifying the ISE authorization policy.
Figure 3-6 shows the ISE authorization rules used to enforce MDM and ISE compliance. These authorization rules are executed after the user has on-boarded the mobile device and before additional access (e.g., Full, Partial, Internet) to the network is granted.
Figure 3-6 MDM Compliance Authorization Rules
MDM Enrollment Rule
This rule matches when the following conditions are met:
The endpoint connected via a wireless 802.1X SSID.
Logical Profile equals MDM Managed—The device is managed and supported by the MDM.
The device has gone through the on-boarding process and registered with ISE.
The device has not registered with the MDM.
If these conditions match, the Internet Until MDM authorization profile is used. This profile is configured to redirect non-registered devices to the redirect URL highlighted in Figure 3-7.
Figure 3-7 Internet Until MDM
The authorization profile relies on two named ACLs previously defined in the Wireless LAN Controller: ACL_Internet_Redirect and ACL_Internet_Only. ACL_Internet_Redirect is shown as being applied to the MDM Redirect setting in Figure 3-7. ACL_Internet_Only is shown as being sent to the wireless controller via the Radius:Airespace-ACL-Name attribute value (AV) pair in Figure 3-8.
There are slight differences between centralized WLCs and the converged access products that influence the named ACLs. Refer to the BYOD CVD for additional details. The Cisco Mobile Workspace Solution with Citrix CVD covers centralized controllers.
Figure 3-8 ACL Internet Redirect
The ACL specifies the following access:
Allow IP access to and from the DNS server (10.31.1.10).
Allow IP access to and from the ISE Server (10.31.1.32).
Allow IP access to and from the XenMobile AppController (10.31.1.44).
Deny IP access to and from internal network address space (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
Allow access to and from all other subnets (Internet access).
Note The access list shown is generic and not intended to work for every organization. An ACL should be more specific and only allow access to specific IP addresses and protocols in the required direction. A common practice is to make the ACLs as detailed as possible and to define every entry down to the port level.
The first time the user tries to browse an internal resource, the session is redirected to a page similar to the one in Figure 3-9. providing a link to register with the appropriate MDM.
Figure 3-9 Register with XenMobile Device Manager
Remediate Non-ISE Compliant Rule
This rule matches when the following conditions are met:
The connection originated using EAP-TLS authentication (defined as a compound condition, see below).
The device does not comply with ISE requirements.
Logical Profile equals MDM Managed—The device is managed and supported by the MDM.
If these conditions match, the ISE Quarantine authorization profile is used. This profile is configured to redirect non-compliant devices to the redirect URL.
Figure 3-10 ISE Quarantine Authorization Profile
The authorization profile relies on two named ACLs, previously defined in the Wireless LAN Controller: ACL_ISE_Remediate_Redirect and ACL_ISE_Remediate. ACL_ISE_Remediate_Redirect is shown as being applied to the MDM Redirect setting in Figure 3-11. ACL_ISE_Remediate is shown as being sent to the wireless controller via the Radius:Airespace-ACL-Name attribute value (AV) pair.
For centralized wireless controllers, ACL_ISE_Remediate_Redirect functions as both the ACL which controls web redirection, as well as the ACL which controls what the wireless client is allowed to access on the network. CUWN wireless controllers do not make use of this ACL when URL redirection is specified. In designs that leveraged converged access products, two ACLs are required as shown here.
WorxHome requires continuous access to XenMobile device manager and XenMobile AppController to allow users to launch the application. WorxHome depends on XenMobile AppController to authorize users. The application allows users to manually refresh the devices compliance attributes with the MDM. If the user is placed in quarantine, they need this functionality to clear the condition without the assistance of IT. If WorxHome is blocked to either the device manager or AppController, the user must call IT to refresh their device’s compliance status with the device manager or wait an extended amount of time until the normal check-in process completes.
In some environments, the policy may be simplified by removing the ISE compliance condition. In this case, compliance will be an exclusive function of the MDM Compliant attribute. If both ISE quarantine and MDM quarantine result in the same policy results, then a single policy is adequate. In many cases, users can gain Internet only access by using their LTE interface. Internet-only access may be an appropriate result for all non-compliant devices. By having a single policy, the configuration including the number of ACLs can be simplified. This simplification results in easier support and reduced troubleshooting time. This CVD treats ISE and MDM compliance as two distinct outcomes to illustrate the flexibility of the system.
Figure 3-11 ACL_ISE_Remediate
The ACL specifies the following access:
Allow IP access to and from the AppController (10.31.1.44).
Allow IP access to and from the ISE Server (10.31.1.32).
Allow IP access to and from the DNS server (10.31.1.10I).
Allow IP access to and from the MDM server (220.127.116.11).
Allow IP access to Apple Push Notification Server (18.104.22.168 /8 TCP port 5223).
Allow IP access to AppStore (22.214.171.124/8).
Allow IP access to Google Play (126.96.36.199 /8).
Deny IP access (redirect) to all other IP addresses.
Note The access list shown in Figure 3-11 is generic and not intended to work for every organization. Google and Apple both distribute software from servers based on the user’s location. The entries shown above may not work from all locations. An ACL should be more specific and only allow access to specific IP addresses and protocols in the required direction. A common practice is to make the ACLs as detailed as possible and to define every entry down to the port level.
The Wireless_EAP-TLS compound condition checks for the following conditions:
Radius:Service-Type Equals Framed
Radius:NAS-Port-Type Equals Wireless - IEEE 802.11
Network Access:EapAuthentication Equals EAP-TLS
To define this compound condition, click Policy > Conditions > Authorization > Compound Conditions. Figure 3-12 shows how the Wireless_EAP-TLS condition combines several conditions into one.
Figure 3-12 Wireless EAP-TLS Condition
Remediate Non-MDM Compliant Rule
This rule matches when the following conditions are met:
The connection originated using EAP-TLS authentication, as defined by the Wireless_EAP-TLS compound condition highlighted in Figure 3-11.
The device does not comply with MDM policies. The ISE makes the DeviceCompliantStatus API call to the MDM to obtain this information.
Logical Profile equals MDM Managed—The device is managed and supported by the MDM.
If these conditions match, the MDM Quarantine authorization profile is used. This profile is configured to redirect non-registered devices to the redirect URL highlighted in Figure 3-13.
Figure 3-13 MDM Quarantine Authorization Profile
The authorization profile relies on the same two named ACLs: ACL_Internet_Redirect and ACL_Internet_Only previously illustrated in Figure 3-8.
When the user tries to browse an internal resource, the session is redirected to a page that informs the user of the condition and suggests an action for remediation.
For reference purposes, a complete authorization policy including both wireless and wired policy is shown. The BYOD CVD explains the additional components not included as part of CMW. Figure 3-14 highlights the following sections:
1. Used for blacklisting lost or stolen devices.
2. On-boarding and MDM registration/remediation.
3. Wireless devices connecting from an access point in a SGT_Enabled location.
4. Wireless devices connecting from an access point in the campus or branch locations.
5. Wired devices connecting from campus or branch locations.
6. Wired and Wireless devices connecting from a converged location.
7. Guest and Basic Access.
Figure 3-14 Complete Authorization Policy
Setting Device Policy on XenMobile Device Manager
Apple and Android differ in how device management is implemented. Each offers APIs natively in the operating system that the MDM is able to leverage. It is possible to manage basic elements on an iOS device without agent software, although the agent is required for the full set of features. Android does require agent software with device administrator privileges. In the solution as configured in this document, the agent is required to collect attributes ISE uses to establish network access for both iOS and Android devices.
Apple defines profiles, which are an important concept in mobile device management and a foundational component of Apple’s mobile device management protocol that is implemented by the operating system (iOS). This concept can be extended to application profiles, but as discussed here, they are found under the settings of the device. Each profile can contain one or more payloads. A payload has all the attributes needed to provision some aspect of built-in system functions, such as PIN lock. One special payload is the MDM payload that defines the MDM server as the device administrator. There can only be one MDM payload installed on any iOS device. In iOS 5 and earlier, the profile containing the MDM payload cannot be locked and the user is free to delete it at any time. When this occurs, all other profiles installed by the MDM are also removed, essentially resulting in a corporate wipe. The MDM may lock any sub-profile that it installed to prevent the user from removing them individually. The MDM is allowed to inspect other profiles, such as the WiFi profile installed by ISE, but is not allowed to remove any profile that it did not install, including the WiFi profile as detailed in this CVD. Because multiple profiles can be installed on a device and profiles have payloads, it is possible to have a payload collision. Devices with multiple security payloads will install all the payloads by aggregating the most secure settings from each as a logical OR function. In most other cases the first payload is installed and subsequent payloads are ignored or multiple payloads are accepted. For example, the device can have multiple VPNs provisioned, but only one can be named XYZ.
Note Starting in iOS6, Apple does allow the MDM payload to be locked if the user has not set a PIN lock. As presented in the CVD, a PIN lock is required to gain network access.
Android devices generally implement device management functions through a specific set of APIs, most of which are manufacturer- or model-specific. For example, Samsung uses its SAFE API while HTC uses its One APIs.
XenMobile uses policies to create and define device profiles. These policies can then be deployed to the device through the use of packages. XenMobile defines a rich set of conditions that can be placed on the deployment of these packages, including membership in an AD group. For example, a policy can be created for all employee-owned devices called BYOD_Employee.
Figure 3-15 Configure Employee Device Policy
The policy can include password policy or restrictions specific to employee devices. Additional policies can be created for users who belong to either the CMW_Full_Access or CMW_Partial_Access Active Directory group.
Deploying Policy to the Device
After creating these policy resources, deployment packages are used to determine how resource will be applied. Deployment packages are organized in an object tree. The deployment packages in a child object are only considered against devices that fall into the parent deployment package. This structure can be used or organize policy. In the example shown in Figure 3-16, parent packages are set up for employee-owned and corporate-owned devices. The deployment package simply contains a check for the Owned_By device attribute. In most cases, resource specific to all corporate devices or all employee devices are contained in the appropriate resource package for that asset class. Child packages for Full access or Partial access are placed under the Employee Owned resource. The child packages have conditions set to match AD group membership and contain resources specific to that user group. The resulting profiles installed on the device depend both on the device ownership and the user’s AD group membership. The concept of resource package folders is further discussed in Use Case 2—Employee Owned Device with Full Access.
Figure 3-16 Hierarchal Deployment Packages
XenMobile comes preinstalled with two default packages for each of the various supported devices, Base Package and Passcode Package, that can be used to accelerate the initial deployment. However administrators should carefully review the policy each implements to ensure it is appropriate. In many cases, it may be advisable to use the preinstalled packages as templates to create new policy profile, leaving the XenMobile policies unmodified. The example deployment packages shown in Figure 3-16 are used to extend the use cases presented in the CVD and are intentionally simplistic. It is usually a good idea to create specific policies and deployment packages that align with the enterprise organization so that changes can be applied to a targeted group of devices. For example, a change may be required for outside sales employees that would not benefit inside sales employees. This change may be difficult if devices used by all sales employees were initially set up with the same deployment package set.
A deployment package has several common components:
A unique and descriptive package name.
Groups of users to which the package will be deployed. User groups can be either from Active Directory or locally defined user groups.
A resource or list of resources. Resources are the objects that will be deployed by the deployment package, including applications, policy configurations, SharePoint, Application Tunnels, etc.
A deployment schedule that determines when the deployment will occur. This is not the same as time-based restrictions. Generally packages should be tested on a small set of devices before global deployment.
Deployment rules that determine the devices to which the package will be deployed. Deployment rules can be configured with a simple or advanced dialog. Rules can consider a comprehensive list of device attributes that can be combined in any logical combination. Rules can also consider specific user attributes not related to the user group. For example, if a user belongs to several groups, a user attribute can be used to match the user’s primary AD group. To extend the use cases presented in the CVD, only the device Boolean “Owned by” is needed, as shown in Figure 3-17.
Deployment rules are another method to provide a logical hierarchal structure. In this case, the deployment rules of multiple packages include a check for “employee owned”. When using this approach, it is a good idea to code the structure into the name of the package, since the natural tree structure is not readily apparent.
Figure 3-17 Deployment Based on Device Ownership
The complete logic is summarized in Figure 3-18.
Figure 3-18 Deployment Package Summary
With the example configuration shown above, all Active Directory users with a personal device have the BYOD_Employee resource installed, which establishes a password policy on the device. Only devices that match this deployment package are considered for the two child packages, BYOD_Full_Access and BYOD_Partial_Access, that are used to place additional policy on the device based solely on Active Directory user groups. The end device sees two profiles, one because the device is employee owned and the other based on their membership in an AD group.
Policy Deployment During Enrollment
When an iOS device initially enrolls with the XenMobile Device Manager, it gets two profiles. One has certificates that ensure the device will trust the XenMobile Device Manager. The other is the MDM payload that allows the device to receive secure messaging from the push service. The Device Manager requests a device check-in via the push service. The device then contacts the XenMobile Device Manager to complete the check-in request. At this time, the additional deployment packages are installed securely on the device. When integrating with ISE, there are some timing issues that need to be considered and are discussed in WorxHome Client App in Chapter4, “Operations”
Figure 3-19 shows the steps required of a device to enroll with the MDM.
Figure 3-19 Enrollment Network Flows
One of the key components of BYOD is the mix of personal devices and corporate devices on the network and the ability to establish policy based on this attribute. Both the ISE and the MDM have the concept of asset classes, which allows corporate devices to be distinguished from all other devices in the system. Ownership is an important aspect of BYOD. For example, an administrator may not want to issue a full wipe of personal devices or track the location of a personal device. However corporate devices may get full wipes as a matter of normal operation and may be used to track location, especially if travel is a key component of the employee’s job. Having the ability to handle the information gathered from personal and corporate devices differently is important.
ISE determines corporate devices through an identity group referred to as the Whitelist, which contains the MAC addresses of corporate assets. Discovering the MAC address of Android and Apple devices is typically a manual process. Apple lists the MAC on the Settings > General > About page. XenMobile allows devices to be bulk-imported into the system using the device serial number for iOS or Android devices and either the device serial number or IMEI for Android devices. An enterprise may need to create a list of corporate-owned devices by MAC addresses and the associated serial numbers to pre-provision them on both systems. Apart from bulk imports, another option used to automatically mark ownership is device tagging with a script. This is covered in the XenMobile Administrator guide available on the Citrix website. Users can declare device ownership when enrolling a device through the Self-Help portal page.
A device may be provisioned with multiple profiles that contain a restrictions payload. For example, a member of BYOD_Partial gets a restrictions payload that prevents devices from synchronizing documents with the iCloud. They also receive a restrictions payload from the parent group Employee Owned that sets the ISE compliance restrictions, e.g., PIN lock, device encryption, and not compromised. When multiple restriction payloads are installed on a device, the device aggregates the settings by keeping the more restrictive attributes. Since the enterprise-wide policy is for a PIN lock, the child organization groups are not required to repeat the PIN lock requirement and can focus on what makes that profile unique for that particular set of devices.
Table 3-1 Device Policies at the BYOD Subgroup Level for Personal Devices
Application Management with Device Manager
Although specific use cases are assigned applications appropriate to that user, there are a few applications that are better deployed from the Device Manager and not the AppController. The primary reason for doing this is that unlike AppController, the Device manager does not require WorxHome. Device manager also has additional device information such as ownership. Remote access requires AnyConnect as presented in this CVD and is only available to users on corporate devices. Only device manager can make this distinction.
When a user on-boards a device from the WiFi network, they are redirected to XenMobile Device Manager for device enrollment. This workflow includes downloading the WorxHome agent on the mobile device. However it is also possible to enroll iOS devices directly with the MDM using Safari. In this case, WorxHome is pushed to the device after enrollment via an MDM policy. This ensures that all users have access to XenMobile AppController distributed applications.
Cisco AnyConnect is another example of an application that should be deployed from the device manager for two reasons:
First, user deployment may have device dependencies. Deploying AnyConnect based solely on the user’s AD group membership may not provide an adequate policy.
Second, the device manager can remotely provision AnyConnect. In fact, this is an important component of establishing remote access policy. User credentials and connection profiles are provisioned in the same deployment package as the application.
Applications can be deployed from the AppStore or Google play. Before an application can be distributed to devices, it must be provisioned on the console. This requires discovering the URL to the specific application. Neither AppController nor the Device Manager are able to search the stores for the link. A third-party tool such as Google or Bing can be used. Once the link is provided, the Device Manager can pull information about the application, such as its description, into the console. With Apple devices, the link should include the machine type attribute of 8 (mt=8). Android applications should include the application’s package ID that is in reverse domain notation. For example, AnyConnect is com.cisco.anyconnect.vpn.andriod.avf. Figure 3-20 illustrates locating Android and Apple applications.
Figure 3-20 Locate Public Application URL
Adding iOS applications into the device manage console is fairly straightforward. The dialog includes options for Apple’s volume purchasing program (VPP) that was updated as of iOS 7 such that software licenses remain the property of the enterprise and not the iTunes account that exercised the license. Further details are available at:
Adding Android applications to the device manager is further detailed in Figure 3-21. If Google Play credentials are provided to the device manager, then it has the ability to pull application information including descriptions from the store. The credentials must also include an Android ID. The specific ID should associate to the Google Play account used. The console suggests keying *#*#8255#*#* into an Android phone to discover the Android ID. If this is not successful, then Figure 2-75 in Chapter 2, “Configuring the Infrastructure” illustrates using a mobile application on the device to get this information. The dialog allows the store credentials to be stored in the database as they are done on the AppController. This is recommend so that same Google Play account is maintained across all applications and to avoid having to find the Android ID in the future. If the credentials are accepted, then the administrator only has to provide the URL and click the Go button. The device manager populates the remaining data from the Google Play site, as shown in Figure 3-21.
Figure 3-21 Add Android Applications
Administrators can create application categories in the Device Manager to organize the applications. Application categories are not directly used in deployment packages, but assist administrators by organizing applications over platforms. For example, there are several binaries for AnyConnect that cover iOS, Android, and Samsung Knox devices. The administrator uses the pencil icon to edit a category after it has been created. It is also possible to sort the table based on any column. Although it is tempting to use the application name, this is not the best choice because there is not a defined naming convention. For example, application names may be prepended with the company name, which could vary from Google Play or the AppStore. A better choice is the Modified on column. This is because applications that have been updated on the public stores are not automatically updated on the device manager console. By placing the oldest applications on top, administrators can better manager application updates. As with most things, there are some subtleties to be aware of. The console does not distribute public binaries directly. Users are directed to the appropriate store for code. The public store may or may not be distributing the same version of the application as is seen in the console. Furthermore, users update their applications directly with the application store. Because of these two facts, there is no guarantee that end devices are running the version seen in the console. However it is still a good idea to maintain the current version on the console because the description may have changed. Figure 3-22 illustrates application categories and how they can be used to keep applications current.
Figure 3-22 MDM Application Categories
XenMobile Device Manager Provisioned Applications on Android Devices
Unlike Apple devices, XenMobile Device Manager cannot push applications to Android devices. Instead a Web Link is provisioned on the device that the employee can use to connect to the self-serve portal where they can choose from the available applications. Users that meet the requirements of the deployment package have access to a pre-provisioned copy of AnyConnect that includes a settings profile and user certificate. The Web Link to the self-serve portal for Android users is shown in Figure 3-23.
Figure 3-23 Web Link for Android Users
Provisioning Select iOS7 Applications
The XenMobile Device Manager can provision AnyConnect with a wide range of operational parameters, such as the VPN head-end, user information, and tunnel group, because AnyConnect is treated as an Add-On application by iOS, much like Facebook and Twitter. It has additional integration hooks into the operating system not found in the majority of third-party applications. Provisioning traditional applications has required wrapping or developing the in-house application with the Citrix SDK. Starting in iOS7, applications can be developed that support remote MDM provisioning. The feature set is not as rich as the SDK, and the application developer, not the enterprise, determines the number of parameters that may be provisioned on a public mobile app. Although very few public enterprise applications are currently supporting this feature, this is expected to change.
A key offering of Cisco Mobile Workspace Solution with Citrix is the concept that an employee is connected to their data and not their device, which is merely a tool needed to interface with data. An application’s structure enables this. Applications consist of three functional elements that can be abstracted from one another.
Interface—Two common ones are the user interface (UI) and Application Programming Interface (API). Both allow users or programs to interact with the business function.
Function—Every program is written to accomplish a set of tasks. This is the application’s purpose or business function.
Persistence—This layer allows the application’s data to persist over time. Data storage is one aspect of persistence, but the application’s state is another. Persistence allows a user to pick up where they left off. It allows the user to move from UI to UI or from one application to another without losing the ability to interact with their work as they left it.
Each of the three components has residency, meaning it can reside on either the client or server. The servers could be hosted in the cloud and offered as a service. UIs are almost always resident on the client device, but the business function layer and the persistence layer could be either server-based or client-based. Many desktop applications have migrated to the web over time. The browser is the client-side user interface. The application and data reside in the data center. The advantages of this model are clear. Support is simplified because only one copy of the application needs to be maintained. Data is stored in a secured data center where it can be properly backed up and secured. There are two drawbacks: users need to be connected to the Internet and the web application has be scalable.
Mobile devices have changed the model once again. The application’s function moved back onto the device with two main reasons driving the migration: web applications did not display well on the smaller screens and mobile devices offered new context around data not present in desktops, such as GPS location, accelerometers, and cameras. Mobile devices offer touch screens that allow the user to interact with applications in a way not possible with the web browser. Many popular websites developed mobile applications and directed web users to the app store if they browsed to the site on a mobile device. Mobile applications often continue to offer persistence on the server. For example, Facebook does not store user data on the mobile device. In fact, Apple devices do not expose a file structure and Android abstracts their file system. This allows users to interact with their work from any device and any copy of that application.
Server-based persistence enables the mobile workspace. The residency of the application’s function and user interface can vary and this CVD devotes a great deal of time exploring these options. But persistence cannot reside on the client in a mobile workspace. There is a trend starting to emerge that begins to move the mobile application’s function back onto the server with web browser returning as the UI. This is partly due to the overhead involved in maintaining both a web site and mobile application, but also because HTML5 and advances in the Java EE frameworks have enhanced the ability of legacy web applications to display properly on mobile devices. This is especially true for most business applications that had been migrated to a web-based application after the network was installed. What is unique with mobile web applications is the use of a desktop icon to launch the website rather than a bookmark. The user does not need to know the URL of the application. Applications that require high processor power are also well suited to be moved back to the server, such as number crunching applications like MatLab or voice recognition like Siri. The applications that remain on the client tend to be graphically intense such as video rendering, AutoCad, Visio, etc.
XenDesktop applications are a hybrid. The user interface has residency on the server, but is then extended to the device through the use of the Receiver client. Citrix specializes in optimizing the experience. In many cases, users are not aware that the UI is not local. There are some advantages in this approach. First, the entire application stack is maintained and secured in the data center, where it can be supported by IT with minimal effort. Persistence is inherent because Receiver offers a layer of abstraction. The user may be able to disconnect, then later launch another instance of Receiver and re-attach to the previous state of the native UI.
Data persistence is the core of the mobile workspace and ShareFile is the key to providing this service. It can provide a data repository to web-based applications or straight websites to allow users to upload content directly from the web page into the ShareFile service. This is done with the remote upload wizard, as shown in Figure 3-24.
Figure 3-24 Using the ShareFile Upload Wizard
This wizard generates an HTML <iframe> that can be embedded into the website directly or further customized within a Spring MVC based controller. A sample of the wizard’s output is shown in Figure 3-25.
Figure 3-25 Wizard Generated HTML Code
If pasted directly into the website, this particular iFrame allows the user to upload five files less than 2 Gig directly from their PC or mobile device. Note that this wizard does not provide a method to authenticate and authorize users. The website needs to ensure appropriate security measures are in place.
Figure 3-26 Embedded ShareFile Upload Wizard
When browsing to this site with a mobile device, Apple allows the user to upload photos while Android allows photos and access to the pseudo file structure on the device.
Use Case 1—Corporate-Owned Device with Full Access
In many ways, full access is an easy use case to deploy because there are few restrictions. The user is allowed a native workspace on a mobile device. WorxHome is the primary mobile application. All mobile applications are installed directly on the device. The following components are used to deliver this use case.
Network Access—There are no restrictions placed on the device’s ability to access corporate servers. In this use case, the MAC address of the device is found in the corporate white list. As configured here, any device appearing on this list is granted full network access regardless of the user’s AD group membership. In an actual network, policy may be established based on a combination of the whitelist and AD membership. Enrolled uses attaching to the wireless network will match on the ISE Authorization condition shown in Figure 3-27.
Figure 3-27 ISE AuthZ for Corporate-Owned Devices
XenMobile Device Restrictions—Because the device is corporate owned, the enterprise is free to establish restrictive acceptable use policies and enforce those policies with the device manager. This could include disabling the game center, preventing the device from backing up to cloud, and tracking the device’s physical location. These provisions may not be appropriate on employee-owned devices, but users of corporate-owned devices should expect the corporation to impose restrictions on many features not required for work and that could expose corporate data to additional risk.
Figure 3-28 Creating Device Restrictions
The General tab shown in Figure 3-28 requires a unique identifier. The remaining tabs can be left at their default settings or adjusted to match the corporate policy for company devices. Figure 3-29 highlights some items that may be of interest. The Media Content tab is not shown. It prevents movies and TV shows from being downloaded from iTunes.
Figure 3-29 Device Restrictions—1 of 2
Figure 3-30 Device Restrictions—2 of 2
Once the policy is created, it is included in a deployment package that matches corporate devices. An example of this is shown in Figure 3-18 .
On iOS devices, device management is tied to the MDM payload installed when the device was first enrolled. The administrator of the device cannot be prevented from removing this profile and effectively un-enrolling the device. The device will be quarantined the next time it attempts to join the network until the device is re-enrolled.
Application Management—The system imposes blacklisted applications. In this case Dropbox is used to illustrate this capability by restricting its use on corporate devices. Conversely, the following applications are considered required and are pushed to all devices: Cisco Any Connect, Citrix ShareFile SaaS, and Citrix Receiver. Some application are available for users to optionally download from the Citrix StoreFront, including Jabber, WebEx, and Evernote. XenDesktop users have Notepad, Paint, and Calculator installed on their desktops, which are also accessible from Citrix Receiver installed on mobile devices.
Although the device manager can manage applications, AppController is the primary App Management tool for mobile applications and the only tool to deploy Windows-based applications on a mobile device. This is useful when a user wants to leverage the same application that is used on a PC. Some enterprises have also chosen to deploy AppController as a migration tool for in-house Windows-based client applications on mobile devices. Often this is easier than mobilizing the legacy in-house windows application.
Before applications can be deployed to devices natively, they must be added to AppController. Applications deployed virtually through StoreFront are not added to AppController. Instead they are available over the integration with XenDesktop.
Adding Applications to AppController
There is a wide range of applications that AppController can manage, but only a subset are covered here including public applications, SaaS applications, Web Links, and a discussion of custom applications. Prior to installing Android applications, the administrator should have added Google Play credentials, as shown in Figure 2-76 in Chapter2, “Configuring the Infrastructure”
Note Web Link is a generic term used by AppController to refer to both Web Clips on iOS devices and Web Shortcut on Android devices.
Applications can be organized into categories, which assist users in finding appropriate applications when they visit AppController either with WorxHome or Receiver. Categories can be added, as shown in Figure 3-31.
Figure 3-31 Add Application Categories
AppController defines roles to add a layer of abstraction between users and applications. Roles are used to support use cases and are created, as shown in Figure 3-32. Users and applications are assigned to a role. Roles are not formed around the device and because of this, device properties are not a factor when assigning applications. Therefore there is no distinction between corporate devices and personal devices with respect to application distribution. Applications are assigned to users, not devices.
Figure 3-32 Add Roles to AppController
Applications can then be added to a role, as shown in Figure 3-33.
Figure 3-33 Assign Applications to Roles
Information Management—Full-access employees using a corporate device use Citrix ShareFile to access corporate data. Within this CVD, there are three folders provisioned on ShareFile: Top secret, Internal Only, and Public. Each folder has either native access or virtual access. Virtual access is provided through the Receiver client. Full access users are provided both read and write access to all folders.
When considering storage, user-generated data and group-distributed data can be thought of as two distinct models. Data generated by the user is the result of an application. The application may be client side, such as the device camera, or it could be server side, such as interfacing with a web service. A third model is the hybrid where client software is executing in the data center via XenDesktop. User-created data is inbound. Contrast this with group-distributed data. Here information is published to a target user community. Restrictions may be placed on re-sharing this content.
When ShareFile is integrated with WorxMail, email attachments can be removed from email and placed into ShareFile. This allows the content to come under management so that policy-limiting distribution can be imposed.
ShareFile uses distribution groups to manage the dissemination of content.
Desktop Virtualization—For Corporate Devices, it is assumed that the primary use case for access to a XenDesktop session is to provide access to corporate, Windows applications that may not be available for mobile devices and perhaps incompatible with MAC OS. Unlike personal laptops or Macbooks, corporate computing assets would typically be under strict administrative control, ensuring that these systems are continually updated with the latest OS updates and AV signatures as well as Active Directory Group Policy Objects (GPO) restricting system modification by the employee. As such there may be less reason to make use of Desktop Virtualization due to security concerns of the posture of a laptop or MacBook accessing the network.
Corporate devices when accessing XenDesktop are granted a session enumerated by a server assigned to the CMW_Full_Access Delivery Group. The ESXi servers that make up that Delivery Group may reside in a VLAN secured by the appropriate ACLs or identified by a corresponding TrustSec Security Group Tag ensuring the correct policies are enforced to provide access to the network and data center resources users accessing these XenDesktop sessions require.
Figure 3-34 provides a sample of the CMW_Full_Access hosted shared (virtual) desktop.
Figure 3-34 XenDesktop for Corporate and Personal Devices with Full Access
Cisco AnyConnect is installed on corporate devices during the onsite onboarding process. The Citrix XenMobile Device manager provisions AnyConnect, including a certificate that is used in addition to the users credentials supplied by the user at the time of connection. No ACL is applied to the user’s remote session. Users continue to use native applications while attached to the VPN head end.
There are several components that need to configured to provide MDM provisioned remote access:
XenMobile Device Manager—Provisions AnyConnect with correct user settings and certificate.
Advance Security Appliance (ASA)—Provides head-end SSL termination for AnyConnect. Validates user certificate.
AnyConnect—Client application providing SSL service to the device. Can use split tunnels and on-demand connections.
ISE—Authenticates users against AD and downloads ACL to the SSL session.
Note AnyConnect requires an additional mobility license on the ASA. In addition, the ASA must have a boot image of 8.0(4) or later.
Configure XenMobile Device Manager to Provide Remote Access
The device manager accomplishes three tasks:
It pushes AnyConnect to iOS devices and offers AnyConnect to Android users.
Obtains a user certificate from the CA via SCEP.
Provisions AnyConnect with a connection profile appropriate to the asset class.
As mentioned earlier, distinguishing between personal and corporate devices provides a use case that illustrates the flexibility of the system.
The Device Manager was configured for SCEP earlier as part of configuring the infrastructure. The steps shown in Configuring SCEP Between Device Manager and the Microsoft CA Server in Chapter 2, “Configuring the Infrastructure” should be completed before proceeding with this section.
Two deployment packages are created, one for iOS devices and one for Android. Although AnyConnect can also be provisioned on desktop devices, these devices are not considered here. There are slight variations in the profiles deployed to each device.
Create a Profile for iOS Credentials
This profile must be created first and is used to bind the user certificate to AnyConnect.
Figure 3-35 Create Profile with Credentials
The profile is given a name and the credential provider named payload as shown in Figure 2-199 in Chapter 2, “Configuring the Infrastructure” is bound to the profile. This is shown in Figure 3-36.
Figure 3-36 Setting the Credential Provider
Create a VPN Profile AnyConnect on iOS Devices
The profile sets the VPN head-end address, connection profile, and user certificate, as shown in Figure 3-37.
Figure 3-37 AnyConnect Provision Profile for iOS
There are several fields that are important:
User account—The brackets indicate a substitution will take place; $USER will be replaced by the user account associated with the profile.
Group—This is the connection profile to which AnyConnect will attach. The ASA passes this information to ISE and it is included to determine the appropriate network access level. See Figure 2-199 in Chapter 2, “Configuring the Infrastructure” to confirm the ASA is configured with the group, although note that Figure 2-199 is not specific to the Corporate use case and shows the profile connection for Citrix_EmpOwned rather than Citrix.
Identity credential—This is a device profile that was created in the previous step and illustrated in Figure 3-36.
A deployment package is now created to deploy the AnyConnect application, the user certificate, and the AnyConnect profile. The profile must be in place when AnyConnect initially launches after installation. AnyConnect must be installed by the MDM to be considered a managed application. Figure 3-38 shows the deployment package.
Figure 3-38 AnyConnect iOS Deployment Package
In step 3 of 6, the order in which the resources are listed is important. Use the up and down arrows to move resources around to ensure the user certificate is pushed to the device prior to the profile that depends on it.
In step 5 of 6, these deployment rules effectively tie the device to the connection profile on the ASA. Policy in ISE should assume users that attach to the ASA Connection Profile contained in the AnyConnect resource have met these conditions.
Step 6 or 6 is a final check of the deployment package and should be reviewed prior to submitting the package.
Providing Remote Access for Android Users
Provisioning AnyConnect for Android devices is similar to the method used with iOS devices. However there are a few key differences. First, as mentioned previously, the MDM cannot push applications to Android devices. Users instead visit the XenMoblie Device Manager self-service page, which was provisioned as a web link on their desktop. Second, there are multiple versions of AnyConnect. AnyConnect ICS+ is for Ice Cream Sandwich or version 4.0 and greater of the operating system that is built around the Android VPN Framework (AVF). There is also a version available for Samsung Knox devices that provides additional capabilities. Figure 3-39 shows both the AnyConnect VPN profile and the deployment package summary. Figure 3-39 happens to show the Citrix_EmpOwned ASA Connection profile that would be deployed to employee-owned devices. Although this applies to the use case covered in Use Case 2—Employee Owned Device with Full Access, it is included here to allow an easy comparison of the key functional component. While ISE can make decisions based on the users AD group, the MDM can influence policy by provisioning a specific AnyConnect connection profile.
Figure 3-39 Provisioning AnyConnect on Android Devices
Use Case 2—Employee Owned Device with Full Access
There are two components to risk assessment.
User access to the corporate network
The degree to which the device is managed and trusted
While corporate devices are tightly controlled, there are limitations to the controls that can be placed on employee-owned devices. For example, disabling the camera on an employee’s private phone would be met with resistance and most likely the employee would not participate in the corporate sanctioned program. The user may be motivated to explore other non-approved methods to gain network access, such as reverse tethering to a wired laptop. Yet before a personal device is allowed on the corporate network, the enterprise needs some assurances that the employee has used good judgment to minimize risk. Common sense approaches include configuring a PIN lock on the device. The device should lock after some idle time has passed. While there is a small inconvenience in having to unlock the device each time before use, the tradeoff is acceptable because the enhancement to security is tangible. However there are some limitations. If the passcode requirements are overly complex, then users may opt out of the program. The user may not be willing to provide an eight character passcode, including uppercase, lowercase, numbers, and special characters every time they want to send a personal text.
A key component to employees using personal devices at work is a clearly written and detailed acceptable use policy that the employee should agree to prior to using their device at work. The agreement should specify any restrictions placed on the user of the device, any applications on the device, and corporate content. There should also be policy established on sharing a device with family, friends, and other employees. Finally companies should detail how retired devices should be handled prior to product upgrades. Obviously employee should not sell their old phone until all corporate data has been removed. Administrators are encouraged to further research this topic prior to allowing personal devices on the corporate network. Having considered these issues, the following system configuration was used to support full access users on personal devices:
Network Access—Cisco ISE can establish network access based on both the device’s asset class and the user’s AD group membership. Personal devices are not included in the corporate whitelist. This fact and the users AD group membership established the network policy. In this situation, the user’s AD group membership is “full access” and therefore no ACL is placed on the device’s connection. However this does not mean that corporate and personal devices are treated the same. Cisco ISE checks with the MDM for device compliance. The conditions that set that flag are dependent on the device policies that are applied to that device. ISE policy establishes corporate devices by checking the MAC address against a whitelist. All devices not in the white list are assumed to be personal devices. In the ISE policy stack, assumptions are allowed to fall through known conditions. In other words, the policy statement matching corporate devices against the white list should be higher in the stack. Policy statements below this line apply to non-corporate devices such as guest, employee-owned, or contractor-owned. There is not a statement to match employee-owned devices because there are various possible outcomes based on the users’ AD group membership. Each possible outcome requires a specific match. Figure 3-40 illustrates the basic BYOD policies for devices. Corporate devices match the whitelist with no regard for AD membership. The second and third lines are those devices not in the whitelist where the policy is determined exclusively by the AD group membership. There are two possible outcomes, with the top and bottom statement both resulting in full access.
Figure 3-40 Core BYOD Authorization Policy
XenMobile Device Restrictions—Employee-owned devices could be a challenge to adequately cover in a specific use case because individual organizations will have unique policies with respect to their use. As presented here, personal devices are not held to the same restrictions as corporate devices. Users are free to use the camera, play games, or check their Twitter feed. It is assumed that the employee will use their personal device responsibly, however there are some basic restrictions that are placed on the device. For example, a PIN lock must be set and the device cannot be compromised. This use case also defines a set of blacklisted applications. While it is not possible to prevent the user from installing a specific application on their device, we can set a compliance condition when that application is found on a device. This is not the same as NAC compliance that is used by ISE. Instead, the device manager can respond directly to non-compliant conditions by installing additional profiles that further restrict how the device is used when a specific application is present.
When establishing device policy, it is helpful to think how the device manager organizes its policy. There is a pool of defined policy statements that is separate from the deployment packages. Deployment packages can deploy multiple policies, which are also known as payloads. The deployment packages are organized in a hierarchal tree where a child package is dependent on its parent’s deployment. Some payload types can be combined. For example, it is possible to deploy multiple restriction payloads. When this happens, the restrictions are combined so that the more restrictive setting is in effect, which can be quite useful.
There are some device restrictions that are imposed on all devices, including the requirement for a PIN Lock and that the device is not compromised. A specific profile should be set up for these base restrictions. Additional restrictions can be layered on top of these for full access devices and another for corporate devices. By having targeted profiles, changes can be made without the need to change duplicate settings over multiple profiles. For example, if the PIN Lock requirement is updated and there are multiple profiles with a PIN Lock setting, then each profile needs to be changed. However if base restrictions are layered with other restrictive profiles, then changes to the PIN Lock only need to be modified in a single profile.
Figure 3-41 Combining Targeted Restrictions
As shown in Figure 3-41, a single deployment package contains all of the targeted restrictions for this particular use case. When the user views the profiles on their device, they see a profile for each payload. The profiles should have descriptive names that help the user quickly understand what benefits the profile provides. One downside is that there may be another package for EmpOwnPartialAccess that the administrator may need to manage and maintain that has many of the same payloads. If policies for employee devices are updated, then there may be multiple packages impacted. This is a fairly flat package architecture, however XenMobile allows deployment packages to have structure. In this case three deployment packages are used, each at a layer in the hierarchy, to deploy the same effective policy. However the policy is structured and can be easily maintained and updated. Users have a profile for each deployment package on their phone. The payloads within the packages should be marked as non-removable.
Figure 3-42 Structured Deployment Packages
The administrator should be aware that unless an iOS device is in supervised mode or an Android device is in kiosk mode, the user of the device is the device administrator. In this role, they can remove remote management from the device by deleting the MDM profile (iOS) or disabling the MDM as a device administrator (Android). However this effectively is a corporate wipe on the device and removes all content placed on the device by the device manager. It does not remove the user’s access to ShareFile or Web Receiver. Figure 3-43 shows the profiles that are installed on an employee-owned device with full access, including the webclip for Adobe reader placed on the device to support XenDesktop virtualized Windows applications.
Figure 3-43 Installed Profiles
Application Management—Full access users on personal iOS devices have AnyConnect pushed to their device from the device manager. The remaining applications are available for inside of WorxHome via AppController. These applications would be considered essential for using the device in a productive way while at work and include Cisco Jabber, Cisco Webex, and Citrix ShareFile SaaS. In many situations, the list would also include in-house applications that were developed by the enterprise to accomplish a core business function. Receiver is set as a mandatory AppController application that is installed on mobile devices from the device manager over the integration between device manager and AppController. An example of this setup is shown in Figure 3-44. Note that only the URL needs to be provided. The remaining required fields can be pulled from the AppStore. The roles listed in the drop-down menu were set up while configuring the infrastructure.
Figure 3-44 Adding Mandatory Applications to a Role
Applications added directly to AppController install natively on the mobile device. Once Receiver is installed on the device, it becomes possible to launch public applications from StoreFront that run virtually, including native Windows applications. All of the applications are available from the WorxHome client. When native applications are installed, they are placed directly on the desktop and execute locally on the device. When StoreFront applications are installed, they are installed to the MyApps page in the in the Work Home client and launch through Receiver. In addition, a desktop icon is installed that links back to WorxHome via a web clip. The following illustrations highlight this concept. Figure 3-45 shows the WorxStore found inside of WorxHome where a mix of virtual applications from StoreFront and outlined with a red box are shown together with native applications provisioned from the AppController. The MDM self-service portal applications are not listed here. Also notice a + symbol under applications that have not yet been installed by the user.
Figure 3-45 WorxStore with AppController and StoreFront Apps
Figure 3-46 shows the Adobe Reader Web Clip that contains a pointer associated to the Work Home client application. Users may need to be educated that some applications redirect to WorxHome.
Figure 3-46 StoreFront Web Clips
When the user clicks open, WorxHome launches, which hands over to Receiver to support the virtual application, as shown in Figure 3-47.
Figure 3-47 Launching Virtual Applications from the Desktop
AppController provides distribution policy through the use of roles for native applications. Roles are tied back to AD group membership. StoreFront also ties into AD, but uses delivery groups as explained in the Delivery Group Creation in Chapter2, “Configuring the Infrastructure” When two or more virtualized applications are run at the same time, they appear in the same window on the same desktop pane.
Information Management—Personal devices have additional concerns with respect to being lost or stolen. They are also more likely to be resold without the enterprise’s knowledge, so the data that is physically placed on the device needs to be tightly controlled. In this use case, ShareFile is installed on both corporate and personal devices. But in the case of personal devices, users are not permitted to access the top-secret folders natively in ShareFile. Instead these users follow a shortcut placed on a virtual desktop. The data is restricted such that it cannot be taken off the virtual server located in the data center. Public content may still be accessed directly on ShareFile.
Desktop Virtualization—In the case of employee personal devices with full access, the applications essentially are the same as the corporate devices. Here in a typical installation however, access to additional Windows applications may be more commonplace as the employee’s personal device is most likely less secure than a corporate device. As such, direct access to some applications and databases may be restricted and only accessible through a virtual desktop.
It is anticipated that the same ACLs and or SGT assignment would be applicable to these personal devices as corporate devices and as such the same Delivery Group, “CMW_Full_Access”, is used for the XenDesktop sessions.
Figure 3-48 provides a sample of the “CMW_Full_Access” hosted shared (virtual) desktop.
Figure 3-48 XenDesktop for Corporate and Personal Devices with Full Access
Remote Access—Today the ASA cannot directly distinguish personal devices from corporate devices. AnyConnect can pass RADIUS back to ISE, but the content of certificates remains local. There are still possibilities to differentiate access for personal and corporate device. The easiest approach uses the MDM to provision two distinct AnyConnect profiles. In the simplest form, the group key is unique for personal and corporate devices. Other options involve dedicated head-ends. The group key is shown in this CVD to restrict the idle time for personal phones such that these devices idle out faster than a corporate device authenticates to the same AD account. It is possible to also place access restrictions but as these use cases are defined, full network access is common to both asset classes. Administrators following the example used here should easily be able to adjust the use case to meet their specific needs.
Use Case 3—Employee Owned Device with Partial Access
In many ways, this uses case extends Use Case 2—Employee Owned Device with Full Access. The CVD does not present a scenario where a corporate device would be limited to partial access, although it is certainly possible to configure this outcome. Corporate devices are defined by two conditions:
The mac-address is listed in the ISE whitelist.
The XenMobile device manager attribute “owned by” is set to corporate.
All devices not matching these two conditions are considered employee-owned. Authorization for devices is set based solely on the user’s AD group. In this case, membership in the AD group BYOD_Partial access is enough to establish the appropriate device and network policy. AppController and ShareFile are not aware of a device’s asset class and do not distinguish when a specific user is on a corporate or personal device. When this policy is in effect, the following conditions are applied:
Network Access—By definition of the use case Partial_Access, users have an ACL applied to their network connection that restricts their access to some corporate resources. The most common approach is denying IP destination addresses. While not shown here, the policy could also block based on port number affecting a specific class of traffic, for example VPN. That would prevent the user from gaining access to some corporate resource and then from there establishing a connection to some unknown location, such as their home network. Of course, the partial access granted in this use case is conditional on information obtained from the Citrix XenMobile MDM server.
There are two components that require attention. First is the ISE policy to ensure that network access is properly assigned. Figure 3-40 shows a typical policy. Notice that the policy statement for partial access is below the match for corporate devices, but above full access for personal devices. If a user is erroneously in both Full and Partial AD groups, then the most restrictive match occurs first. This means that to get full access, the AD group membership must contain full and must not contain partial. When ordering policy, consider how unexpected conditions such as this will be handled.
XenMobile Device Restrictions—Because the device belongs to the user, only the minimal set of restrictions is placed on the device as needed to protect corporate interests. In addition, the device is restricted from accessing secured and sensitive subnets on the network. As discussed in the last section, multiple payloads can be combined.
In some environments, administrators may choose not to put the device under management and instead offer only virtual access through the Receiver client. In this situation, the administrator should consider deploying the “Basic” access use model detailed in the BYOD CVD. This model establishes a “guest-like” SSID to partition non-managed devices from the network. Another option is to enroll the device in ISE, but not the MDM. The ISE configuration would be adjusted to include AD group membership as a condition for MDM attribute checking.
The specific policy applied to personal devices used by partial access users varies based on corporate policy. The design guide does not make a recommendation as to what restrictions are appropriate. Instead only the general recommendation that additional network access should be accompanied by tighter device restrictions is made in this guide. The platform does allow a structured policy to be created and applied, as discussed in Chapter2, “Configuring the Infrastructure”
Application Management—As mentioned, the XenMobile AppController does not distinguish application policy based on the XenMobile device manager Owned By attribute. Instead Active Directory is used to create roles and applications are assigned to these roles. Users that belong to the AD group Partial_Access have access to the same applications on both their corporate and personal devices. This is not a limitation. Access to applications is almost always based on user credentials and is usually not a factor of the specific device.
Information Management—Citrix ShareFile is the primary tool to manage secure content. ShareFile policy is the same for all devices used by an employee in the Partial_Access AD group. Sharefile uses distribution groups to establish content policy. Although not discussed in this design, it is possible to synchronize distribution groups with the corporate Active Directory structure. The specific distribution groups are less likely to be tied to Active Directory and more likely to be dynamic based on a specific project in which a user is engaged. Some distribution groups may be established for long periods of time, while others may be rather short lived. People may join and leave distribution groups depending on what is appropriate for their active projects.
Desktop Virtualization—For employee-owned devices with partial access, again as in the case of personal devices with full access, it is anticipated that these devices are a greater security risk and hence access to many corporate applications are either completely inaccessible or, if available, only through the use of XenDesktop. For these devices access to only a handful of corporate applications for employee convenience would be made available and restrictions enforce limiting network access through the use of ACLs and or SGT assignment.
Personal devices with partial access have access to XenDesktop sessions enumerated from the “CMW_Partial_Access” Delivery Group. The servers that make up this Delivery Group would be in a different security zone from the servers servicing the full access group, which would be subject to more restrictive network policies.
Figure 3-49 provides a sample of the “CMW_Partial_Access” hosted shared (virtual) desktop.
Figure 3-49 XenDesktop for Employee Devices with Partial Access
Remote Access—Partial access users on employee-owned devices applications are provided remote access via the same mechanism discussed for employee-owned, full access devices. The device manager provisions a profile specific to the asset class on the device. When the user attaches to the head-end, the ASA passes the tunnel group and user credentials back to ISE, where a policy decision is made. The policy result may include access restrictions that can be bound to the user’s session.