The workflow that users must complete to on-board their device is set by the ISE policy. As presented in the CVD, the user first on-boards with ISE. When the user first joins the BYOD_Employee SSID, ISE checks the device’s MDM Registration status through the MDM API. If the device is not registered, then a captive ACL is activated. This ACL allows Internet access, but captures any attempts to access corporate resources. A full explanation is provided in the CVD. The device requires Internet access to complete the MDM on-boarding process, including downloading the client application from either Google Play or Apple’s App Store. When the device is captured, the user is presented with a screen that includes two buttons, as shown in Figure 4-1. The first redirects the client to the MDM registration page. The second button issues a CoA to force a re-evaluation of the AuthZ policy after MDM enrollment completes.
Figure 4-1 MDM Redirect for Enrollment
When the user lands on the XenMobile registration page, they are asked to choose their platform type. This allows the system to direct the client to the proper location to download the client applications. XenMobile version 8.0.1 directs the user to download both the WorxHome application and the Enroll application. Figure 4-2 shows the platform options available to the user. Note that in the current version of the CVD, only Apple iOS and Android devices are supported even though Citrix supports a wide range of mobile devices.
Figure 4-2 XenMobile Platform Selector
After the user launches the Enroll mobile application, they are asked for their credentials and the server to which they wish to connect, as shown in Figure 4-3. Server information should be provided to the user prior to starting the enrollment process. If the user successfully authenticates, a profile including the MDM payload and associated certificate is installed on the device. The user is led step by step through the enrollment process. The final step verifies the mobile device can establish a secure session with the XenMobile Device Manager.
Figure 4-3 XenMobile Enroll Mobile Application
After enrollment, the user returns to the page shown in Figure 4-1 and clicks the Continue button, which notifies ISE that the user has completed the MDM enrollment process. ISE responds by issuing a change of authority (CoA) to the device, causing the device to re-authorize. This time, the MDM should respond that the device’s status is now “enrolled”.
While this is occurring, the XenMobile Device Manager pushes a check-in request to the iOS device through APNS. During this initial check-in, additional profiles, applications, or Web Clips are provisioned on the device. Web Clips are HTML bookmarks that are displayed as application icons on an Apple mobile device. Android devices simply call these bookmarks.
iOS devices will attempt to auto-join networks, including the provisioning network even after the device has previously enrolled. Most users continue to re-enroll the device with ISE, which only provisions the WiFi settings on the device including a new user certificate. During this time, the device remains enrolled with the device manager and policy remains in effect. If this policy includes a restriction against installing third-party profiles, then the user will not be able to complete the re-enrollment process with ISE and the previous WiFi profile will remain. It most situations, rejoining the provisioning SSID is uncommon.
iOS devices use the following decision process when auto-joining a WiFi network:
1. Connect to the previously joined secure network.
2. Connect to any known secure network preferring the most secure.
3. Connect to an unknown secure network preferring the most secure.
4. Connect to a HotSpot, EAP-SIM or Captive network.
5. Connect to an unsecure or open network.
iOS prefers EAP, WPA, WEP, in that order. Where two SSIDs have the same security, the stronger RSSI is chosen.
Note When iOS initially boots, the device must be unlocked before the device attempts to join secured or non-secured WiFi networks
WorxHome Client App
With Apple devices, the majority of MDM features are implemented directly through the operating system and do not require a mobile device client application. However some of the advanced functionality does require a client running on the endpoint. In particular, jailbreak and rooted detection requires WorxHome client as does location-based policy. The WorxHome client application is installed on mobile devices during the enrollment process. It is recommended to mark WorxHome as a required application in the event that the user inadvertently deletes it.
In addition to providing specific device information, the client application offers the end users some useful troubleshooting information, including application logs that users can use to monitor the client’s interaction with the server. Users can also use the WorxHome application to determine their geographical location. If location services are enabled, this is also the location provided to the server. The XenMoble Device Manager can use location to establish geo-fencing and location-based policy.
One useful feature of the client application is the ability to manually refresh the device’s posture to the server. The need arises when the device has been placed in MDM quarantine due to a compliance violation. For example, the device may not have a PIN lock when one is required. When the user configures the device with a PIN lock, the phone’s OS does not trigger an update to the MDM agent. The agent detects the change during the next security scan interval. The server only discovers this the next time the device is polled. This could result in ISE continuing to place the device in quarantine ever after the user has corrected the issue. Rather than waiting for the MDM to poll the device for an update, the user could use the mobile application to send the current data to the server. Figure 4-4 shows the refresh button on the mobile client.
Figure 4-4 Manually Refresh Server Data
The WorxHome client also serves as the container for AppController and performs authentication tasks for managed applications. It also directs StoreFront application to Citrix Receiver.
When installing the WorxHome client, the user provides the Device Manager URL and user credentials that are authenticated by the device manager, typically through Active Directory integration. However once installed, WorxHome users authenticate against XenMobile AppController. If the user attempts to enroll the device off campus, where access is available to the device manager, but is not available to AppController withouth AnyConnect, the user will successfully authenticate initially, but will see an error message after the installation completes. When this occurs, the device has been enrolled successfully with the device manager and depending on policy, may have AnyConnect provisioned and pushed to iOS devices. AnyConnect can then be used to launch WorxHome. Modifications to the ASA or the use of NetScaler Gateway can be used to eliminate the requirement for VPN access for remote enrollment.
Cisco ISE provides a logging mechanism that is used for auditing, fault management, and troubleshooting. Several reports provide information related to endpoints. In Figure 4-5, the Mobile Device Management report shows the endpoints connected to the ISE and several attributes collected from the MDM. Other reports provide additional information that may be used for reporting and troubleshooting.
Figure 4-5 MDM Reports Available on ISE
Lost and Stolen Devices
A benefit of this solution is the ability to secure devices that have been lost or stolen. Both are serious situations, but they are treated differently. Lost devices may eventually be found, but quite often the user is slow to report the device until they are confident the device is really lost. Stolen devices are often more obvious. There may be other stolen items or the device is not where it was last left. Of course, some devices are lost and then stolen and these are the most serious due to the delay. Of course users are required to report lost devices immediately, but know the procedure may take longer to research than looking for the device one more time. In an effort to reduce the amount to time before a user decides to report a device lost, the user is provided a self-service location where they can inactivate the device on the network and later reinstate the device after it has been discovered, without having to launch a support case with security or IT. The user can also issue selective wipes to remove corporate data and managed applications. For this to be effective, the user must know intuitively how to do this without having to search the company website. One approach is to provide a desktop web clip to the self-help websites for ISE. There are other portals the administrator can use to sanitize a device that are not user reversible. Each provides specialized functions to manage security. There is some integration of select features across portals, which is discussed in the next section.
The ISE user portal allows users to self-report lost devices and prevent that device from joining the corporate network. ISE can also request the MDM remove corporate data from the device.
The BYOD CVD has an entire chapter that covers lost and stolen devices and what is required. The components that integrate with the user workspace and XenMobile Device Manager are included in this design. Enabling blacklisting devices on ISE, Endpoint protection services, and ISE Authz rules are not covered in this design.
ISE My Devices Portal
Using the My Devices Portal, employees are able to mark any of their devices as lost to prevent further network access. The portal requires user authentication and displays the devices that have been added or registered by the employee. The My Devices Portal may be accessed from the URL:
In addition to being able to report a device lost or stolen, the portal is used to enforce MDM Actions, such as PIN lock and device wipes through MDM integrations. Figure 4-7 shows the My Devices Portal page.
Figure 4-7 ISE My Devices Portal
The portal displays devices assigned to the employee or previously registered using the self-registration portal.
Reporting a Device as Lost
The employee is able to edit the device’s description and report a device as lost, as shown in Figure 4-8.
Figure 4-8 ISE Self Reported Lost Devices
Before blacklisting a device, ISE displays the warning shown in Figure 4-9.
Figure 4-9 Blacklist Warning
Once the device is marked as lost, the device is added to the Blacklist Identity Group. If the device is connected to the network at that time, ISE issues a Change of Authorization (CoA) and forces the device off the network. To verify that the device has been added to the Blacklist Identity group, click Administration > Identity Management > Groups > Endpoint Identity Groups and review the Blacklist. Figure 4-10 shows the MAC address added to the Blacklist.
Figure 4-10 Blacklist Identity Group
PIN Lock and Device Wipes
The integration with an MDM provides additional device control to the user. With the My Devices Portal, the employee is able to:
Initiate a Corporate Wipe—Remove settings and applications configured in the MDM policies.
Initiate a Full Wipe—Remove all information from the device (factory reset).
Enforce a PIN lock—Lock the device.
Figure 4-13 shows the MDM actions available from the My Devices Portal.
Figure 4-13 MDM Actions from My Devices Portal
Managing Lost Devices with AppController
Both AppController and Device Manager can lock and wipe lost or stolen devices, but do so in a slightly different fashion. AppController is discussed in this section and the Device Manager is covered in Securing Lost Devices with Device Manager.
AppController issues locks and wipes specific to applications that are accessed by either the WorxHome client or Receiver. Although AppController and both a lock and wipe feature, it is better suited for lock while wipes are better accomplished on the Device Manager. To lock AppController managed applications, the administrator navigates to the devices tab in the console and locates the device. One approach is to search on the user name. Where a user has multiple devices, the administrator must determine which device has been lost. This maybe be challenging if the user has left the device name as the default. AppController adds a sequence number behind devices with the same name. This name can be see in the WorxHome client application by viewing the account information. Figure 4-14 illustrates how to lock a specific device. This is not a device lock and the user retains access to all applications outside of AppController, including any installed by the Device Manager. Locking applications is an administrative function. Users do not perform this action because AppController does not provide a self-help portal.
Figure 4-14 Locking Applications on AppController
AppController does not have native push access to iOS devices, which means locks are not pushed to the device. However WorxHome always authenticates back to AppController any time an application is launched. Therefore a lock is effective immediately and a user is able to gain access to applications. If WorxHome does not have reachability to AppController because the device is remote, then a connectivity error is displayed if the user launches WorxHome. As configured in this CVD, remote users need to connect to the corporate network using AnyConnect before they have access to WorxHome. Figure 4-15 shows the screen a user sees if they attempt to access WorxHome applications after their device has been locked on AppController. The user still sees the installed applications, but they will not launch. The administrator can unlock a device following the same procedure used to lock it. Locked devices are easier to find using either the username search or the locked tab on the left. Devices that are locked are indicated by the padlock icon, which represents the action that will be performed when selected. If a device is currently locked, the icon displays a padlock that is unlocked.
Figure 4-15 WorxHome Locked Message
Securing Lost Devices with Device Manager
The device manager is the primary tool for securing devices after they have been lost or stolen. It can reach devices on campus or off campus and remove all corporate data, applications, and profiles. After a device is wiped, the device manager can be set to disallow the device from re-enrolling with the system. This would be the case if an employee using their personal device or a contractor were no longer with the organization. As explained earlier, wipes can be full wipes or selective wipes. Full wipes erase all data on the device and return it to its factory settings. Normally only corporate devices are fully wiped and only after an acceptable use policy has been agreed to be the user. Selective wipes, also referred to as corporate wipes or partial wipes, only remove managed applications and profiles. WorxHome is left on a device after it has been selectively wiped. For a device to be managed by the device manager, the user must have selected to enroll the device during the enrollment process, as shown in Figure 4-16. If the user chooses No, then the device is not managed and can not be selectively wiped.
Figure 4-16 Enrolling with Device Manager
Because of the policy deployed on ISE in this CVD, devices that are not enrolled are not allowed access to corporate resources on the network. To prevent users from enrolling only in AppController and not in Device Manager, the administrator should require Device Management. This is done from the AppController console, as shown in Figure 4-17. When this option is checked, the user is not offered the option of not enrolling. This is the recommended setting when using ISE to secure the corporate network.
Figure 4-17 Require Device Manager Enrollment
Devices that are enrolled with the device manager can be wiped from the device manager console. When preforming Device Manager wipes, it is helpful to understand how the various components of XenMobile interconnect. Figure 4-18 shows a simplified map of the various connections. Receiver is responsible for rendering any applications offered through Store Front that may be available from WorxHome. Because of this, Receiver must be installed before any Store Front applications can be launched. The device manage places a web clip or web link to any Store Front applications. Device Manager installs any native applications launched via AppController on the iOS device. Applications installed by Device Manager on the behalf of AppController are removed when the device is selectively wiped.
Figure 4-18 XenMobile Interconnects
The device must be reachable on the network before it can be wiped or selectively wiped. In the case of Apple devices, the devices must be able to reach the push servers. Devices that do not have a data plan service with a service provider may not be reachable. Devices with dead batteries can not be wiped.
Device that are active on the system can be wiped from the console, as shown in Figure 4-19.
Figure 4-19 Device Manager Wipes
Within the Mobile Workspace Solution CVD, Citrix Receiver is used for access to XenDesktop for all user roles, whether the user is physically located on campus or remotely accessing the corporate network over the Internet.
While on campus, corporate devices and employee devices with full or partial access have access to a XenDesktop session through local access to Citrix StoreFront. To access the corporate network remotely over the Internet, corporate devices and employee devices with full or partial access are required to use the Cisco AnyConnect Mobile Client to establish a VPN session with the ASA in the DMZ. Prior to launching Citrix Receiver, the user must first launch the AnyConnect client establishing the SSL VPN tunnel, after which Receiver can be launched.
For contractors, all access to XenDesktop is proxied through the ASA VPN Edition appliance because access to the corporate network itself is by means of guest wireless, which is terminated at a Cisco wireless anchor controller in the DMZ. This access to XenDesktop through the ASA highlights the clientless, web VPN capabilities of the ASA VPN Edition to proxy the Citrix Receiver connection to XenDesktop, eliminating the requirement for the AnyConnect Client. Remote access via the Internet to the corporate network for contractor devices is the same as if they were physically on-site inasmuch as their connection to XenDesktop is likewise proxied through the ASA in the DMZ.
The requirement for the Cisco AnyConnect mobile client on corporate or employee personal devices is driven by the fact that access to their network goes beyond the simple need to use Citrix Receiver for XenDesktop access. In the case of employees, it is assumed that they need to access numerous corporate applications, email, and collaboration services that require a full VPN tunnel to access the corporate network, as well as the XenMobile mobile applications which the contractors do not require nor have access to.
highlights the Citrix Receiver connection requirements in this CVD.
Table 4-1 XenDesktop Access
Direct access to XenDesktop
Employee (Personal Full/Partial Access)
Direct access to XenDesktop
Clientless VPN through ASA
Clientless VPN through ASA
Citrix Receiver for Corporate and Employee Devices
Windows Laptops and MacBooks
For corporate laptops and MacBooks, it is anticipated that an organization has their own procedures for software distribution within the company. As such the CVD assumes those procedures would be followed as opposed to providing any prescriptive guidance as to the means by which Receiver can be installed on these devices.
However for employee personal PCs or MacBooks, it would be expected that they would not be enrolled in any automation providing automatic software installation and updating or, alternatively, have access to servers from which they could manually download the software. As such it may be desirable to provide an automated means by which the correct Receiver Client and Receiver configuration file (.cr) can be installed. For such situations, one method that could be used would be to provide the user with the necessary information to access Citrix Receiver for Web from the XenDesktop StoreFront site. When using a browser from Windows or Mac OS X to access the StoreFront site, the site tries to determine if Receiver is installed on the user’s device. If Receiver cannot be detected, the user is prompted to download and install the appropriate version of Citrix Receiver from the StoreFront website.
The following steps outline the user experience for accessing Citrix Receiver for Web from the XenDesktop StoreFront and subsequent downloading and installation of Receiver on their device.
Step 1 To access Citrix Receiver for Web from StoreFront, the user must have access to the corporate network either:
Having established a VPN connection using the AnyConnect Client, opened a browser, and navigated to http://StoreFront_name.foo.com/Citrix/StoreWeb (the address used in the CVD is http://dc-xendesk.sdulab.com)
Upon accessing the site, StoreFront determines that Citrix Receiver is not installed on the Windows laptop. From here, the user simply needs to acknowledge the EULA and click Install.
Figure 4-20 Citrix StoreFront Receiver Detection
Step 2 Upon selecting Install, the user is prompted to run or save the Receiver executable, as shown in Figure 4-21.
Figure 4-21 Receiver Download and Installation
Step 3 Once the executable is downloaded, the Receiver Setup window is displayed and the installation begins, after which a logon is required.
Figure 4-22 Receiver Installation
Step 4 Once the Receiver installation has completed, the browser window changes to the login prompt, as shown in Figure 4-23. Upon entering credentials and successful authentication, Receiver access is now available and a XenDesktop server OS session can be launched for access to a virtual desktop.
Figure 4-23 Initial Receiver Log On
Step 5 To access XenDesktop later, the user simply needs to launch Citrix Receiver from their laptop or MacBook, as shown in Figure 4-24. In Figure 4-24, this user belongs to the “employee” role and has access to not only XenDesktop, but Windows applications available for that user role such as Firefox and Adobe reader.
Figure 4-24 Receiver for Windows Application
Installation of Citrix Receiver on corporate- or employee-owned mobile devices is automatic upon successful enrollment with the XenMobile MDM. After the initial enrollment with XenMobile and subsequent installation of the AnyConnect Client and the configuration profile, the user simply launches the AnyConnect VPN to access WorxHome with the resident WorxStore where users can choose to install approved Mobile Apps, as shown in Figure 4-25.
Figure 4-25 WorxHome Login Page and WorxStore
There is no specific need to access the “WorxStore” to install Citrix Receiver as it has been defined in XenMobile previously as a required mobile application for both employee and personal devices. As such, once this initial access to XenMobile has been established, the user is automatically prompted after a short time to install the Receiver client and once confirmed the installation begins, as shown in Figure 4-26.
Figure 4-26 Citrix Receiver Installation
Once Citrix Receiver has been successfully installed, the user must go back to the WorxStore via WorxHome and select the approved Citrix Receiver profile on which the profile will be installed on the WorxHome page, as shown in Figure 4-27.
Figure 4-27 Receiver Profile Installation
Finally, with the installation of the Receiver profile on the WorxHome page completed, the user simply selects that icon from WorxHome and Receiver automatically launches using this profile. The user is authenticated transparently, by virtue of the initial authentication to access WorxHome, and is connected with a XenDesktop session and a customized desktop with the appropriate applications for that user’s role, as shown in Figure 4-28. Recall that to open WorxHome and access Citrix Receiver, the user must first launch the AnyConnect Client for access to the corporate network.
Figure 4-28 Launching Receiver from Mobile Device with the AnyConnect Client
Citrix Receiver Installation and Operations for Contractor/Clientless Access
Contractor access to XenDesktop is significantly different from that of corporate or employee personal devices. As discussed in this CVD, Contractor access to XenDesktop in the corporate network is limited to remote access through the use of an ASA VPN Edition appliance at the edge of the network. This design was discussed in Configuring the ASA for Clientless WebVPN Access Using Citrix Receiver in Chapter2, “Configuring the Infrastructure” Whereas employees’ personal and corporate devices utilize the Cisco AnyConnect Client for VPN access to XenDesktop, contractors use the “Clientless” SSL or WebVPN functionality of the ASA. This clientless functionality can be co-resident with client-based VPN connectivity or configured on dedicated appliances based on an organization’s needs. With this approach, access to a XenDesktop session is proxied through the ASA.
Although this CVD only validates remote network access via Clientless WebVPN for contractors, other options are available should an organization choose to provide limited access to the corporate network. One such option would be to deploy a dedicated SSID or make use of an existing guest network utilizing an anchor controller in the DMZ such that all contractor traffic terminates there and connectivity to XenDesktop would be through the ASA in similar fashion as remote users. It is however beyond the scope of this CVD to document such options.
Clientless Remote Access to XenDesktop for Contractor Laptops and MacBooks
For clientless access to XenDesktop from a laptop or a MacBook, the contractor launches a browser and enters the ASA’s fully qualified Domain Name along with the name of the connection profile that has been specified for their access, such as https://asa.foo.com/CitrixClientless, where the connection profile is “CitrixClientless”. The fully customizable login form for WebVPN is diplayed, in which the user enters their credentials, as shown in Figure 4-29.
Figure 4-29 ASA WebVPN Login from a Laptop
Upon successful authentication, the connection is proxied by the ASA to Citrix StoreFront. As in the case of direct access to StoreFront without the ASA as a proxy, Receiver for Web launches and detects whether or not Citrix Receiver is installed locally on the user’s machine. As in the case of corporate- or employee-owned devices, if it is not installed, the user is prompted to install Citrix Receiver locally on their laptop or MacBook. This installation is identical to that previously described. If Citrix Receiver has been previously installed, the user is prompted to authenticate once again at Citrix StoreFront. After successful authentication, their XenDesktop session is launched.
After initial installation of Citrix Receiver, it is still necessary to access subsequent XenDesktop sessions through the use of a browser to first establish an SSL connection with the ASA. Upon connection with the ASA, the ASA proxies the connection to Citrix StoreFront using the Clientless WebVPN Connection Profile, previously documented in Configuring the ASA for Clientless WebVPN Access Using Citrix Receiver in “Configuring the Infrastructure,” after which the Receiver client launches on the PC or MacBook automatically and the user is prompted for login, as shown in Figure 4-30.
Figure 4-30 Clientless Login to XenDesktop
When the user is finished with their XenDesktop session, they can simply disconnect from the session as normal and once back at the Receiver login screen, click the red logout icon, as shown in Figure 4-31, to clear the WebVPN session on the ASA.
Figure 4-31 Clientless Logout
Clientless Remote Access for Citrix Mobile Receiver to XenDesktop for Contractors
Citrix Mobile Receiver, unlike the desktop equivalent, can be configured to communicate directly with the ASA to access Citrix StoreFront to launch a XenDesktop session.
The following steps outline the procedure required to configure an iPad. It should be noted that although not discussed here, this procedure is virtually identical to that required to configure the Mobile Receiver on an Android device.
Step 1 The user must install Citrix Mobile Receiver from the Apple App Store. Once installed, open Citrix Receiver, as shown in Figure 4-32, and select Add Account.
Step 2 A New Account window is displayed. Enter the FQDN for the ASA VPN Edition appliance. Click Next.
Step 3 After attempting to connect, an error window is displayed. In that window, click Manual Setup.
Figure 4-32 Adding an Account for Mobile Receiver Clientless Access
Upon choosing the manual setup option, the New Account window expands for entry of additional information, as shown in Figure 4-33.
Step 4 Enter a description for the StoreFront account. This step is mandatory.
Step 5 Select Access Gateway and the New Account window expands for the entry of additional information.
Step 6 Select the Access Gateway Standard Edition.
Step 7 Enter the username, password, and domain for the XenDesktop session.
Step 8 Click Save.
Figure 4-33 Account Information for Mobile Receiver Clientless Access
Once saved, the Citrix Mobile Receiver application is displayed, as shown in Figure 4-34. From this view, the user can select the account icon in the top right of the screen and verify the account they created in the Accounts drop-down menu. To add any XenApp applications as well as the XenDesktop profile to the Receiver home screen, the user can just tap the plus sign (+).
Figure 4-34 Citrix Mobile Receiver
After tapping the plus sign, a Window pop-out box is displayed on the left side of the screen from which the user can select those XenApp applications, XenDesktop profile, and the Logout button to the Mobile Receiver home screen, as shown in Figure 4-35.
Figure 4-35 Adding Applications to the Mobile Receiver Home Screen
Upon tapping the CMW_Contractor Receiver icon, the XenDesktop session is automatically launched. To disconnect from the XenDesktop session, the user simply taps the icon in the top left corner of the screen, selects Disconnect, and once back at the home screen, taps Logout, as shown in Figure 4-36. Similar to the Logout button in Receiver for Windows, after the user has disconnected from the XenDesktop session and returned to the Mobile Receiver home screen, the user can then click the Logout button to terminate the session at the ASA. Note that this is purely optional, but reclaims ASA resources used for that connection.
Figure 4-36 Logging Out of XenDesktop
To log back in to XenDesktop, the user simply taps the CMW_Contractor Receiver icon and is prompted for credentials, as shown in Figure 4-37, after which the XenDesktop session launches immediately.
Figure 4-37 XenDesktop Login