*Identity provisioning* (or *account provisioning*) is the process of setting up
accounts and establishing connections among the three systems that hold user
data, and in some cases setting up connections between users and their devices.

![](https://developers.google.com/static/android/work/play/emm-api/images/3-systems.png)

In an Android enterprise environment, three different systems hold user account
information:

- The organization's user directory is the definitive source of information about users.
- You (the EMM solution provider) must maintain at least a minimal directory of the organization's users.
- Google maintains some information about managed Google Play Accounts and Google Accounts to provide app management through Google Play.

*** ** * ** ***

A [`Users`](https://developers.google.com/android/work/play/emm-api/v1/users) resource represents an account associated with an enterprise. The
account can be specific to a device, or can be associated with an individual who
has multiple devices and uses the account across them all. The account can
provide access to managed Google Play only, or to other Google services,
depending on how you set up your [customer's enterprise](https://developers.google.com/android/work/overview#customer_onboarding):

- **Managed Google Accounts** are existing accounts that are managed by
  Google. These accounts require the customer to either use Google as their
  identity provider or link their organization's user directory to Google. For
  enterprises using managed Google Accounts, Google is responsible for
  authenticating the user during device provisioning.

- **Managed Google Play Accounts** provide a way for enterprises to
  automatically create limited user accounts through their enterprise mobility
  management (EMM) solution provider. These accounts provide access to Managed
  Google Play only. The EMM is fully responsible for authenticating the user
  when needed. For managed Google Play Accounts enterprises, this is the only
  type of account available.

#### Table 1: Users API fields and methods

|   | managed Google Play Accounts | managed Google Accounts |
|---|---|---|
| Field |||
| id | Yes | Yes |
| kind | Yes | Yes |
| accountIdentifier | A unique identifier that you create and map to the ID (`userId`) returned from Google Play. Don't use personally identifiable information (PII). | Not set. |
| accountType | deviceAccount, userAccount | userAccount |
| displayName | The name you display in UI items, such as within Google Play. Don't use personally identifiable information. | Not set. |
| managementType | emmManaged | googleManaged, emmManaged |
| primaryEmail | Not set. | This field is the primary key by which you manage synchronization from Google-managed domain accounts to user accounts in your system. |
| Methods |||
| delete | Yes | No |
| generateAuthenticationToken | Yes | No |
| generateToken | No | Yes |
| get | Yes | Yes |
| getAvailableProductSet | Yes | Yes |
| insert | Yes | No |
| list | No | Yes |
| revokeToken | No | Yes |
| setAvailableProductSet | Yes | Yes |
| update | Yes | No |

*** ** * ** ***

As part of our device enrollment improvements, we are transitioning to using
**managed Google Accounts** for all Android Enterprise devices used by an
employee with a corporate identity.

For new enrollments, we now recommend using managed Google Accounts over managed
Google Play Accounts. While we continue to support managed Google Play Accounts
for existing users, they only provide access to the managed Google Play store.
**Managed Google Accounts** give users access to the full suite of Google
services and cross-device features.

## Enrollment improvements

Managed Google Accounts establish a user's identity with Google. This enables
cross-device experiences, such as task hand-off, notifications, and nearby
sharing. These features are increasingly important in the enterprise space,
where users often use multiple devices.

Enterprises that don't use Google as their identity provider are now strongly
recommended to link their existing identity provider to Google. This enables the
creation of managed Google Accounts for employees during the binding process.
Enterprises should use the same identity provider for this as they use with
their EMM.

We've implemented the following changes:

- The authentication of the end user during device enrollment is now handled
  by Google/Android. The EMM's Device Policy Controller (DPC) requires that
  Android authenticate the user at the appropriate point, and Android then
  returns the identity of the logged-in user to the DPC.

- The EMM must pass an enrollment token to Android when requesting user
  authentication. This token is returned by an API call to the Android
  Enterprise API and might be encoded within the QR, NFC, or zero-touch
  enrollment payload.

While Android now handles authentication and provides the user identity to the
EMM, it is still the EMM's responsibility to map the user identity to the
correct group or organizational structure. This mapping is essential for
applying the appropriate policies to the device. Therefore, enterprises must
continue to link their organization's user directory to their EMM.

IT admins can enable or disable the new Google-provided end-user authentication
feature. To provide users with the best experience, including cross-device
features, we recommend that IT admins link their organization's user directory
to Google. Without this link, users will have managed Google Play Accounts and
won't have access to cross-device experiences.

A new requirement for all EMMs is to provide additional information when
creating enrollment and sign-in tokens. Specifically, you must now indicate
whether a device is userless (such as a kiosk or dedicated device) or not.

### Benefits

The new process offers the following key improvements:

- **Simplified enrollment:** It reduces the number of manual steps and
  complexity compared to standard methods.

- **Google Account support:** You can now use Google Accounts with all
  provisioning methods. This removes the needs for managed Google Play
  Accounts.

- **Enhanced user experience:** With managed Google Accounts, you get a richer
  Android experience that includes powerful cross-device features like sharing
  and copy-paste.

### Implementation of user accounts

To learn how to proceed with this new enrollment flow, see [Implement user
accounts](https://developers.google.com/android/work/play/emm-api/implement-user-accounts).

## Lifecycle of managed Google Accounts

For organizations that use Google Accounts, user accounts in an EMM's
solution mirror existing user accounts associated with another Google service
(such as Google Workspace). These accounts are `googleManaged` ([Table 1](https://developers.google.com/android/work/play/emm-api/user-accounts#table-1))
because Google's backend services are the source for the creation of and
information about the account.

As an EMM, you can provide mechanisms in your console to facilitate the creation
and ongoing synchronization of user accounts held in your system with their
Google domain account sources using tools such as [Google Cloud Directory Sync
(GCDS)](https://knowledge.workspace.google.com/admin/users/about-google-cloud-directory-sync) and the [Google Admin SDK Directory API](https://developers.google.com/admin-sdk/directory/). for an overview of
various approaches. The Google-managed domain identity model requires that the
user account exists in the context of your solution (EMM console, EMM server,
perhaps in a datastore) before it can be provisioned on any of the user's
devices in the context of a work profile.

During identity provisioning, the organization's Google-managed domain is
populated with user accounts. In some cases, users' existing online identities
(for example, their Microsoft Exchange accounts) are synchronized with their
Google Accounts.

### Synchronize customer accounts

In a Google Accounts deployment, the organization can use the GCDS tool to
synchronize the data in their Google Workspace domain with the data in their
LDAP directory. Alternatively, you can use GCDS to do this on the organization's
behalf, if the organization gives you access.

The GCDS tool calls the Google Directory API and synchronizes usernames, but not
passwords.

If the organization uses Microsoft Active Directory and wants to keep users'
Google Workspace passwords in sync with their Active Directory passwords, see
[Get ready to use Password Sync](https://knowledge.workspace.google.com/admin/users/get-ready-to-use-password-sync).

For GCDS instructions for admins, see [About Google Cloud Directory Sync](https://knowledge.workspace.google.com/admin/users/about-google-cloud-directory-sync).

### Google Directory API

In a Google Accounts deployment, you can use the Google Directory API to
synchronize active directories, passwords, or both:

- **Using the Directory API for directory-only sync.** If you have read-only
  access to the organization's managed Google domain, you can use the Google
  Directory API to get Google Account information, such as usernames (but not
  passwords) from Google. Because you're unable to write any data to users'
  Google Accounts, the organization is fully responsible for account life
  cycles.

  [Scenario 1](https://developers.google.com/android/work/play/emm-api/identities-and-user-accounts#scenario-1) and [SAML-based SSO authentication scenarios](https://developers.google.com/android/work/play/emm-api/identities-and-user-accounts#scenario-saml) describe
  this situation more fully.

  For information about using the Directory API in this way, see [Retrieve all
  account users](https://developers.google.com/admin-sdk/directory/v1/guides/manage-users#get_all_users) in the Directory API documentation.
- **Using the Directory API for directory and optional password sync.** If you
  have read-write access to the organization's managed Google domain, you can
  use the Google Directory API to get usernames, passwords, and other Google
  Account information. You can update this information and sync it with your
  own database, and you might have full or partial responsibility for account
  life cycles, depending on the solution that you're offering to your
  customer.

  [Scenario 2](https://developers.google.com/android/work/play/emm-api/identities-and-user-accounts#scenario-2) describes this situation more fully.

  For more about using the Directory API to manage user account information,
  see the [Directory API: User Accounts](https://developers.google.com/admin-sdk/directory/v1/guides/manage-users) developer's guide.

### Google Accounts scenarios

A few typical Google Accounts identity-provisioning scenarios are described in
the following section.

#### Scenario 1: Customer responsible for account life cycles

![Using the Directory API (with read-only access) and GCDS](https://developers.google.com/static/android/work/play/emm-api/images/scenario-1.png)

In this scenario, your customer creates and maintains Google Accounts for its
users.

You get user account information from the organization's LDAP directory, and you
correlate this with Google Account data that you get from Google using the
Google [Directory API](https://developers.google.com/admin-sdk/directory).

The organization is fully responsible for account life cycles. For example, when
a new Google Account is created, the organization adds the user to their LDAP
directory. The next time you sync your database to the LDAP directory, your
database receives information about this new user.

In this scenario:

- You have read-only access to Google Accounts.
- Your database acquires Google Account names, but no LDAP usernames or passwords.
- You use the Google Directory API to get basic account information for your customer's users. (The information available to you is the non-writable information [returned by a `Users.get`](https://developers.google.com/admin-sdk/directory/v1/reference/users#resource) request). You use this information to verify that users' Google Accounts exist so that users can authenticate to their devices.
- Your customer uses the GCDS tool to do a one-way sync to populate users' Google Accounts. (The organization probably also uses GCDS for their own ongoing synchronization after identity provisioning is complete.) Optionally, the organization can also use the [GSPS](https://knowledge.workspace.google.com/admin/users/get-ready-to-use-password-sync) tool to sync not only usernames, but also passwords.

#### Scenario 2: EMM responsible for account life cycles

![Using the Directory API with
read-write access](https://developers.google.com/static/android/work/play/emm-api/images/scenario-2.png)

In this scenario, you handle the process of creating Google Accounts on behalf
of your customer, and you're responsible for the users' account life cycles.

For example, when user information changes in the organization's LDAP directory,
you're responsible for updating the user's Google Account. GCDS is not used in
this scenario.

In this scenario:

- You have read-write access to Google Accounts.
- Your database acquires Google Account names and LDAP usernames (and optionally, password hashes).
- You use the Google Directory API on behalf of your customer to read and write account information for the organization's users. (The information available to you is the non-writable information [returned by a
  `Users.get`](https://developers.google.com/admin-sdk/directory/v1/reference/users#resource) request). You use this information to verify that users' Google Accounts exist so that users can authenticate to their devices.
- The GCDS tool is not used.

> [!NOTE]
> **Tip:**Synchronize the accounts at the same time as you set up users' Google Accounts. That way, when the organization creates Android enterprise user accounts for their employees, the users' email addresses and network passwords are already synchronized across any accounts that the users need to access.

#### SAML-based SSO authentication scenarios

In a Google Accounts deployment, you or your customer might use Security
Assertion Markup Language (SAML) with an identity provider (IdP) to authenticate
the Google Account associated with each user. You use the Google Account names
as verification that users' Google Accounts exist, which is needed for user
authentication when users sign in to their devices. For example, SAML could be
used in Scenario 2. For details about how to set this up, see [About SSO](https://knowledge.workspace.google.com/admin/apps/about-sso).