Known issues and troubleshooting related to IdP setup in Cloudera

Known issues with mutable SAML NameID or SCIM userName

Issue (If using SAML without SCIM):

If you use SAML without SCIM, and you set the SAML NameID field to a mutable Azure AD field (such as an email), then you will end up with duplicate users in Cloudera when the Azure AD value changes. The duplicate user is a new, different user that has a different Cloudera workload username. This is because SAML has no way to differentiate between two different users and a user whose SAML NameID has changed.

Issue (If using SAML with SCIM):

If you are using both SAML and SCIM, you must set the SAML NameID and the SCIM userName fields to the same Azure AD field. If that Azure AD field is a mutable field, when it changes you will end up with duplicate users in Cloudera. This will cause errors in your Azure AD Enterprise Application and SCIM updates to the user will fail.

Workaround:

There is no automatic way to recover and you will likely have to delete and recreate the affected user. This includes having to delete and recreate the user's permissions, passwords, keys, and so on. If this happens, contact Cloudera support.

Known issues with Azure AD User Principal Name (UPN)

While uncommon in practice, the Azure AD UPN is actually a mutable field. Ask your Azure AD team if your organization mutates UPN before using it.

By default, when users are deleted in Azure AD they are moved to a "recently deleted" list for 30 days, before they are permanently deleted and removed from Azure AD. When a user is moved to the "recently deleted'' list, their UPN is automatically changed by Azure AD. This will cause SCIM errors to show up in your Azure AD Enterprise Application: The error is Azure AD trying to update the userName field, and Cloudera returning an error saying that operation is not supported. These errors can be ignored.

Note that even though users in Azure AD are in the "recently deleted" list, they will persist in Cloudera as active users until after the 30 day wait time when they are fully removed from Azure AD (deleted from the Azure AD system). At that point SCIM will delete them from Cloudera as well. If you permanently delete the user from Azure AD before the 30 day period (that is, delete the user from the "recently deleted" list), then that user will also be deleted in Cloudera. If neither of these options work for you, then you must delete the user manually in Cloudera.

Known issues with updating group names

Updating group names is rare - most organizations do not do this. Cloudera does not support updating group names. To fix the issue, create a new group instead.

Inconsistencies while syncing groups through SCIM and SAML

When configuring Cloudera on cloud, you may encounter inconsistencies in group membership synchronization if both SAML SSO Group Sync and SCIM are enabled simultaneously. The following conditions can lead to these inconsistencies:

• The user belongs to more than 150 groups in Azure AD.
• Certain groups exist exclusively in Azure AD and are not synced through an on-premises Active Directory (AD). Consequently, Azure AD transmits the group's "objectId" GUID within the SAML "groups" claims, which fails to fulfill the group naming standards required by Cloudera.

In these situations, SCIM should be the sole mechanism used for synchronizing user profiles and group updates, instead of utilizing both SAML and SCIM. You can turn off the group synchronization through SAML using one of the following steps:

• Using the Update Identity Provider action in Cloudera Management Console: Navigate to the User Management page and select Identity Providers > .
• Using the API/CLI/SDK and setting Sync groups on Login: Disabled for your Identity Provider in Cloudera.

Troubleshooting SCIM Synchronization Failures