Product Documentation

Security and User Experience

Jan 12, 2017

Hinweis

This section applies to XenMobile Cloud and XenMobile on-premises deployments.

Security is important to any organization, but you need to strike a balance between security and user experience. On one hand, you may have a very secure environment that is very difficult for users to use. On the other hand, your environment may be so user-friendly that access control is not as strict. The other sections in this virtual handbook cover security features in detail, but the purpose of this article is to give a general overview of the security options available to you and to get you thinking about common security concerns in XenMobile.

Here are some key considerations to keep in mind for each use case:

  • Do you want to secure certain apps, the entire device, or both?
  • How do you want your users to authenticate their identity? Will you be using LDAP, certificate-based authentication, or a combination of the two?
  • How much time should pass before a user's session times out? Keep in mind that there are different time-out values for background services, NetScaler, and for being able to access apps while offline.
  • Do you want users to set up a device-level passcode and/or an app-level passcode? How many logon attempts do you want to afford to users? Keep in mind the additional per-app authentication requirements that may be implemented with MAM and how users may perceive them.
  • What other restrictions do you want to place on users? Should they be able to access cloud services such as Siri? What can they do with each app you make available to them and what can they not do? Should you deploy corporate WiFi policies to prevent cellular data plans from being eaten up while inside office spaces?

App vs. Device

One of the first things you should consider is whether you should only secure certain apps (mobile app management, or MAM) or if you want to manage the entire device (mobile device management or MDM). Most commonly, if you don't require device-level control, you'll only need to manage mobile apps, especially if your organization supports Bring Your Own Device (BYOD).

With a MAM-only environment, users can access resources made available to them. MAM policies secure and manage the apps themselves.

MDM allows you to secure an entire device, including the ability to take inventory of all the software on a device and prevent enrollment if the device is jailbroken, rooted, or has unsafe software installed. Taking this level of control, however, makes users leery of allowing that much power over their personal devices and may reduce enrollment rates.

It is possible to have MDM required for some devices and not for others, but keep in mind that this choice may involve setting up two dedicated environments, which requires additional resources and upkeep.

Authentication

Authentication is where a great deal of the user experience takes place. If your organization is already running Active Directory, using Active Directory is the simplest way to have your users access the system.

Another big part of the authentication user experience is time-outs. A high security environment may have users log on every time they access the system, but that option may not be ideal for all organizations. For example, having users enter their credentials every time they want to access their email can be very frustrating and may not be necessary.

User Entropy

For added security, you can enable a feature called user entropy. Citrix Secure Hub and some other apps often share common data like passwords, PINs, and certificates to ensure everything functions properly. This information is stored in a generic vault within Secure Hub. If you enable user entropy through the Encrypt Secrets option, XenMobile creates a new vault called UserEntropy, and moves the information from the generic vault into this new vault. In order for Secure Hub or another app to access the data, users must enter a password or PIN.

Enabling user entropy adds another layer of authentication in a number of places. This means, however, that whenever an app requires access to shared data in the UserEntropy vault—which includes passwords, PINs, and certificates—users need to enter a password or PIN.

You can learn more about user entropy by reading About the MDX Toolkit in the XenMobile documentation. To turn on user entropy, you can find the related settings in the Client properties.

Policies

Both MDX and MDM policies give a great deal of flexibility to organizations, but they can also restrict users. You may want this in some situations, but policies may also make a system unusable. For instance, you may want to block access to cloud applications such as Siri or iCloud that have the potential to send sensitive data where you don't want it going. You can set up a policy to block access to these services, but keep in mind that such a policy may have unintended consequences. The iOS keyboard mic is also reliant on cloud access and you may block access to that feature as well.

Apps

Enterprise Mobility Management (EMM) segments into Mobile Device Management (MDM) and Mobile Application Management (MAM). While MDM enables organizations to secure and control mobile devices, MAM facilitates application delivery and management. With the increasing adoption of BYOD, you can typically implement a MAM solution, such as XenMobile, to assist with application delivery, software licensing, configuration, and application life cycle management. With XenMobile, you can go a step further to secure these apps by configuring specific MAM policies and VPN settings to prevent data leak and other security threats. XenMobile provides organizations with the flexibility to deploy their solution as a MAM-only or a MDM-only environment, or to implement XenMobile as a unified XenMobile Enterprise environment that provides both MDM and MAM functionality within in the same platform.

