如果您当前将内部部署 Active Directory 中的用户和组同步到 Omnissa Workspace ONE UEM,则可以将目录迁移到 Omnissa Identity Service。 此外,如果您的 Workspace ONE UEM 租户具有关联的 Omnissa Access 目录,且该目录满足特定要求,则可以同时迁移这两个目录。
Omnissa Identity Service 是新推出的云服务,用于将 Omnissa 产品和服务与第三方基于云的身份提供程序集成,以进行用户置备和身份联合。支持 Microsoft Entra ID、Okta 以及符合 SCIM 2.0 的通用身份提供程序。
迁移后,用户和组将从您的云身份提供程序置备到 Omnissa Identity Service,然后自动从 Omnissa Identity Service 置备到 Workspace ONE UEM(和 Omnissa Access,如果适用)。您将从 Omnissa Identity Service 管理目录,而不是从 Workspace ONE UEM Console 或 Omnissa Access 控制台进行管理。
您可以通过在 Omnissa Connect 中选择身份管理 > 最终用户管理来访问 Omnissa Identity Service。Omnissa Connect 是一种基于 Web 的服务,可提供对所有 Omnissa 服务和解决方案的集中式访问。
重要信息:本文档提供了有关将现有目录迁移到 Omnissa Identity Service 的指导。要为新组织配置 Omnissa Identity Service,请参阅使用 Omnissa Identity Service 配置用户置备和身份联合。
迁移到 Omnissa Identity Service 的优势
-
您可以使用 SCIM 2.0 协议将用户从基于云的目录置备到 Workspace ONE UEM(和 Omnissa Access,如果适用),而不是从 Active Directory 同步用户。
-
您不需要任何内部部署组件(如 AirWatch Cloud Connector 或 Omnissa Access Connector)来置备用户和组。
-
Omnissa Identity Service 提供跨 Omnissa 服务的集中式用户管理。您可以从一个中央位置管理目录,而不是从每个服务单独管理。
重要信息:目前,支持迁移 Workspace ONE UEM。如果满足特定要求,也可以将单个 Omnissa Access 目录与 Workspace ONE UEM 目录一起迁移。
-
您只需配置一次与身份提供程序的集成,即可在受支持的 Omnissa 服务中启用联合身份验证。
不支持的功能
使用 Omnissa Identity Service 时,不支持以下功能。
-
迁移完成后,无法回滚到使用 Active Directory。
-
不支持的 Workspace ONE UEM 功能:
- 与内部部署 Active Directory 直接集成
- 通过目录服务创建管理员和管理员组并对其进行管理
您可以通过 Omnissa Connect 置备管理员。 - 在为父组织组 (Organization Group, OG) 配置 Omnissa Identity Service 时覆盖子组织组的目录服务
- 即时 (Just-In-Time, JIT) 用户置备
可通过 SCIM 将注册用户置备到 Workspace ONE UEM。 - 为设备注册和更新用户属性批量导入 Omnissa Identity Service 用户
不支持以下注册方法:
<tr> <td>Windows</td> <td>Dropship Online</td> </tr> <tr> <td>Linux</td> <td>无外设设备上的 SAML 身份验证</td> </tr> <tr> <td>XR</td> <td>所有流程</td> </tr> <tr> <td>外围设备</td> <td>所有流程</td> </tr>平台 不支持的流程 -
不支持的 Omnissa Access 功能:
- 与内部部署 Active Directory 直接集成
- 从 Active Directory 同步的目录管理员
您可以通过 Omnissa Connect 置备管理员。 - 本地用户、本地管理员或即时 (JIT) 用户
所有用户都是通过 Omnissa Identity Service 从身份提供程序置备的用户,或是从 Omnissa Connect 置备的管理员。
注意:本地用户和本地管理员指的是直接在 Omnissa Access 中创建且未从目录源同步的用户帐户。 - 动态组
- 密码(云部署)和密码(本地目录)身份验证方法
- People Search
- 如果将 Omnissa Access 与 Office 365 集成,则无法对 Microsoft Entra ID 身份提供程序使用联合身份验证。仅特定于 Omnissa Access 的身份验证方法(例如 RSA SecurID、Hub MFA、移动 SSO 和证书身份验证)可用。当前不支持 Office 365 活动流身份验证。
要求
-
Workspace ONE UEM
- 所有 Workspace ONE UEM 目录管理员都已迁移到 Omnissa Connect。
- Workspace ONE UEM 已配置目录服务。
- 您的 Workspace ONE UEM 目录服务设置未被子组织组目录设置中的其他目录覆盖。
- Workspace ONE UEM 环境中没有任何类型为“组织单位”或“自定义查询”的目录组。
- 迁移到 Omnissa Identity Service 后,将继续支持 Workspace ONE UEM 基本用户。但是,需要注意的是,所有用户(基本和已置备)都将在登录期间看到额外的提示。
-
Omnissa Access
如果在与 Workspace ONE UEM 租户关联的 Omnissa Access 租户中配置了目录,则可以在满足以下要求的情况下将该目录与 Workspace ONE UEM 目录一起迁移:
- 所有 Omnissa Access 目录管理员都已迁移到 Omnissa Connect。
- 所有 Omnissa Access 本地管理员都已迁移到 Omnissa Connect。
- Omnissa Access 租户中仅配置了一个目录:要么是“通过 LDAP 访问的 Active Directory”类型的目录,要么是“其他”类型的目录,且该目录中配置了 AirWatch 置备应用程序以将用户和组置备到 Workspace ONE UEM。
- 如果目录是“通过 LDAP 访问的 Active Directory”类型的目录,该目录会使用与 Workspace ONE UEM 目录相同的 Active Directory 作为源,并且包含相同的用户和组。
- Omnissa Access 租户没有任何本地用户或本地管理员,包括系统目录中的任何用户。
- 密码(本地目录)身份验证方法未在任何访问策略中使用。
- 密码(云部署)身份验证方法未在任何访问策略中使用。有关更多信息,请参阅关键注意事项。
- Omnissa Access 中未启用 Office 365 置备适配器。
- Omnissa Access 租户没有任何动态组(在 Omnissa Access 中创建的组,而不是从 Active Directory 同步的组)。
重要信息:只能将 Omnissa Access 目录与 Workspace ONE UEM 目录一起迁移。无法仅迁移 Omnissa Access 目录。
-
Microsoft Active Directory
如果当前将 Active Directory 嵌套组同步到 Workspace ONE UEM,并且计划使用 Entra ID 作为云身份提供程序,则必须在 Active Directory 中将这些嵌套组扁平化,或者按照 Omnissa Identity Service 为同步嵌套组提供的过程进行操作。请参阅迁移嵌套组。
-
您的云身份提供程序(Microsoft Entra ID、Okta 或通用 SCIM 2.0 身份提供程序)
-
您具有云租户。
-
您已将用户和组从内部部署 Active Directory 同步到云目录。
您可以使用 Microsoft Entra Connect(对于 Entra ID)和 Okta Active Directory 代理(对于 Okta)等工具从内部部署 Active Directory 同步用户和组。
-
关键注意事项
-
无法更改 externalId
您无法更改现有用户的 externalId。您云身份提供程序的置备应用程序中的属性映射必须与 externalId 的现有 Workspace ONE UEM 和 Omnissa Access 属性映射相匹配。 -
使用 distinguishedName 作为默认的唯一通用标识符
在迁移过程中,Omnissa Identity Service 使用 distinguishedName 作为默认的通用标识符,以将现有 Workspace ONE UEM 和 Omnissa Access 用户和组与从身份提供程序同步到 Omnissa Identity Service 的用户和组进行匹配。如果使用默认设置,则必须将 distinguishedName 从 Active Directory 同步到云身份提供程序,并在置备应用程序中为用户和组添加属性映射。
您可以选择其他属性作为通用标识符。如果这样做,则必须确保将该属性从 Active Directory 同步到云身份提供程序,并在置备应用程序中为用户和组添加属性映射。
支持将以下属性作为通用标识符:
- 对于用户:distinguishedName、externalId、emails、userName
- 对于组:distinguishedName、displayName
注意:在以下情况下,建议将 displayName 作为组的通用标识符:
- 当 Okta 是身份提供程序时。Omnissa Identity Service 使用 displayName 作为 Okta 组的默认通用标识符。
- 当迁移配置了 AirWatch 置备应用程序的 Omnissa Access 目录时。
重要信息:在开始迁移之前,请先确定将哪个属性用作通用标识符,以便可以在迁移过程的步骤 1:完成目录必备条件中选择该标识符。要在迁移过程后面部分更改通用标识符,您必须删除 Identity Service 目录并重新启动迁移。
-
将 sAMAccountName 或 userPrincipalName 用作用户名
如果在 Workspace ONE UEM 和 Omnissa Access 中将 sAMAccountName 用作用户名,并希望在迁移期间或迁移后将用户名更改为 userPrincipalName(Entra ID userPrincipalName 或 Okta 登录标识符),则可以通过在身份提供程序的置备应用程序中更改映射来执行此操作。但是,必须根据某些 Workspace ONE UEM 和 Omnissa Access 功能的使用情况来考虑此项更改的影响。
-
例如,对于 Workspace ONE UEM,如果在 Workspace ONE Content 存储库模板的 NFS 文件夹路径中使用用户名,则必须将这些路径更新为使用 userPrincipalName。同样,如果在证书模板中使用用户名,则需要重新部署与这些模板关联的配置文件。根据您在 Workspace ONE UEM 中部署的配置,用户属性可能正被用作其他位置(如配置文件负载、应用程序配置、消息模板)的查找值。
-
对于 Omnissa Access,更改用户名映射将导致以下身份验证方法失败:RADIUS、RSA SecurID 和 Kerberos。此外,如果在身份验证方法配置中选择用户名作为用户名格式设置,则 DUO 安全身份验证方法将失败。如果使用这些身份验证方法,我们建议您不要更改用户名映射。
另一方面,如果您决定在 Workspace ONE UEM 中将 sAMAccountName 用作用户名,请记住,以后创建新用户时,必须在 Active Directory 中创建这些用户并将其同步到您的云身份提供程序,因为 sAMAccountName 仅在 Active Directory 中可用。在云身份提供程序中创建的新用户将无法使用 Workspace ONE UEM。
在开始迁移之前,需先决定要将哪个属性用作用户名。如果您打算继续将 Active Directory 用作用户身份的真实来源,则使用 sAMAccountName 是一个可行的选项。如果您计划切换到使用云身份提供程序作为真实来源,最好将用户名更新为 userPrincipalName。
-
-
同时迁移 Workspace ONE UEM 目录和 Omnissa Access 目录
如果要将 Omnissa Access 目录与 Workspace ONE UEM 目录一起迁移,则必须先解除密码(云部署)身份验证方法与 Omnissa Access 中所有访问策略的关联,然后再开始迁移过程。可更新访问策略以使用云身份提供程序进行最终用户身份验证。这要求将身份提供程序作为第三方 IDP 集成到 Omnissa Access 中。当您随后将 Omnissa Identity Service 与云身份提供程序集成时,Omnissa Identity Service 会自动从 Omnissa Access 中导入配置详细信息,从而简化该过程。
注意:Omnissa Identity Service 不支持 Omnissa Access 支持的单点注销 IdP 重定向参数设置。
此页面对您有帮助吗?