15.3 Troubleshooting Provisioning Issues

Actions that are taken on users and groups in the identity source might not be reflected in the SaaS applications (Google Apps, Salesforce, and Office 365). The following table lists the actions in the identity sources and the corresponding actions in the SaaS applications.

Table 15-2 Provisioning Actions

Identity Sources

SaaS Applications

Delete a user. (Or disable the user account.)

Disables the SaaS account.

NOTE:In the MobileAccess app on an iOS device, the user continues to have access to the SaaS account until the in-progress user session times out.

Remove a user from the authorized group.

Disables the SaaS account.

Create a user.

  • Creates an account for the user in the SaaS application, if the user is a member of a group with mapped SaaS authorizations.

    or

  • Users are prompted to validate their information when they log in for the first time.

Move a user from out of the search context into the search context.

Creates an account for the user in the SaaS application, if the user is a member of a group with mapped SaaS authorizations.

Move a user out of the search context.

Disables the SaaS account.

By default, CloudAccess establishes identity based on an internal unique ID in the identity source, not based on the user name, and does not support recreating users with the same name unless they also have the same internal unique ID. After a user has been mapped and provisioned, if you delete the user from the identity source and then recreate that user with the same name, you will not be able to cache and activate the user in CloudAccess or provision the user to SaaS applications. When CloudAccess is unable to cache users properly, the Cached User Status Bar indicates this status with a lower number of active users than cached users.

IMPORTANT:CloudAccess does provide a Relaxed user matching option under Advanced Options on the configuration window for the identity source. If you select this option, CloudAccess matches users based on CN or sAMAccountName instead of the internal unique ID. This option enables you to recreate previously deleted users so CloudAccess can manage them again, but you must ensure that you do not create different users with the same CN or sAMAccountName as previously deleted users. Otherwise, those users will have access to the previously deleted users’ cloud application data.