In addition to the ability to deliver apps to mobile devices, XenMobile offers app containerization through MDX technology. MDX secures apps through encryption that is separate from device level encryption; you can wipe or lock the app, and the apps are subject to granular policy-based controls. Independent software vendors (ISVs) can apply these controls using the Worx App SDK.

In a corporate environment, users use a variety of mobile apps to aid in their job role. The apps can include apps from the public app store, in-house developed apps, or native apps as well, in some cases. XenMobile categorizes these apps as follows:

Public apps: These apps include free or paid apps available in a public app store, such as iTunes or Google Play. Vendors outside of the organization often make their apps available in public app stores. This option lets their customers download the apps directly from the Internet. You may use numerous public apps in your organization depending on users' needs. Examples of such apps include GoToMeeting, Salesforce, and EpicCare apps.

Citrix does not support downloading app binaries directly from public app stores, and then wrapping them with the MDX Toolkit for enterprise distribution. If you need to wrap third-party applications, work with your app vendor to obtain the app binaries which you can wrap using the MDX Toolkit.

In-house apps: Many organizations have in-house developers who create apps that provide specific functionality and are independently developed and distributed within the organization. In certain cases, some organizations may also have apps that ISVs provide. You can deploy such apps as native apps or you can containerize the apps by using a MAM solution, such as XenMobile. For example, a healthcare organization may create an in-house app that allows physicians to view patient information on mobile devices. An organization can then use the MDX Toolkit to wrap the app in order to secure patient information and enable VPN access to the back-end patient database server.

Web and SaaS apps: These apps include apps accessed from an internal network (web apps) or over a public network (SaaS). XenMobile also allows you to create custom web and SaaS apps using a list of app connectors. These app connectors can facilitate single sign-on (SSO) to existing Web apps. For details, see App connector types. For example, you can use Google Apps SAML for SSO based on Security Assertion Markup Language (SAML) to Google Apps.

XenMobile Apps: These are Citrix-developed apps that are included with the XenMobile license. You must wrap these apps with the MDX Toolkit to enable the associated MDX policies and VPN functionality. For details, see About XenMobile Apps. Citrix also offers other business-ready apps that ISVs develop by using the Worx App SDK.

HDX apps: These are Windows-hosted apps that you publish with StoreFront. If you have a Citrix XenApp and XenDesktop environment, you can integrate the apps with XenMobile to make the apps available to the enrolled users.

Depending of the type of mobile apps you plan to deploy and manage with XenMobile, the underlying configuration and architecture will differ. For example, if multiple groups of users with different level of permissions will consume a single app, you may have to create separate delivery groups to deploy two separate versions of the same app. In addition, you must make sure the user group membership is mutually exclusive to avoid policy mismatches on users' devices.

You may also want to manage iOS application licensing by using the Apple Volume Purchase Program (VPP). This option will require you to register for the VPP program and configure XenMobile VPP settings in the XenMobile console to distribute the apps with the VPP licenses. A variety of such use cases makes it important to assess and plan your MAM strategy prior to implementing the XenMobile environment. You can start planning your MAM strategy by defining the following:

Types of apps: List the different types of apps you plan to support and categorize them, such as public, native, XenMobile Apps, Web, in-house, ISV apps, and so on. Also, categorize the apps for different device platforms, such as iOS and Android. This categorization will help with aligning different XenMobile settings that are required for each type of app. For example, certain apps may not qualify for wrapping, or a few apps may require the use of the Worx App SDK to enable special APIs for interaction with other apps.

Network requirements: You need to configure apps with specific network access requirements with the appropriate settings. For example, certain apps may need access to your internal network through VPN; some apps may require Internet access to route access via the DMZ. In order to allow such apps to connect to the required network, you have to configure various settings accordingly. Defining per-app network requirements help in finalizing your architectural decisions early on, which will streamline the overall implementation process.

Security requirements: Defining the security requirements that apply to either individual apps or all the apps is critical to ensure that you create the right configurations when you install XenMobile server. Although settings, such as the MDX policies, apply to individual apps, session and authentication settings apply across all apps, and some apps may have specific encryption, containerization, wrapping, encryption, authentication, geo fencing, passcode or data sharing requirements that you will need to outline in advance to simplify your deployment.

