Migrating Directories to Omnissa Identity Service (Limited Availability)

If you currently sync users and groups from on-premises Active Directory to Omnissa Workspace ONE UEM, you can migrate your directory to Omnissa Identity Service. Additionally, if your Workspace ONE UEM tenant has an associated Omnissa Access directory that meets specific requirements, you can migrate both directories together.

Omnissa Identity Service is a new cloud service for integrating Omnissa products and services with third-party cloud-based identity providers for user provisioning and identity federation. Microsoft Entra ID, Okta, and generic SCIM 2.0-compliant identity providers are supported.

After migration, users and groups will be provisioned from your cloud identity provider to Omnissa Identity Service, and then automatically provisioned from Omnissa Identity Service to Workspace ONE UEM (and Omnissa Access, if applicable). You will manage the directory from Omnissa Identity Service, not from the Workspace ONE UEM or Omnissa Acccess consoles.

You can access Omnissa Identity Service by selecting Identity Management > End User Management in Omnissa Connect. Omnissa Connect is a web-based service that provides centralized access to all Omnissa services and solutions.

Important: This document provides guidance for migrating existing directories to Omnissa Identity Service. To configure Omnissa Identity Service for new organizations, see Configuring User Provisioning and Identity Federation with Omnissa Identity Service.

Benefits of Migrating to Omnissa Identity Service

• You can provision users from your cloud-based directory to Workspace ONE UEM (and Omnissa Access, if applicable) using the SCIM 2.0 protocol, instead of syncing users from Active Directory.

• You do not need any on-premises components such as AirWatch Cloud Connector or Omnissa Access Connector to provision users and groups.

• Omnissa Identity Service offers centralized user management across Omnissa services. You manage your directory from one central location, not separately from each service.

  Important: Currently, Workspace ONE UEM is supported for migration. A single Omnissa Access directory can also be migrated along with the Workspace ONE UEM directory if certain requirements are met.

• You configure the integration with your identity provider only once to enable federated authentication across supported Omnissa services.

Unsupported Features

When you use Omnissa Identity Service, the following features are not supported.

• You cannot roll back to using Active Directory after the migration is complete.

• Unsupported Workspace ONE UEM features:

  • Direct integration with on-premises Active Directory
  • Creating and managing administrators and administrator groups through Directory Services
    You can provision administrators through Omnissa Connect.
  • Overriding Directory Services for child organization groups (OG) when Omnissa Identity Service is configured for the parent organization group
  • Just-in-time (JIT) provisioning of users
    Enrollment users are provisioned through SCIM to Workspace ONE UEM.
  • Batch import for Omnissa Identity Service users, for device registration and for updating user properties

  The following enrollment methods are not supported:

  <tr>
    <td>Windows</td>
    <td>Dropship Online</td>
  </tr>
    <tr>
    <td>Linux</td>
    <td>SAML authentication on Headless devices</td>
  </tr>
  <tr>
    <td>XR</td>
    <td>All flows</td>
  </tr>
  <tr>
    <td>Peripherals</td>
    <td>All flows</td>
  </tr>
  

  Platform	Unsupported Flows

• Unsupported Omnissa Access features:

  • Direct integration with on-premises Active Directory
  • Directory administrators synced from Active Directory
    You can provision administrators through Omnissa Connect.
  • Local users, local administrators, or Just-in-time (JIT) users
    All users are either provisioned from your identity provider by Omnissa Identity Service, or are administrators provisioned from Omnissa Connect.
    Note: Local users and local administrators refer to user accounts that are created directly in Omnissa Access and not synced from a directory source.
  • Dynamic groups
  • Password (cloud deployment) and Password (Local Directory) authentication methods
  • People Search
  • If you integrate Omnissa Access with Office 365, you cannot use federated authentication to the Microsoft Entra ID identity provider. Only Omnissa Access-specific authentication methods, such as RSA SecurID, Hub MFA, Mobile SSO, and Certificate Auth, will be available. Office 365 Active Flow authentication is currently not supported.

Requirements

• Workspace ONE UEM

  • All Workspace ONE UEM directory administrators have been migrated to Omnissa Connect.
  • Workspace ONE UEM has Directory Services configured.
  • Your Workspace ONE UEM Directory Services setting is not overridden by another directory in a child organization group's directory settings.
  • Your Workspace ONE UEM environment does not have any Directory groups of type Organizational Unit or Custom Query.
  • Workspace ONE UEM Basic users will continue to be supported after migration to Omnissa Identity Service. However, you need to be aware that all users (Basic and provisioned) will see an additional prompt during login.

