NetScaler Gateway™ integration with XenMobile®

XenMobile is Citrix's Enterprise Mobile Management suite. It allows enterprises to maintain better control over how their IT users interact with company data, when connected through either company-provided or employee-owned mobile devices. The importance of such a solution is easy to see when you consider how ubiquitous mobile devices have become and also how they offer better on the run access to information, something hugely important to the mobile workforce of today.

Before we dive into troubleshooting XenMobile integration, let's look at some fundamentals.

XenMobile components

From an integration perspective, the key components are as follows:

  1. The XenMobile Server, a Linux virtual machine which is an amalgamation of the following:
    • The AppController service, which provides mobile application management, but also acts as an STA for ticketing
    • The MDM service, which provides mobile device management
  2. The WorxHome component, which is the application on the mobile device that takes care of User enrolment, as well as handling application enumeration and subscription.
  3. The Worx applications, such as WorxMail, WorxWeb, or even custom applications.
  4. A SAAS-based sharing platform which allows users to store and share files. It works both as a standalone application and as a connector built into other WorxApps, such as WorxMail, allowing users to attach files directly from the cloud.

The Ports used for NetScaler integration are as follows:

  • LDAP and Global Catalogue: TCP ports 389/636 and TCP ports 3268/3269
  • DNS: UDP port 53
  • User Enrolment and WorxStore access: TCP port 8443 between NetScaler and XenMobile server

Note

The complete XenMobile solution uses a lot more ports. Please see the XenMobile eDocs page for the exhaustive list.

XenMobile launch process with NetScaler Gateway

Let's take a look at a communication flow that demonstrates NetScaler's integration with XenMobile server using the most popular use case for this integration, WorxMail. We will once again break this into phases to make it easy to digest:

  • Phase1: Authentication and discovery
  • Phase2: Mobile application enumeration and launch

Phase 1 – Authentication and discovery

When User Bob launches WorxHome on his mobile device, it sends a GET to the path /zdm/cxf/public/getserverinfo on XenMobile server. This for the purpose of discovery and results in a redirect to the NetScaler Gateway VIP:

Phase 1 – Authentication and discovery

Bob logs in and his credentials are verified with the LDAP server.

Phase 1 – Authentication and discovery

Use aaad.debug, as in the VPN scenario, for any issues with authentication. Along with the credentials, WorxHome also tells NetScaler Gateway what kind of device Bob is connecting from, by using the User-Agent header:

User-Agent: CitrixReceiver/com.zenprise build/10.2.2 Android/4.4.2 KOT49H.N5110XXDNF1 VpnCapable

Note

The VpnCapable part of the string is used to say that the client component can handle microvpns.

This results in a redirect to the path /cgi/setclient?andr. The andr here stands for Android. The redirect also contains the NSC_AAAC cookie, which identifies all further requests from this User:

Phase 1 – Authentication and discovery

The discovery finishes with the VPN client receiving the XenMobile server's details:

Phase 1 – Authentication and discovery

Phase 2 – App enumeration and Launch

Once discovery is complete, WorxHome on the User's mobile device needs to be able to show the list of Worx Applications available to them. This is called application enumeration.

Note

The callback URL in XenMobile is optional, just as with Storefront. The recommendation is to leave it blank by default.

WorxHome requests a list of available applications through a series of POST, the last of which is to /StoreWeb/ws/Resources/List. So if it's enumeration that's failing, this is the request you'd be looking for. The response will be a list of apps and info about these apps, such as where to pull the icons from, their app ID, and their SSO details:

Phase 2 – App enumeration and Launch

The app ID here is very useful because if you have app launch failures you can search using this value, and identify all pertinent requests. In the following screenshot the app ID is MobileApp2:

Phase 2 – App enumeration and Launch

At this point Bob clicks on the WorxMail icon and this results in the application being fetched for installation. We can follow the exchange using a filter such as http contains MobileApp2. This should show something similar to the following:

Phase 2 – App enumeration and Launch

The really large 200 OK is the WorxMail package. At this point, communication starts between the mobile end point and the end server, which is exchange in the case of WorxMail, and the User should see their mail:

Phase 2 – App enumeration and Launch

For WorxMail, this will appear as a series of ActiveSync requests.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.144.21.125