Deployment requirements: You may want to use a policy-based deployment to allow only compliant users to download the published apps. For example, you may want certain apps to require that device encryption is enabled or the device is managed, or that the device meets a minimum operating system version. You may also want certain apps to be available only to corporate users. You need to outline such requirements in advance so that you can configure the appropriate deployment rules or actions.

Licensing requirements: You should record app-related licensing requirements. These notes will help you to manage license usage effectively and to decide if you need to configure specific features in XenMobile to facilitate licensing. For example, if you deploy an iOS app, irrespective of whether it is a free or a paid app, Apple enforces licensing requirements on the app by making the users sign into their iTunes account. You can register for Apple VPP to distribute and manage these apps via XenMobile. VPP allows users to download the apps without having to sign into their iTunes account. Additionally, tools, such as Samsung SAFE and Samsung KNOX, have special licensing requirements, which you need to complete prior to deploying those features.

Blacklist/whitelist requirements: There may be apps that you do not want users to install or use at all. Creating a blacklist will define an out of compliance event. You can then set up policies to trigger in case such a thing happens. On the other hand, an app may be acceptable for use but may fall under the blacklist for one reason or another. If this is the case, you can add the app to a whitelist and indicate that the app is acceptable to use but is not required. Also, keep in mind that the apps pre-installed on new devices can include some commonly used apps that are not part of the operating system. This may conflict with your blacklisting strategy.

Use Case

A healthcare organization plans to deploy XenMobile to serve as a MAM solution for their mobile apps. Mobile apps are delivered to corporate and BYOD users. IT decides to deliver and manage the following apps:

  • XenMobile Apps: iOS and Android apps provided by Citrix that are MDX wrapped.
  • Secure Mail: Email wrapped with MDX security policies, calendar and contact app.
  • Secure Web: Secure web browser that provides access to the Internet and intranet sites.
  • Secure Notes: Secure note-taking app with email and calendar integration.
  • ShareFile: App to access shared data and to share, sync, and edit files.

Public app store:

  • Secure Hub: Client used by all mobile devices to communicate with XenMobile. IT pushes security settings, configurations, and mobile apps to mobile devices via the Secure Hub client. Android and iOS devices enroll in XenMobile through Secure Hub.
  • Citrix Receiver: Mobile app that allows users to open XenApp-hosted applications on mobile devices.
  • GoToMeeting: An online meeting, desktop sharing, and video conferencing client that lets users meet with other computer users, customers, clients, or colleagues via the Internet in real time.
  • SalesForce1: Salesforce1 lets users access Salesforce from mobile devices and brings all Chatter, CRM, custom apps, and business processes together in a unified experience for any Salesforce user.
  • RSA SecurID: Software-based token for two-factor authentication.
  • EpicCare apps: These apps give healthcare practitioners secure and portable access to patient charts, patient lists, schedules, and messaging.
    • Haiku: Mobile app for the iPhone and Android phones.
    • Canto: Mobile app for the iPad
    • Rover: Mobile apps for iPhone and iPad.

HDX: These apps are delivered via Citrix XenApp.

  • Epic Hyperspace: Epic client application for electronic health record management.

ISV:

  • Vocera: HIPAA compliant voice-over IP and messaging mobile app that extends the benefits of Vocera voice technology anytime, anywhere via iPhone and Android smartphones.

In-house apps:

  • HCMail: App that helps compose encrypted messages, search address books on internal mail servers, and send the encrypted messages to the contacts using an email client.

In-house web apps:

  • PatientRounding: Web application used to record patient health information by different departments.
  • Outlook Web Access: Allows the access of email via a web browser.
  • SharePoint: Used for organization-wide file and data sharing.

The following table lists the basic information required for MAM configuration.

App Name

App Type

MDX Wrapping

iOS

Android

Secure Mail

XenMobile App

Yes

Yes

Yes

Secure Web

XenMobile App

Yes

Yes

Yes

Secure Notes

XenMobile App

Yes

Yes

Yes

ShareFile

XenMobile App

Yes

Yes

Yes

Secure Hub

Public App

NA

