Omnissa Identity Service へのディレクトリの移行（制限付きで提供）

現在、オンプレミスの Active Directory から Omnissa Workspace ONE UEM にユーザーとグループを同期している場合は、ディレクトリを Omnissa Identity Service に移行できます。 また、Workspace ONE UEM テナントに特定の要件を満たす Omnissa Access ディレクトリが関連付けられている場合は、両方のディレクトリを一緒に移行できます。

Omnissa Identity Service は、Omnissa 製品およびサービスをサードパーティのクラウドベースの ID プロバイダと統合し、ユーザー プロビジョニングと ID フェデレーションを行う新しいクラウド サービスです。Microsoft Entra ID、Okta、および汎用 SCIM 2.0 準拠の ID プロバイダがサポートされます。

移行後、ユーザーとグループはクラウド ID プロバイダから Omnissa Identity Service にプロビジョニングされ、その後、Omnissa Identity Service から Workspace ONE UEM（および該当する場合は Omnissa Access）に自動的にプロビジョニングされます。ディレクトリは、Workspace ONE UEM または Omnissa Acccess コンソールではなく Omnissa Identity Service から管理します。

Omnissa Identity Service にアクセスするには、Omnissa Connect で [ID 管理] > [エンド ユーザー管理] を選択します。Omnissa Connect は、すべての Omnissa サービスとソリューションの一元化されたアクセスを提供する Web ベースのサービスです。

重要：このドキュメントでは、既存のディレクトリを Omnissa Identity Service に移行する方法について説明します。新しい組織向けに Omnissa Identity Service を構成するには、「Omnissa Identity Service を使用したユーザー プロビジョニングと ID フェデレーションの構成」を参照してください。

Omnissa Identity Service への移行のメリット

• Active Directory からユーザーを同期させる代わりに、SCIM 2.0 プロトコルを使用して、クラウドベースのディレクトリから Workspace ONE UEM（および該当する場合 Omnissa Access）にユーザーをプロビジョニングできます。

• ユーザーとグループをプロビジョニングするために、AirWatch Cloud Connector や Omnissa Access Connector などのオンプレミス コンポーネントは必要ありません。

• Omnissa Identity Service を使用すると、Omnissa サービス全体でユーザーを一元管理できます。ディレクトリは、サービスごとに個別にではなく、1 つの中央の場所から管理します。

  重要：現在、移行では Workspace ONE UEM がサポートされています。特定の要件が満たされている場合は、1 つの Omnissa Access ディレクトリを Workspace ONE UEM ディレクトリとともに移行することもできます。

• ID プロバイダとの統合を 1 回のみ構成して、サポートされている Omnissa サービス間でフェデレーション認証を有効にします。

サポートされていない機能

Omnissa Identity Service を使用する場合、次の機能はサポートされません。

• 移行が完了した後、Active Directory の使用にロールバックすることはできません。

• サポートされていない Workspace ONE UEM 機能：

  • オンプレミスの Active Directory との直接統合
  • ディレクトリ サービスを使用した管理者および管理者グループの作成と管理
    Omnissa Connect を使用して管理者をプロビジョニングできます。
  • 親組織グループに Omnissa Identity Service が構成されている場合の、子組織グループ (OG) のディレクトリ サービスのオーバーライド
  • ユーザーの Just-in-Time (JIT) プロビジョニング
    加入ユーザーは、SCIM を介して Workspace ONE UEM にプロビジョニングされます。
  • デバイス登録およびユーザー プロパティ更新のための Omnissa Identity Service ユーザーのバッチ インポート

  次の加入方法はサポートされていません。

  <tr>
    <td>Windows</td>
    <td>ドロップシップ オンライン</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 を使用して管理者をプロビジョニングできます。
  • ローカル ユーザー、ローカル管理者、Just-in-Time (JIT) ユーザー
    すべてのユーザーは、Omnissa Identity Service によって ID プロバイダからプロビジョニングされるか、管理者として Omnissa Connect からプロビジョニングされます。
    注：ローカル ユーザーとローカル管理者とは、ディレクトリ ソースから同期されたものではなく、Omnissa Access 内で直接作成されたユーザー アカウントを指します。
  • 動的グループ
  • パスワード（クラウド デプロイ）およびパスワード（ローカル ディレクトリ）認証方法
  • People Search
  • Omnissa Access を Office 365 と統合する場合、Microsoft Entra ID プロバイダへのフェデレーション認証を使用できません。RSA SecurID、Hub MFA、モバイル SSO、証明書認証など、Omnissa Access 固有の認証方法のみを使用できます。Office 365 アクティブ フロー認証は現在サポートされていません。

