XenMobile Deployment Prerequisites

XenMobile Deployment Prerequisites

Topics:

• Gathering Information Before You Deploy XenMobile Components
• Opening Ports for the XenMobile Solution
• Gathering Network Information
• Obtaining and Installing Certificates

Before you deploy the XenMobile solution and install the components, make sure you have the right prerequisites and system requirements. This effort will prepare you to configure the network settings, open ports in your firewall, install certificates and licenses, and configure authentication. This section details the deployment information you need to gather and includes the XenMobile Solution Pre-Installation Checklist to guide you through the recommended settings.

Gathering Information Before You Deploy XenMobile Components

Before you install XenMobile components in your network, you need the right prerequisites. These prerequisites include:

• Network settings. These settings include IP addresses, ports, DNS, Network Time Protocol (NTP) and SMTP servers, and the IP address or fully qualified domain name (FQDN) of a load balancer.
• Hardware and sizing requirements. These include Windows Servers, hypervisors, and NetScaler Gateway requirements. The NetScaler Gateway appliance you select (VPX, MDX, or SDX) determines the maximum number of user connections to your XenMobile deployment.
• Certificates. These include server, root, intermediate, Apple Push Notification Service (APNS), and certificates for wrapping mobile apps with the MDX Toolkit.
• Licenses. Licenses are required for XenMobile MDM Edition and NetScaler Gateway.
• Active Directory settings. These settings are required for XenMobile MDM Edition and for XenMobile App Edition.
• Authentication method Before deploying XenMobile components, it's important to decide on an authentication method. For example, you should decide if you are implementing the Worx PIN that you configure in App Controller. The Worx PIN caches Active Directory credentials and works with client certificate authentication. Authentication settings can enable LDAP, RADIUS, one-time passwords, client certificate authentication, and two-factor authentication. If users connect to internal web sites, you need to configure authentication for NetScaler Gateway and SharePoint to allow single sign-on (SSO) to work.

Note: If you implement an authentication method for users and then change the method after users enroll, users will need to enroll again.

• Load balancers. Load balancers manage connections to your XenMobile deployment. You might also need to plan for packet inspection appliances to monitor network traffic entering your internal network.
• Email server and data synchronization settings These settings include Exchange Server and ActiveSync configurations for XenMobile MDM Edition and WorxMail.
• Databases. These databases include either Microsoft SQL Server or Postgres for XenMobile MDM Edition. The Postgres database comes with XenMobile MDM Edition and installs when you install Device Manager.

Note: Citrix recommends that you use Microsoft SQL Server. You should only use PostgreSQL in test deployments.

Opening Ports for the XenMobile Solution

To allow devices and apps to communicate with each XenMobile component, you need to open ports in your firewall. The following tables define the ports you need to open.

Opening Ports for NetScaler Gateway and App Controller

You need to open the following ports to allow user connections from Worx Home, Receiver, or the NetScaler Gateway Plug-in through NetScaler Gateway to App Controller, StoreFront, XenDesktop and to other internal network resources, such as intranet web pages.

• If NetScaler Gateway can reach the authentication server through a system IP (NSIP) subnet, the appliance uses the NSIP as the source IP. If the authentication server is not on a local subnet to the NSIP, the source IP is the subnet IP (SNIP). You should configure the firewall rules accordingly.
• For the sake of this guide, the listed ports are the default settings for the associated protocols. You may need to adjust the port configuration if your environment uses custom ports for any of the associated services. The list is also not exhaustive; advanced features not covered in this guide may use additional ports.

Gathering Network Information

You need to identify the following network settings and configure appropriate server settings before you install the XenMobile components in your network:

• IP addresses for each XenMobile component. For example, for NetScaler Gateway, you need the system IP (NSIP) and the subnet IP (SNIP) addresses.
• Opening the appropriate ports in your firewall to allow network traffic to communicate with each component.
• Domain Name Servers (DNS) for name resolution with users inside your network and users who connect from remote locations. You might need different IP addresses for each DNS server.
• Network Time Protocol (NTP) server. The NTP server synchronizes the time between all of your network components. Citrix recommends that you use an NTP server for your XenMobile deployment.
• SMTP server for email. When you configure an SMTP server, you need the fully qualified domain name (FQDN) of the email server, such as mail.mycompany.com. You also need to identify the port, the email addresses used for the send function, and user email addresses and passwords.

The XenMobile Pre-Installation checklist includes a section where you can write down all of your network settings. You might need to coordinate with other team members to configure the ports and servers you need for the XenMobile deployment.

Obtaining and Installing Certificates

Certificates are used to create secure connections and authenticate users.

XenMobile MDM requires a certificate from the Apple Push Notification Service (APNS). XenMobile MDM also uses its own PKI service or obtains certificates from the Microsoft Certificate Authority (CA) for client certificates.

All Citrix products support wildcard and SAN certificates. For most deployments, you only need two wildcard or SAN certificates. You can use the following formats:

• External - *.mycompany.com
• Internal - *.myinternaldomain.net

For NetScaler Gateway and App Controller, Citrix recommends obtaining server certificates from a public CA, such as Verisign, DigiCert, or Thawte. You can create a Certificate Signing Request (CSR) from the NetScaler Gateway configuration utility or the App Controller management console. After you create the CSR, submit it to the CA for signing. When the CA returns the signed certificate, you can install the certificate on NetScaler Gateway or App Controller.

For more information about installing certificates, see the following topics in Citrix eDocs:

• NetScaler Gateway: Installing and Managing Certificates
• App Controller: Configuring Certificates in App Controller
• Device Manager: Requesting an APNS Certificate

Configuring Client Certificates for Authentication

NetScaler Gateway supports the use of client certificates for authentication. Users logging on to a NetScaler Gateway virtual server can also be authenticated based on the attributes of the client certificate that is presented to the virtual server. Client certificate authentication can also be used with another authentication type, such as LDAP or RADIUS, to provide two-factor authentication.

To authenticate users based on the client-side certificate attributes, client authentication should be enabled on the virtual server and the client certificate should be requested. You must bind a root certificate to the virtual server on NetScaler Gateway.

When users log on to the NetScaler Gateway virtual server, after authentication, the user name information is extracted from the specified field of the certificate. Typically, this field is Subject:CN. If the user name is extracted successfully, the user is then authenticated. If the user does not provide a valid certificate during the Secure Sockets Layer (SSL) handshake or if the user name extraction fails, authentication fails.

You can authenticate users based on the client certificate by setting the default authentication type to use the client certificate. You can also create a certificate action that defines what is to be done during the authentication based on a client SSL certificate.