ID プロビジョニング（またはアカウント プロビジョニング）は、アカウントを設定し、ユーザーデータを保持する 3 つのシステム間の接続を確立するプロセスです。場合によっては、ユーザーとデバイス間の接続を設定することもあります。
Android エンタープライズ環境では、次の 3 つの異なるシステムでユーザー アカウント情報が保持されます。
- 組織のユーザー ディレクトリは、ユーザーに関する情報の信頼できるソースです。
- EMM ソリューション プロバイダは、組織のユーザーの最小限のディレクトリを維持する必要があります。
- Google は、Google Play を通じてアプリ管理を提供するために、managed Google Play アカウントと Google アカウントに関する一部の情報を保持しています。
Users リソースは、企業に関連付けられたアカウントを表します。アカウントはデバイスに固有の場合もあれば、複数のデバイスを使用し、それらすべてでアカウントを使用する個人に関連付けられている場合もあります。アカウントで managed Google Play のみにアクセスできるようにするか、他の Google サービスにもアクセスできるようにするかは、お客様のエンタープライズの設定方法によって異なります。
管理対象の Google アカウントは、Google によって管理されている既存のアカウントです。これらのアカウントでは、Google を ID プロバイダとして使用するか、組織のユーザー ディレクトリを Google にリンクする必要があります。managed Google アカウントを使用している企業の場合、デバイスのプロビジョニング時にユーザーの認証を行うのは Google です。
managed Google Play アカウントを使用すると、企業はエンタープライズ モビリティ管理（EMM）ソリューション プロバイダを通じて、制限付きユーザー アカウントを自動的に作成できます。これらのアカウントは、managed Google Play へのアクセスのみを提供します。EMM は、必要に応じてユーザーの認証を行う全責任を負います。managed Google Play アカウント エンタープライズでは、このタイプのアカウントのみを使用できます。
表 1: Users API のフィールドとメソッド
| managed Google Play アカウント | 管理対象の Google アカウント | |
|---|---|---|
| フィールド | ||
| id | ||
| kind | ||
| accountIdentifier | 作成して Google Play から返された ID（userId）にマッピングする一意の識別子。個人を特定できる情報（PII）は使用しないでください。 | 未設定。 |
| accountType | deviceAccount、userAccount | userAccount |
| displayName | Google Play などの UI アイテムに表示する名前。個人を特定できる情報は使用しないでください。 | 未設定。 |
| managementType | emmManaged | googleManaged、emmManaged |
| primaryEmail | 未設定。 | このフィールドは、Google 管理ドメイン アカウントからシステム内のユーザー アカウントへの同期を管理するための主キーです。 |
| メソッド | ||
| delete | ||
| generateAuthenticationToken | ||
| generateToken | ||
| get | ||
| getAvailableProductSet | ||
| 挿入 | ||
| list | ||
| revokeToken | ||
| setAvailableProductSet | ||
| update | ||
デバイス登録の改善の一環として、企業 ID を持つ従業員が使用するすべての Android Enterprise デバイスで管理対象 Google アカウントを使用するように移行しています。
新規登録では、managed Google Play アカウントよりも managed Google アカウントを使用することをおすすめします。既存のユーザーに対しては引き続き managed Google Play アカウントをサポートしますが、managed Google Play ストアへのアクセスのみが提供されます。管理対象の Google アカウントを使用すると、Google サービスとクロスデバイス機能の全スイートにアクセスできます。
登録の改善
管理対象の Google アカウントは、Google でユーザーの ID を確立します。これにより、タスクの引き継ぎ、通知、ニアバイ シェアなどのクロスデバイス エクスペリエンスが可能になります。これらの機能は、ユーザーが複数のデバイスを使用することが多い企業環境でますます重要になっています。
ID プロバイダとして Google を使用していない企業は、既存の ID プロバイダを Google にリンクすることを強くおすすめします。これにより、バインディング プロセス中に従業員の管理対象 Google アカウントを作成できます。企業は、EMM で使用しているものと同じ ID プロバイダを使用する必要があります。
次の変更が実装されました。
デバイス登録時のエンドユーザーの認証は、Google/Android によって処理されるようになりました。EMM のデバイス ポリシー コントローラ（DPC）は、適切なタイミングで Android がユーザーを認証することを要求します。Android は、ログインしているユーザーの ID を DPC に返します。
EMM は、ユーザー認証をリクエストする際に登録トークンを Android に渡す必要があります。このトークンは、Android Enterprise API への API 呼び出しによって返され、QR、NFC、またはゼロタッチ登録のペイロード内でエンコードされている場合があります。
Android が認証を処理し、ユーザー ID を EMM に提供するようになりましたが、ユーザー ID を正しいグループまたは組織構造にマッピングするのは、引き続き EMM の責任です。このマッピングは、デバイスに適切なポリシーを適用するために不可欠です。そのため、企業は組織のユーザー ディレクトリを EMM に引き続きリンクする必要があります。
IT 管理者は、Google が提供する新しいエンドユーザー認証機能を有効または無効にできます。デバイス間の機能など、ユーザーに最高の体験を提供するため、IT 管理者は組織のユーザー ディレクトリを Google にリンクすることをおすすめします。このリンクがない場合、ユーザーは managed Google Play アカウントを持ち、クロスデバイス エクスペリエンスにアクセスできません。
すべての EMM に、登録トークンとログイン トークンの作成時に追加情報を提供することが新たに義務付けられました。具体的には、デバイスがユーザーレス（キオスクや専用デバイスなど）かどうかを示す必要があります。
利点
新しいプロセスでは、次のような主な改善が行われています。
登録の簡素化: 標準的な方法と比較して、手動の手順と複雑さが軽減されます。
Google アカウントのサポート: すべてのプロビジョニング方法で Google アカウントを使用できるようになりました。これにより、managed Google Play アカウントの必要がなくなります。
ユーザー エクスペリエンスの向上: 管理対象の Google アカウントを使用すると、共有やコピー＆ペーストなどの強力なクロスデバイス機能を含む、より充実した Android エクスペリエンスを利用できます。
ユーザー アカウントの実装
この新しい登録フローの手順については、ユーザー アカウントを実装するをご覧ください。
管理対象の Google アカウントのライフサイクル
Google アカウントを使用している組織の場合、EMM ソリューションのユーザー アカウントは、別の Google サービス（Google Workspace など）に関連付けられている既存のユーザー アカウントをミラーリングします。これらのアカウントは googleManaged（表 1）です。これは、Google のバックエンド サービスがアカウントの作成と情報の発信元であるためです。
EMM は、Google Cloud Directory Sync（GCDS）や Google Admin SDK Directory API などのツールを使用して、システム内のユーザー アカウントと Google ドメイン アカウント ソースの作成と継続的な同期を容易にするメカニズムをコンソールで提供できます。さまざまなアプローチの概要については、Google 管理ドメインの ID モデルでは、仕事用プロファイルのコンテキストでユーザーのデバイスにプロビジョニングする前に、ユーザー アカウントがソリューションのコンテキスト（EMM コンソール、EMM サーバー、データストアなど）に存在している必要があります。
ID のプロビジョニング中に、組織の Google 管理ドメインにユーザー アカウントが入力されます。場合によっては、ユーザーの既存のオンライン ID（Microsoft Exchange アカウントなど）が Google アカウントと同期されます。
顧客アカウントを同期する
Google アカウントの導入では、組織は GCDS ツールを使用して、G Suite ドメインのデータを LDAP ディレクトリのデータと同期できます。または、組織からアクセス権が付与されている場合は、GCDS を使用して組織に代わってこれを行うこともできます。
GCDS ツールは Google Directory API を呼び出して、ユーザー名を同期しますが、パスワードは同期しません。
組織で Microsoft Active Directory を使用しており、ユーザーの G Suite パスワードと Active Directory パスワードを同期させたい場合は、組織または管理者が GCDS で G Suite Password Sync（GSPS）ツールを使用できます。
管理者向けの GCDS の手順については、G Suite ドメインを同期するための準備をご覧ください。
Google Directory API
Google アカウントのデプロイでは、Google Directory API を使用して、Active Directory、パスワード、またはその両方を同期できます。
ディレクトリのみの同期に Directory API を使用する。組織の管理対象 Google ドメインへの読み取り専用アクセス権がある場合は、Google Directory API を使用して、Google からユーザー名（パスワードは除く）などの Google アカウント情報を取得できます。ユーザーの Google アカウントにデータを書き込むことができないため、アカウントのライフサイクルは組織が完全に責任を負います。
シナリオ 1 と SAML ベースの SSO 認証シナリオで、この状況について詳しく説明しています。
この方法で Directory API を使用する方法については、Directory API ドキュメントのすべてのアカウント ユーザーを取得するをご覧ください。
Directory API を使用してディレクトリとオプションのパスワードを同期します。組織の管理対象 Google ドメインに対する読み取り / 書き込みアクセス権がある場合は、Google Directory API を使用して、ユーザー名、パスワード、その他の Google アカウント情報を取得できます。この情報を更新して独自のデータベースと同期できます。また、顧客に提供するソリューションに応じて、アカウントのライフサイクル全体または一部を管理する責任を負う場合があります。
シナリオ 2 で、この状況について詳しく説明します。
Directory API を使用してユーザー アカウント情報を管理する方法については、Directory API: ユーザー アカウント デベロッパー ガイドをご覧ください。
Google アカウントのシナリオ
次のセクションでは、Google アカウントの ID プロビジョニングの一般的なシナリオをいくつか説明します。
シナリオ 1: アカウントのライフサイクルをお客様が担当している場合
このシナリオでは、お客様がユーザーの Google アカウントを作成して管理します。
組織の LDAP ディレクトリからユーザー アカウント情報を取得し、Google Directory API を使用して Google から取得した Google アカウント データと関連付けます。
アカウントのライフサイクルは組織が完全に管理します。たとえば、新しい Google アカウントが作成されると、組織はユーザーを LDAP ディレクトリに追加します。次回データベースを LDAP ディレクトリに同期すると、データベースにこの新しいユーザーの情報が反映されます。
次のようになります。
- Google アカウントに対する読み取り専用アクセス権があります。
- データベースは Google アカウント名を取得しますが、LDAP ユーザー名やパスワードは取得しません。
- Google Directory API を使用して、顧客のユーザーの基本アカウント情報を取得します。（利用可能な情報は、書き込み不可の情報です。
Users.getリクエストによって返される情報です）。この情報は、ユーザーの Google アカウントが存在することを確認するために使用され、ユーザーはデバイスを認証できます。 - お客様は GCDS ツールを使用して一方向の同期を行い、ユーザーの Google アカウントにデータを入力します。（組織は、ID プロビジョニングの完了後も、独自の継続的な同期に GCDS を使用している可能性があります）。必要に応じて、組織は GSPS ツールを使用して、ユーザー名だけでなくパスワードも同期できます。
シナリオ 2: アカウントのライフサイクルを担当する EMM
このシナリオでは、お客様に代わって Google アカウントを作成するプロセスを処理し、ユーザーのアカウント ライフサイクルを管理します。
たとえば、組織の LDAP ディレクトリでユーザー情報が変更された場合は、ユーザーの Google アカウントを更新する必要があります。このシナリオでは GCDS は使用されません。
次のようになります。
- Google アカウントに対する読み取り / 書き込みアクセス権がある。
- データベースは、Google アカウント名と LDAP ユーザー名（必要に応じてパスワード ハッシュ）を取得します。
- お客様に代わって Google Directory API を使用して、組織のユーザーのアカウント情報を読み書きします。（利用可能な情報は、書き込み不可の情報（
Users.getリクエストによって返される情報）です）。この情報は、ユーザーの Google アカウントが存在することを確認するために使用され、ユーザーはデバイスを認証できます。 - GCDS ツールは使用されません。
SAML ベースの SSO 認証シナリオ
Google アカウントのデプロイでは、ユーザーまたはお客様が ID プロバイダ（IdP）で Security Assertion Markup Language（SAML）を使用して、各ユーザーに関連付けられた Google アカウントを認証する場合があります。Google アカウント名は、ユーザーがデバイスにログインする際のユーザー認証に必要な、ユーザーの Google アカウントが存在することの確認に使用されます。たとえば、シナリオ 2 では SAML を使用できます。設定方法について詳しくは、G Suite アカウントへのシングル サインオン（SSO）の設定をご覧ください。