要件

• Workspace ONE UEM

  • すべての Workspace ONE UEM ディレクトリ管理者が Omnissa Connect に移行されていること。
  • Workspace ONE UEM にディレクトリ サービスが構成されていること。
  • Workspace ONE UEM ディレクトリ サービスの設定が子組織グループのディレクトリ設定内の別のディレクトリによってオーバーライドされていないこと。
  • Workspace ONE UEM 環境に、[組織単位] または [カスタム クエリ] タイプのディレクトリ グループがないこと。
  • Workspace ONE UEM 基本ユーザーは、Omnissa Identity Service への移行後も引き続きサポートされます。ただし、ログイン時にすべてのユーザー（基本およびプロビジョニング）に追加のプロンプトが表示される点に注意する必要があります。

• Omnissa Access

  Workspace ONE UEM テナントに関連付けられている Omnissa Access テナントでディレクトリが構成されている場合、次の要件を満たしている場合は、Workspace ONE UEM ディレクトリとともに移行できます。

  • すべての Omnissa Access ディレクトリ管理者が Omnissa Connect に移行されていること。
  • すべての Omnissa Access ローカル管理者が Omnissa Connect に移行されていること。
  • Omnissa Access テナントに 1 つのディレクトリのみが構成されていること：タイプが「LDAP 経由の Active Directory」のディレクトリ、またはタイプが「その他」のディレクトリ（AirWatch プロビジョニング アプリケーションがユーザーとグループを Workspace ONE UEM にプロビジョニングするように構成されている）のいずれか。
  • ディレクトリが「LDAP 経由の Active Directory」ディレクトリの場合、Workspace ONE UEM ディレクトリと同じ Active Directory をソースとして使用し、同じユーザーとグループを含んでいること。
  • Omnissa Access テナントに、システム ディレクトリ内のユーザーを含むローカル ユーザーまたはローカル管理者が含まれていないこと。
  • パスワード（ローカル ディレクトリ）認証方法がどのアクセス ポリシーでも使用されていないこと。
  • パスワード（クラウド デプロイ）認証方法がどのアクセス ポリシーでも使用されていないこと。詳細については、「重要な考慮事項」を参照してください。
  • Office 365 プロビジョニング アダプタが Omnissa Access で有効になっていないこと。
  • Omnissa Access テナントに動的グループ（Active Directory から同期されたものではなく、Omnissa Access 内で作成されたグループ）が含まれていないこと。

  重要：Omnissa Access ディレクトリは、Workspace ONE UEM ディレクトリとともにのみ移行できます。Omnissa Access ディレクトリのみを移行することはできません。

• Microsoft Active Directory

  現在、Active Directory のネストされたグループを Workspace ONE UEM に同期していて、Entra ID をクラウド ID プロバイダとして使用することを計画している場合は、Active Directory でネストされたグループをフラット化するか、ネストされたグループを同期するために Omnissa Identity Service が提供するプロセスに従う必要があります。「ネストされたグループの移行」を参照してください。

• クラウド ID プロバイダ（Microsoft Entra ID、Okta、または汎用 SCIM 2.0 ID プロバイダ）

  • クラウド テナントがあること。

  • オンプレミスの Active Directory からクラウド ディレクトリにユーザーとグループを同期していること。

    Entra ID 用の Microsoft Entra Connect、Okta 用の Okta Active Directory エージェントなどのツールを使用して、オンプレミスの Active Directory からユーザーとグループを同期できます。