• Omnissa Access

  If a directory is configured in the Omnissa Access tenant associated with your Workspace ONE UEM tenant, you can migrate it along with the Workspace ONE UEM directory if these requirements are met:

  • All Omnissa Access directory administrators have been migrated to Omnissa Connect.
  • All Omnissa Access local administrators have been migrated to Omnissa Connect.
  • Only one directory is configured in the Omnissa Access tenant: either a directory of type Active Directory over LDAP, or a directory of type Other with the AirWatch Provisioning app configured to provision users and groups to Workspace ONE UEM.
  • If the directory is an Active Directory over LDAP directory, it uses the same Active Directory as the source as your Workspace ONE UEM directory, and contains the same users and groups.
  • The Omnissa Access tenant does not have any local users or local administrators, including any users in the System directory.
  • The Password (Local Directory) authentication method is not used in any access policies.
  • The Password (cloud deployment) authentication method is not used in any access policies. See Critical Considerations for more information.
  • The Office 365 provisioning adapter is not enabled in Omnissa Access.
  • The Omnissa Access tenant does not have any dynamic groups (groups created in Omnissa Access, not synced from Active Directory).

  Important: You can only migrate an Omnissa Access directory along with your Workspace ONE UEM directory. You cannot migrate only an Omnissa Access directory.

• Microsoft Active Directory

  If you currently sync Active Directory nested groups to Workspace ONE UEM, and you are planning to use Entra ID as your cloud identity provider, you must either flatten the nested groups in Active Directory or follow the process Omnissa Identity Service offers for syncing nested groups. See Migrating Nested Groups.

• Your cloud identity provider (Microsoft Entra ID, Okta, or generic SCIM 2.0 identity provider)

  • You have a cloud tenant.

  • You have synced users and groups from your on-premises Active Directory to the cloud directory.

    You can use tools such as Microsoft Entra Connect for Entra ID and Okta Active Directory Agent for Okta to sync users and groups from on-premises Active Directory.

Critical Considerations

• externalId cannot be changed
  You cannot change the externalId for existing users. The attribute mapping in the provisioning app in your cloud identity provider must match the existing Workspace ONE UEM and Omnissa Access attribute mapping for externalId.

• distinguishedName is used as the default unique, common identifier

  During migration, Omnissa Identity Service uses distinguishedName as the default common identifier to match existing Workspace ONE UEM and Omnissa Access users and groups with those synced from your identity provider to Omnissa Identity Service. If you use the default setting, you must sync distinguishedName from Active Directory to your cloud identity provider and add the attribute mapping in the provisioning app for both users and groups.

  You can select a different attribute as the common identifier. If you do so, you must ensure that you sync that attribute from Active Directory to your cloud identity provider and add the attribute mapping in the provisioning app for both users and groups.

  The following attributes are supported as the common identifier:

  • For users: distinguishedName, externalId, emails, userName
  • For groups: distinguishedName, displayName

  Note: displayName is recommended as the common identifier for groups in the following cases:

  • When Okta is the identity provider. Omnissa Identity Service uses displayName as the default for Okta groups.
  • When you migrate an Omnissa Access directory with the AirWatch Provisioning app configured.

  Important: Make the decision about which attribute to use as the common identifier before you start the migration so that you can select the identifier in Step 1: Complete Directory Prerequisites of the migration process. To change the common identifier later in the migration process, you will have to delete the Identity Service directory and restart migration.

• Using sAMAccountName or userPrincipalName as username
  If you were using sAMAccountName as the username in Workspace ONE UEM and Omnissa Access, and you want to change username to userPrincipalName (Entra ID userPrincipalName or Okta login identifier) during or after migration, you can do so by changing the mapping in the provisioning app in the identity provider.

  However, you must consider the impact of the change based upon your usage of certain Workspace ONE UEM and Omnissa Access features.

  • For Workspace ONE UEM, for example, if username is used in NFS folder paths in Workspace ONE Content repository templates, you would have to update the paths to use userPrincipalName. Similarly, if username is used in certificate templates, you would need to re-deploy profiles associated with these templates. User attributes might be in use as lookup values in other places such as profile payloads, app configurations, and message templates, depending on the configurations you have deployed in Workspace ONE UEM.

  • For Omnissa Access, changing the username mapping will cause the following authentication methods to fail: RADIUS, RSA SecurID, and Kerberos. Additionally, the DUO Security authentication method will fail if Username is selected as the Username format setting in the authentication method configuration. If you use these authentication methods, we recommend that you do not change the username mapping.

  On the other hand, if you decide to use sAMAccountName as the username in Workspace ONE UEM, keep in mind that when you create new users in the future, you will have to create them in Active Directory and sync them to your cloud identity provider because sAMAccountName is only available in Active Directory. New users created in the cloud identity provider will not be able to use Workspace ONE UEM.

  Make the decision about which attribute you want to use as username before you begin the migration. If you intend to continue using Active Directory as the source of truth for user identities, using sAMAccountName is a viable option. If you plan to switch to your cloud identity provider as the source of truth, updating username to userPrincipalName might be preferable.

• Migrating both a Workspace ONE UEM directory and an Omnissa Access directory
  If you are migrating an Omnissa Access directory along with your Workspace ONE UEM directory, you must disassociate the Password (cloud deployment) authentication method from all access policies in Omnissa Access before starting the migration process. Update the access policies to use your cloud identity provider for end user authentication. This requires the identity provider to be integrated as a third-party IDP in Omnissa Access.

  When you subsequently integrate Omnissa Identity Service with your cloud identity provider, Omnissa Identity Service automatically imports the configuration details from Omnissa Access, simplifying the process.

  Note: Omnissa Identity Service does not support the Single Sign-Out IdP Redirect Parameter setting supported by Omnissa Access.