Use the information in the following sections to troubleshoot provisioning issues.
By default, when you provision users, the appliance does not log any information about the provisioning process. Enabling logging causes performance issues, so you should never leave the logging running all of the time.
However, if you have provisioned users and select accounts are not showing up in the SaaS applications, you will need to enable logging to capture the cause.
To capture logs of provisioning issues:
Determine which account (or accounts) were not provisioned.
Remove that account from the group that grants access to the SaaS application.
Turn on logging:
Access the Admin page of the appliance console.
Under Appliances, click the Node icon, then click Enter troubleshooting mode.
Click the Node icon again, then click Troubleshooting tools.
Select Provisioning, then click Apply and OK.
Add the user to the group or initiate the provisioning action.
Access the troubleshooting tools again.
Click Download CloudAccess Log Files to download the logs.
Deselect Provisioning, then turn off troubleshooting mode.
Review the logs to find the error when provisioning occurs.
Ensure that you have turned off troubleshooting mode, otherwise it will cause performance problems with the appliance.
Actions that are taken on users and groups in the identity source might not be reflected in the SaaS applications (Google Apps, Salesforce, ServiceNow, and Office 365). The following table lists the actions in the identity sources and the corresponding actions in the SaaS applications.
Table 16-3 Provisioning Actions
|
Identity Sources |
SaaS Applications |
|---|---|
|
Delete a user. (Or disable a 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. |
|
|
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. Once 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.
Issue: Users were previously able to see and access private appmarks, but they are no longer able to do so. The only change in the environment is that you are now using the filters for the connector for an LDAP identity source to reduce the search scope for importing users.
Solution: The product is working as designed. CloudAccess imports users based only on the original CN of the users. By using the filters, you are changing the search scope for the users.
If users are no longer in the search scope (as defined by the search filter), but the users exist internally in CloudAccess, those users see only public appmarks when they authenticate. The reason is that you can allow unmapped users to authenticate, but when users are outside of the search scope, CloudAccess removes the entitlements for the private appmarks.
Issue: In the customized import options of the Active Directory identity source, you create a filter for Active Directory users or groups that contain special characters. The filter returns all users and groups regardless of whether the objects contain special characters. For example, if the filter searches for groüp and you have groüp and group, CloudAccess matches on both group objects. This happens whether it is group or user objects.
Workaround: The filter search option in CloudAccess uses an ldapsearch against Active Directory. Active Directory ignores the special characters during an ldapsearch. The workaround is to create filters that do not rely on special characters.
This same filter search works properly against eDirectory.
Issue: If you use non-alphanumeric characters (such as !@#$%) in a group description in Active Directory, policy mapping may appear to be successful, but users in that group do not see the mapped appmarks.
Workaround: Remove any non-alphanumeric characters from the group description.
Issue: If you change the user or group filter to exclude some users from an LDAP identity source, and you change the naming attribute in the same operation, both the rename and the user filtering fail.
Workaround: Instead of performing both actions in the same operation, change the filter, wait for the sync, then change the naming attribute and wait for the sync.