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 user mobile devices. Users might work from home or in remote offices using mobile devices that you provide. Or, users might use personal mobile devices, which allows them to access tools that are subject to certain security compliance rules.

With more user communities using mobile devices, Enterprise Mobility Management (EMM) becomes critical to prevent data leak and to enforce organizational 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.

Categorizing user communities can include use of the following components:

• Active Directory Organizational Units (OUs) and Groups

  Users added to specific Active Directory security groups can receive policies and resources such as apps. Removing users from the Active Directory security groups removes access to previously allowed XenMobile resources.

• XenMobile local users and groups

  For users who don’t have an account in Active Directory, you can create the users as local XenMobile users. You can add local users to delivery groups and provision resources to them in the same manner as Active Directory users.

• XenMobile delivery groups

  If multiple groups of users with different level of permissions are to consume a single app, you might need to create separate delivery groups. With separate delivery groups, you can deploy two separate versions of the same app.

• Delivery group and user group mapping

  Delivery group to Active Directory group mappings can be either one-to-one, or one-to-many. Assign base policies and apps to a one-to-many delivery group mapping. Assign function-specific policies and apps to one-to-one delivery group mappings.

• Delivery Group and Resource Mapping of Apps

  Assign specific apps to each delivery group.

• Delivery Group and Resource Mapping of MDM Resources

  Assign apps and specific device management resources to each delivery group. For example, configure a delivery group with any mix of the following: Types of apps (public, HDX, and so on), specific apps per app type, and resources such as device policies and automated actions.

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.

You can divide user roles and functions for this organization 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 (BYOD). To enforce the appropriate level of security restrictions and prevent data leak, the organization decided that corporate IT manages each enrolled device. Also, users can only enroll a single device.

The following sections provide 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 various 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 various 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 on.)
• 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

For OU = XenMobile Resources

• OU = Clinical; Groups =
  • XM-Nurses
  • XM-Physicians
  • XM-Specialists
  • XM-Outside Physicians
  • XM-Home Health Services
  • XM-Research Specialist
  • XM-Education and Training
• OU = Non-Clinical; Groups =
  • XM-Shared Services
  • XM-Physician Services
  • XM-Support Services
  • XM-Philanthropic Programs

XenMobile Local Users and Groups

For Group= Contractors, Users =

• Vendor1
• Vendor2
• Vendor 3
• … Vendor 10

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

Delivery Group and Resource Mapping of Apps

Delivery Group and Resource Mapping of MDM Resources

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 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 only categorizes the user as being in the groups mapped to XenMobile.
• To make MDM enrollment mandatory, set the Enrollment Required option to True in Server Properties in the XenMobile console. For details, see Server Properties.
• To delete a user group from a XenMobile delivery group, delete 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 user 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 Deploy resources in the XenMobile documentation. For details about server properties, see Server Properties in this handbook.

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 property wsapi.mdm.required.flag to true, XenMobile manages all BYOD devices, and any user who declines enrollment is denied access to apps. Consider setting wsapi.mdm.required.flag to true in environments in which enterprise IT teams need high security plus a positive user experience during enrolling.

If you leave wsapi.mdm.required.flag as false, which is the default setting, users can decline enrollment. However, they can access apps on their devices through the XenMobile Store. 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. Some policy settings require the device to check the XenMobile server routinely to confirm that the apps are still allowed to run.