Yes

Yes

Citrix Receiver

Public App

NA

Yes

Yes

GoToMeeting

Public App

NA

Yes

Yes

SalesForce1

Public App

NA

Yes

Yes

RSA SecurID

Public App

NA

Yes

Yes

Epic Haiku

Public App

NA

Yes

Yes

Epic Canto

Public App

NA

Yes

No

Epic Rover

Public App

NA

Yes

No

Epic Hyperspace

HDX App

NA

Yes

Yes

Vocera

ISV App

Yes

Yes

Yes

HCMail

In-House App

Yes

Yes

Yes

PatientRounding

Web App

NA

Yes

Yes

Outlook Web Access

Web App

NA

Yes

Yes

SharePoint

Web App

NA

Yes

Yes

The following tables list specific requirements you can consult when configuring MAM policies in XenMobile.

App Name

 

 

VPN Required

 

 

Interaction
(with apps outside of container)

 

 

Interaction
(from apps outside of container)

 

 

Device Encryption

 

 

Secure Mail

Y

Selectively Allowed

Allowed

Not required

Secure Web

Y

Allowed

Allowed

Not required

Secure Notes

Y

Allowed

Allowed

Not required

ShareFile

Y

Allowed

Allowed

Not required

Secure Hub

Y

N/A

N/A

N/A

Citrix Receiver

Y

N/A

N/A

N/A

GoToMeeting

N

N/A

N/A

N/A

SalesForce1

N

N/A

N/A

N/A

RSA SecurID

N

N/A

N/A

N/A

Epic Haiku

Y

N/A

N/A

N/A

Epic Canto

Y

N/A

N/A

N/A

Epic Rover

Y

N/A

N/A

N/A

Epic Hyperspace

Y

N/A

N/A

N/A

Vocera

Y

Disallowed

Disallowed

Not required

HCMail

Y

Disallowed

Disallowed

Required

PatientRound-ing

Y

N/A

N/A

Required

Outlook Web Access

Y

N/A

N/A

Not required

SharePoint

Y

N/A

N/A

Not required

 

App Name

 

Proxy Filtering

 

Licensing

 

Geo-fencing

 

Worx App SDK

 

Minimum Operating System Version

 

Secure Mail

Required

N/A

Selectively Required

N/A

Enforced

Secure Web

Required

N/A

Not required

N/A

Enforced

Secure Notes

Required

N/A

Not required

N/A

Enforced

ShareFile

Required

N/A

Not required

N/A

Enforced

Secure Hub

Not required

VPP

Not required

N/A

Not enforced

Citrix Receiver

Not required

VPP

Not required

N/A

Not enforced

GoToMeeting

Not required

VPP

Not required

N/A

Not enforced

SalesForce1

Not required

VPP

Not required

N/A

Not enforced

RSA SecurID

Not required

VPP

Not required

N/A

Not enforced

Epic Haiku

Not required

VPP

Not required

N/A

Not enforced

Epic Canto

Not required

VPP

Not required

N/A

Not enforced

Epic Rover

Not required

VPP

Not required

N/A

Not enforced

Epic Hyperspace

Not required

N/A

Not required

N/A

Not enforced

Vocera

Required

N/A

Required

Required

Enforced

HCMail

Required

N/A

Required

Required

Enforced

PatientRound-ing

Required

N/A

Not required

N/A

Not enforced

Outlook Web Access

Required

N/A

Not required

N/A

Not enforced

SharePoint

Required

N/A

Not required

N/A

Not enforced

User Communities

Every organization consists of diverse user communities that operate in different functional roles. These user communities perform different tasks and office functions using various resources that you provide through the users' mobile devices. Users may work from home or in remote offices using mobile devices that you provide, or using their personal mobile devices, which allows them to access tools that are subject to certain security compliance rules.

As more and more user communities start using mobile devices to either simplify or aid in their job role, Enterprise Mobility Management (EMM) becomes critical to prevent data leak and to enforce an organization's security restrictions. In order for efficient and more sophisticated mobile device management, you can categorize your user communities. Doing so simplifies the mapping of users to resources and ensures that the right security policies apply to the right users.

The following example illustrates how the user communities of a healthcare organization are classified for EMM.

Use Case

