Enabling SSO Locks Out Users: Recovery Options – DataHub Customer Support Portal

Area: Deployment Issues

Sub-Area: SSO / Authentication Configuration

Issue

After enabling Single Sign-On (SSO) on a DataHub Cloud instance — for example, configuring an OIDC provider such as Microsoft Entra ID (formerly Azure AD) — users may find themselves unable to log in. The SSO flow may appear to proceed normally (redirecting to the identity provider, prompting for credentials) but ultimately returns an access denied error. Compounding the problem, disabling SSO through the DataHub UI does not immediately restore the ability to log in via username and password, leaving administrators effectively locked out of the instance.

Error Messages

access_denied
End-user does not have access to this application
loginDenied ... loginDenialReason=NOT_PROVISIONED
loginDenied ... loginDenialReason=SUSPENDED
loginDenied ... loginDenialReason=SOFT_DELETED

You Might Be Asking

Why does SSO fail with "access denied" even though the user can authenticate with the identity provider?
Why am I still locked out after disabling SSO in the DataHub UI?
How can I regain admin access to DataHub when SSO is misconfigured and no native (username/password) login is available?
Is there a way to bypass SSO to reset the OIDC configuration?

Solution

Step 1: Understand the Root Cause

There are two distinct failure modes typically seen in this scenario:

Identity provider rejection (access_denied): The error originates at the IdP level, not within DataHub. For Microsoft Entra ID, this commonly occurs when User assignment required is enabled on the enterprise application but the affected user(s) have not been assigned to it. Entra returns access_denied to DataHub's OIDC callback, which DataHub surfaces as a login failure.
Persistent lockout after disabling SSO: Disabling SSO in the DataHub UI changes the configuration for new sign-in attempts, but existing browser sessions may still route users through the SSO flow. Additionally, native username/password login only works for users who already have a native password set in DataHub. If no administrator has a native credential, the standard /login page cannot be used without intervention.

Step 2: Resolve the Identity Provider Configuration (Microsoft Entra ID)

If the error is access_denied from your IdP, correct the assignment settings in Entra:

In the Azure portal, navigate to Microsoft Entra ID → Enterprise Applications.
Select your DataHub application registration.
Go to Users and groups and add the affected users or a security group that contains them.
Alternatively, navigate to Properties and set Assignment required to No to allow all users in the directory to authenticate.
Have the user attempt to sign in again.

Other common Entra/OIDC configuration issues that can cause login failures include:

An expired or incorrect client secret — generate a new secret and update it in DataHub's SSO settings.
An incorrect OIDC discovery URI — ensure you are using the application-specific discovery URI provided by your IdP.
A signing-key mismatch between the IdP and DataHub's OIDC configuration.

Step 3: Regain Admin Access via an Invitation Link (Emergency Recovery)

If no administrator can log in through any available method, DataHub Support can issue an admin invitation link. This link allows a designated user to register and authenticate using a native username and password, completely bypassing the SSO flow. This is the standard emergency recovery procedure for SSO lockout situations on DataHub Cloud.

Contact DataHub Support and request an admin invitation link. Provide the email address of the user who should receive admin access.
DataHub Support will send the invitation link to the specified email address.
Click the link in the email. You will be directed to set up a native (username/password) credential.
Once registered, navigate directly to the native login page:
```
https://<your-instance>.acryl.io/login
```
Sign in using the username and password you just created. This bypasses the SSO redirect entirely.
Once logged in, navigate to Settings → SSO to review and correct the SSO configuration, or disable it while troubleshooting.

Step 4: Diagnose DataHub-Side Login Denials (Advanced)

If the IdP configuration appears correct but login still fails, DataHub itself may be rejecting the user. Check the DataHub frontend logs for lines containing loginDenied. The loginDenialReason field indicates why DataHub rejected the session:

NOT_PROVISIONED — The user account has not been provisioned in DataHub.
SUSPENDED — The user account has been suspended.
SOFT_DELETED — The user account has been soft-deleted.

Example log pattern to search for:

loginDenied ... loginDenialReason=NOT_PROVISIONED

These reasons indicate DataHub itself is denying the user, independent of the IdP response. Contact DataHub Support with this log information for further assistance.

Additional Notes

The admin invitation link recovery method applies to DataHub Cloud instances. Self-hosted deployments have additional recovery options (e.g., directly modifying environment variables or the database) that are not covered here.
Disabling SSO via the DataHub UI takes effect for new login attempts but does not invalidate existing browser sessions. Users with active sessions should clear cookies or open a private/incognito window to force a fresh login attempt.
Native username/password login via /login is only available to users who have a native password configured. Users who have exclusively authenticated via SSO will not have a native password unless one was set during initial account creation or via an invitation link.
Always test SSO configuration in a non-production environment before applying it to a production instance. Ensure at least one administrator retains a native (username/password) credential as a break-glass emergency account.
If you receive an access_denied error, record the exact error text and any error codes returned by your IdP and share them with DataHub Support to accelerate diagnosis.