XenMobile is the next generation of mobile device management (MDM) provided by Citrix. XenMobile provides organizations the ability to automate most of the administrative tasks on mobile devices for both corporate and highly secured environments. In addition, it can also help organizations in managing bring your own device (BYOD) environments.
XenMobile MDM allows administrators to configure role-based management for device provisioning and security for both corporate and employee-owned BYOD devices.
When a user enrolls with their mobile device, an organization can provision policies and apps to devices automatically, blacklist or whitelist apps, detect and protect against jail broken devices, and wipe or selectively wipe a device that is lost, stolen, or out of compliance. A selective wipe means that only corporate or sensitive data is deleted, but personal data stays intact on a user’s device. XenMobile supports every major mobile OS that is being used today, giving users the freedom to choose and use a device of their choice.
XenMobile Reference Architecture:
Components:
XenMobile Device Manager (MDM) is the central server for MDM that combines policies, devices, and users to create deployments to manage the corporate mobile strategy.
To increase security it is recommended to Place this Components in the LAN (Internal Network) instead of DMZ as the picture above shows…
So, this is basically a software solution that helps the organizations to manage, provision, and secure the lifecycle of a mobile device. MDM systems allow enterprises to mass deploy policies, settings, and applications to mobile devices. These features can include provisioning the mobile devices for Wi-Fi access, corporate e-mail, develop in-house applications, tracking locations, and remote wipe. Mobile device management solutions for enterprise corporations provide these capabilities over the air and for multiple mobile operating systems.
- Devices connect to MDM over ports 80, 443, and 8443 (only during device enrollment for iOS).
- MDM runs on a Windows Server 2008 R2. It is recommended to follow the Microsoft security best practices for Windows Servers in the DMZ.
- The MDM Server requires connections to backend infrastructure components like, Active Directory, DNS, SMTP, SQL Server, and a certificate authority.
- MDM also requires a PKI service like Microsoft Certificate Authority or it can use its own PKI service hosted on the MDM Server that gets installed with Device Manager. Device Manager will use this service to push out client certificates to devices for client certification authentication to MDM. Client certificates are deployed automatically during device enrollment.
- It is recommended to use SQL Server, Express, Standard, or Enterprise for a production environment.
Apple Push Notification Service (APNS) is used by MDM to push notifications to iOS devices for configuration and policy updates. This is service provided by Apple and is only required for iOS devices. Non-iOS devices have their own push implementation.
A special APNS certificate that is signed by Citrix and issued by Apple is required before installing MDM.
Access Gateway – NetScaler Access Gateway is used for remote access and can be installed in the form of a NetScaler hardware appliance (MPX or SDX) or a VPX (virtual appliance that runs on XenServer®, VMware, or Hyper-V). This infrastructure component resides in the DMZ and is the central access point into the enterprise network. For extra security, two-factor authentication using RADIUS as a secondary authentication method is supported for services such as like RSA SecurID or Symantec VIP products.
AppController – AppController is a Linux-based hardened VPX appliance that can be deployed on XenServer or VMware. In this configuration, remote access is available using Access Gateway, but internal users can access AppController directly with the Receiver or Receiver for Web. AppController includes a version of Receiver for Web on the same server to allow mobile and desktop receivers to access apps without the addition of a StoreFront server. AppController requires connections to LDAP, DNS, NTP, and SMTP servers. SMTP is required for workflow approval through email notification.
AppController integrates with ShareFile (ShareFile account with SSO enabled is required) by provisioning Active Directory users to the ShareFile cloud service, providing Single Sign-on (SSO) to the data service using SAML authentication.
Two AppController VMs can be deployed in a high availability configuration. The first AppController on which high availability is configured is called the primary, and the other instance is called the secondary. In this deployment, the primary AppController listens for requests, serves
user requests, and synchronizes its data with the data on the secondary AppController. The two VMs work as an active-passive pair, in which only one VM is active at a time. If the primary AppController stops responding for any reason, the secondary AppController takes over, becoming the active VM and begins to service user requests. As the active VM, the secondary AppController also synchronizes system and database information by using a client-server mechanism. A client on the active AppController VM shares the necessary information to a virtual server on the passive AppController as a series of requests. The virtual server parses the requests and performs the necessary action. A virtual IP is required; this will be the FQDN AppController address used when configuring StoreFront and Access Gateway in a CloudGateway deployment. For more information, please follow this link.
StoreFront – For access to Windows desktops and apps, StoreFront needs to be placed in front of the AppController and XenDesktop components. StoreFront provides resource aggregation. It will enumerate apps from XenDesktop, XenApp, and AppController to show the user one consolidated list of resources: Windows apps, desktops, mobile apps, web/SaaS apps, and data. In this configuration, Storefront needs to know how to pass device-specific information to AppController like device enrollment information and key management. These services need to be configured in the web.config file for proper communication between all three servers.
XenDesktop – Link the XenDesktop broker or XenApp XML service to complete the integration with CloudGateway.
Keep Reading here …
XenMobile Tech Overview
XenMobile Reference Architecture
EDOCS
Configure NetScaler Gateway with StoreFront and App Controller