This example healthcare organization provides technology resources and access to multiple users, including network and affiliate employees and volunteers. The organization has chosen to roll out the EMM solution to non-executive users only.

User roles and functions for this organization can be broken into subgroups including: clinical, non-clinical, and contractors. A selected set of users receive corporate mobile devices, while others can access limited company resources from their personal devices. In order to enforce the right level of security restrictions and prevent data leak, the organization decided that corporate IT manages each enrolled device, Corporate and Bring Your Own Device (BYOD). Additionally, users can only enroll a single device.

The following section provides an overview of the roles and functions of each subgroup:

Clinical:

  • Nurses
  • Physicians (Doctors, Surgeons, and so on)
  • Specialists (Dieticians, phlebotomists, anesthesiologists, radiologists, cardiologists, oncologists, and so on)
  • Outside physicians (Non-employee physicians and office workers that work from remote offices)
  • Home Health Services (Office and mobile workers performing physician services for patient home visits)
  • Research Specialist (Knowledge Workers and Power Users at six Research Institutes performing clinical research to find answers to issues in medicine)
  • Education and Training (Nurses, physicians, and specialists in education and training)

Non-Clinical:

  • Shared Services (Office workers performing various back office functions including: HR, Payroll, Accounts Payable, Supply Chain Service, and so on)
  • Physician Services (Office workers performing a variety of health care management, administrative services, and business process solutions to providers, including: Administrative Services, Analytics and Business Intelligence, Business Systems, Client Services, Finance, Managed Care Administration, Patient Access Solutions, Revenue Cycle Solutions, and so on)
  • Support Services (Office workers performing a variety of non-clinical functions including: Benefits Administration, Clinical Integration, Communications, Compensation & Performance Management, Facility & Property Services, HR Technology Systems, Information Services, Internal Audit & Process Improvement, and so o.)
  • Philanthropic Programs (Office and mobile workers that perform various functions in support of philanthropic programs)

Contractors:

  • Manufacturer and vendor partners (Onsite and remotely connected via site-to-site VPN providing various non-clinical support functions)

Based on the preceding information, the organization created the following entities. For more information about delivery groups in XenMobile, see Deploy resources in the XenMobile product documentation.

Active Directory Organizational Units (OUs) and Groups

OU

OU

Groups

XenMobile Resources

Clinical

XM-Nurses

XM-Physicians

XM-Specialists

XM-Outside Physicians

XM-Home Health Services

XM-Research Specialist

XM-Education and Training

Non-Clinical

XM-Shared Services

XM-Physician Services

XM-Support Services

XM-Philanthropic Programs

XenMobile Local Users and Groups

Group

Users

Contractors

Vendor1

Vendor2

Vendor3

Vendor4

Vendor5

Vendor6

Vendor7

Vendor8

Vendor9

Vendor10

XenMobile Delivery Groups

Clinical-Nurses

Clinical-Physicians

Clinical-Specialists

Clinical-Outside Physicians

Clinical-Home Health Services

Clinical-Research Specialist

Clinical-Education and Training

Non-Clinical-Shared Services

Non-Clinical-Physician Services

Non-Clinical-Support Services

Non-Clinical-Philanthropic Programs

Delivery Group and User Group mapping

Active Directory Groups

XenMobile Delivery Groups

XM-Nurses

Clinical-Nurses

XM-Physicians

Clinical-Physicians

XM-Specialists

Clinical-Specialists

XM-Outside Physicians

Clinical-Outside Physicians

XM-Home Health Services

Clinical-Home Health Services

XM-Research Specialist

Clinical-Research Specialist

XM-Education and Training

Clinical-Education and Training

XM-Shared Services

Non-Clinical-Shared Services

XM-Physician Services

Non-Clinical-Physician Services

XM-Support Services

Non-Clinical-Support Services

XM-Philanthropic Programs

Non-Clinical-Philanthropic Programs

Delivery Group and Resource mapping

The following tables illustrate the resources assigned to each delivery group in this use case. The first table shows the mobile app assignments; the second table shows the public app, HDX apps, and device management resources.

XenMobile Delivery Groups

Mobile Apps

Mobile Apps

Citrix Apps

Public Apps

HDX Apps

Clinical-Nurses

X

X

X

X

           