重要な考慮事項

• externalId は変更できない
  既存のユーザーの externalId は変更できません。クラウド ID プロバイダのプロビジョニング アプリケーションの属性マッピングは、externalId の既存の Workspace ONE UEM および Omnissa Access 属性マッピングと一致する必要があります。

• distinguishedName は、デフォルトの一意の共通の識別子として使用される

  移行中、Omnissa Identity Service は distinguishedName をデフォルトの共通の識別子として使用し、既存の Workspace ONE UEM および Omnissa Access ユーザーとグループを ID プロバイダから Omnissa Identity Service に同期されたものと照合します。デフォルト設定を使用する場合は、distinguishedName を Active Directory からクラウド ID プロバイダに同期し、プロビジョニング アプリケーションにユーザーとグループの両方の属性マッピングを追加する必要があります。

  共通の識別子として別の属性を選択できます。その場合は、その属性を Active Directory からクラウド ID プロバイダに同期し、プロビジョニング アプリケーションにユーザーとグループの両方の属性マッピングを追加する必要があります。

  共通の識別子として、次の属性がサポートされています。

  • ユーザーの場合：distinguishedName、externalId、emails、userName
  • グループの場合：distinguishedName、displayName

  注：次の場合、グループの共通の識別子として displayName を使用することをお勧めします。

  • Okta が ID プロバイダの場合。Omnissa Identity Service は、Okta グループのデフォルトとして displayName を使用します。
  • AirWatch プロビジョニング アプリケーションが構成された Omnissa Access ディレクトリを移行する場合。

  重要：移行を開始する前に共通の識別子として使用する属性を決定して、移行プロセスの「手順 1：ディレクトリの前提条件を完了する」で識別子を選択できるようにします。移行プロセスの後半で共通の識別子を変更するには、Identity Service ディレクトリを削除して移行を再開する必要があります。

• sAMAccountName または userPrincipalName をユーザー名として使用する
  Workspace ONE UEM および Omnissa Access のユーザー名として sAMAccountName を使用していて、移行中または移行後にユーザー名を userPrincipalName（Entra ID の userPrincipalName または Okta のログイン ID）に変更する場合は、ID プロバイダのプロビジョニング アプリケーションでマッピングを変更することで行えます。

  ただし、特定の 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 を使用する場合、sAMAccountName は Active Directory でのみ使用できるため、新しいユーザーを作成するときには Active Directory で作成し、それらをクラウド ID プロバイダと同期する必要があることに注意してください。クラウド ID プロバイダで作成された新しいユーザーは、Workspace ONE UEM を使用できません。

  移行を開始する前に、ユーザー名として使用する属性を決定します。ユーザー ID の信頼できる情報源として引き続き Active Directory を使用する予定であれば、sAMAccountName を使用することは有効な選択肢です。信頼できる情報源としてクラウド ID プロバイダに切り替える場合は、ユーザー名を userPrincipalName に更新することをお勧めします。

• Workspace ONE UEM ディレクトリと Omnissa Access ディレクトリの両方の移行
  Omnissa Access ディレクトリを Workspace ONE UEM ディレクトリとともに移行する場合は、移行プロセスを開始する前に、Omnissa Access のすべてのアクセス ポリシーからパスワード（クラウド デプロイ）認証方法の関連付けを解除する必要があります。エンド ユーザー認証にクラウド ID プロバイダを使用するようにアクセス ポリシーを更新します。これには、ID プロバイダを Omnissa Access のサードパーティの ID プロバイダとして統合する必要があります。

  その後、Omnissa Identity Service をクラウド ID プロバイダと統合すると、Omnissa Identity Service は Omnissa Access から構成の詳細を自動的にインポートするため、プロセスが簡素化されます。

  注：Omnissa Identity Service は、Omnissa Access でサポートされているシングル サインアウトの [ID プロバイダ リダイレクト パラメータ] 設定をサポートしていません。