Clinical-Physicians

                   

Clinical-Specialists

                   

Clinical-Outside Physicians

X

 

X

X

           

Clinical-Home Health Services

X

 

X

X

           

Clinical-Research Specialist

X

 

X

X

           

Clinical-Education and Training

             

X

X

 

Non-Clinical-Shared Services

             

X

X

 

Non-Clinical-Physician Services

             

X

X

 

Non-Clinical-Support Services

X

 

X

X

     

X

X

 

Non-Clinical-Philanthropic Programs

X

 

X

X

     

X

X

 

Contractors

X

 

X

X

X

X

 

X

X

 

XenMobile Delivery Groups

Mobile Apps

Device Management

 

Public Apps

HDX Apps

 

RSA SecurID

EpicCare Haiku

Epic Hyperspace

Passcode Policy

Device Restrictions

Automated Actions

WiFi Policy

Clinical-Nurses

           

X

Clinical-Physicians

       

X

   

Clinical-Specialists

             

Clinical-Outside Physicians

             

Clinical-Home Health Services

             

Clinical-Research Specialist

             

Clinical-Education and Training

 

X

X

       

Non-Clinical-Shared Services

 

X

X

       

Non-Clinical-Physician Services

 

X

X

       

Non-Clinical-Support Services

 

X

X

       

Notes and considerations:

  • XenMobile creates a default delivery group named All Users during the initial configuration. If you do not disable this Delivery Group, all Active Directory users will have rights to enroll into XenMobile.
  • XenMobile synchronizes Active Directory users and groups on demand using a dynamic connection to the LDAP server.
  • If a user is part of a group that is not mapped in XenMobile, that user cannot enroll. Likewise, if a user is a member of multiple groups, XenMobile will only categorize the user as being in the groups mapped to XenMobile.
  • In order to make MDM enrollment mandatory, you must set the Enrollment Required option to True in Server Properties in the XenMobile console. For details, see Server Properties.
  • You can delete a user group from a XenMobile delivery group by deleting the entry in the SQL Server database, under dbo.userlistgrps.
    Caution: Before you perform this action, create a backup of XenMobile and the database.

About Device Ownership in XenMobile

You can group users according to the owner of a users' device. Device ownership includes corporate-owned devices and user-owned devices, also known as bring your own device (BYOD). You can control how BYOD devices connect to your network in two places in the XenMobile console: in Deployment Rules and through XenMobile server properties on the Settings page. For details about deployment rules, see Configuring Deployment Rules in the XenMobile documentation. For details about server properties, see Server Properties.

By setting server properties, you can require all BYOD users to accept corporate management of their devices before they can access apps, or you can give users access to corporate apps without also managing their devices.

When you set the server setting wsapi.mdm.required.flag to true, XenMobile manages all BYOD devices, and any user who declines enrollment is denied access to apps. You should consider setting wsapi.mdm.required.flag to true in environments in which enterprise IT teams need high security along with a positive user experience, which comes from enrolling user devices in XenMobile.

If you leave wsapi.mdm.required.flag as false, which is the default setting, users can decline enrollment, but may still access apps on their devices through the XenMobile Store. You should consider setting wsapi.mdm.required.flag to false in environments in which privacy, legal, or regulatory constraints require no device management, only enterprise app management.

Users with devices that XenMobile doesn't manage can install apps through the XenMobile Store. Instead of device-level controls, such as selective or full wipe, you control access to the apps through app policies. The policies, depending on the values you set, require the device to check the XenMobile server routinely to confirm that the apps are still allowed to run.

Security Requirements

The amount of security considerations when deploying a XenMobile environment can quickly become overwhelming. There are many interlocking pieces and settings, that you may not know where to begin or what to choose to ensure an acceptable level of protection is available. To make these choices simpler, Citrix provides recommendations for High, Higher, and Highest Security, as outlined in the following table.

Note that security concerns alone should not dictate your deployment mode choice. It is important to also review the requirements of the use case and decide if you can mitigate security concerns before choosing your deployment mode.

High: Using these settings provides an optimal user experience while maintaining a basic level of security acceptable to most organizations.

Higher: These settings strike a stronger balance between security and usability.

Highest: Following these recommendations will provide a very high level of security at the cost of usability and user adoption.

Security Considerations

High Security

Higher Security

Highest Security

Notes

Deployment Mode

MAM and/or MDM

MDM+MAM

MDM+MAM

FIPS

Depending on the use case, a MDM-only or MAM-only deployment could meet security requirements and provide a good user experience.

If there is no need for app containerization, micro VPN or app specific policies, MDM should be sufficient to manage and secure devices.

For use cases like BYOD in which all business and security requirements may be satisfied with app containerization only, Citrix recommends MAM-only mode.

For high security environments (and corporate issued devices), Citrix recommends MDM+MAM to take advantage of all security capabilities available. You should enforce MDM enrollment through a server property in the XenMobile console.

FIPS options for environments with the highest security needs, such as the federal government.

Note: If you enable FIPS mode, you must configure SQL Server to encrypt SQL traffic.

NetScaler and NetScaler Gateway

NetScaler is recommended

NetScaler Gateway is required for MAM and ENT; recommended for MDM

Standard NetScaler for XenMobile wizard configuration with SSL bridge if XenMobile is in the DMZ; or SSL offload if required to meet security standards when XenMobile server is in the internal network. 

SSL Offload with end-to-end encryption

 

Exposing XenMobile server to the Internet via NAT or existing third-party proxies/load-balancers could be an option for MDM as long as the SSL traffic terminates on XenMobile server, but this choice poses a potential security risk.

For high security environments, NetScaler with the default XenMobile configuration should meet or exceed security requirements.

For MDM environments with the highest security needs, SSL termination at the NetScaler provides the ability to inspect traffic at the perimeter, while maintaining end-to-end SSL encryption.

  • Options to define SSL/TLS ciphers.
  • SSL FIPS NetScaler hardware is also available.

For more information, see Integrating with NetScaler Gateway and NetScaler in this virtual handbook.

Enrollment

Active Directory Group membership only

All users Delivery Group disabled

Invitation only enrollment mode

Active Directory Group membership only

All users Delivery Group disabled

Enrollment mode tied to Device ID

Active Directory Group membership only

All users Delivery Group disabled

Citrix generally recommends that you restrict enrollment to users in predefined Active Directory groups only. This requires disabling the built-in All users Delivery Group.

You can use enrollment invitations to restrict enrollment to users with an invitation only.

You can use one-time PIN (OTP) enrollment invites as a two-factor solution and to control the number of devices a user may enroll.

For environments with the highest security requirements, you can tie enrollment invitations to a device by SN/UDID/EMEI. A two-factor option is also available to require Active Directory password and OTP. (Note that OTP is not currently an option for Windows devices.)

Device PIN

Recommended

*Required for Device level encryption

May be enforced with MDM

Can be set as required for MAM-only via an MDX policy

Enforced via MDM and/or MDX policy

Enforced via MDM and MDX policy

MDM Complex passcode policy

Citrix recommends the use of a device PIN.

You can enforce a device PIN via an MDM policy.

You can use an MDX policy to make a device PIN a requirement for using managed apps; for example, for BYOD use cases.

Citrix recommends combining the MDM and MDX policy options for increased security in MDM+MAM environments.

For environments with the highest security requirements, you can configure complex passcode policies and enforced them with MDM. You can configure automatic actions to notify administrators or issue selective/full device wipes when a device doesn't comply with a passcode policy.

Worx PIN

Recommended

Required for certificate-based authentication

 

Enabled

Enabled

Encrypt Secrets / User Entropy

Citrix highly recommends the use of Worx PIN for increased security and enhanced user experience. If you don't enable Worx PIN, an Active Directory password is used instead.

Ideal for use cases where enforcing a device PIN may not be an option such as BYOD or MAM-only, but protecting managed apps and corporate data is required.

You can configure complexity, history, and expiry options based on security needs.

You can configure the Encrypt Secrets option with user entropy in environments with the highest security requirements, as it relates to app container data.

Complex Worx PIN policies and the Encrypt secrets option can have a negative impact to overall user experience.

A Worx PIN policy that matches the typical Enterprise Active Directory password policy may result in user confusion, having to remember multiple complex passcodes (Active Directory + Worx PIN) and not knowing which password to use at times.

The use of the Encrypt secrets option may result in additional authentication prompts.