Version Affected: [26.0 and earlier].
Description:
Authentication fails for realms configured with Azure AD datastore when the domain used by Azure AD is federated with SecureAuth IDP.
Cause:
As per the design, it results in authentication loop between Azure AD and SecureAuth IDP.
Example flow:
- User accesses a resource protected by Azure AD, such as Azure Portal, Exchange Online, SharePoint Online, and so on.
- On the login.microsoft.com endpoint, user enters the UPN in the username text box.
- Based on the domain name in the UPN suffix, Azure AD redirects the user to SecureAuth IDP. E.g., If the UPN is user@example.com and example.com is configured as a federated domain with SecureAuth IDP, Azure AD won't perform authentication locally, and redirect to SecureAuth IDP for authentication.
- Upon receiving the request, IDP checks the data store configured for the realm. If it is Azure AD, the request is redirected back to Azure AD.
- Azure AD again checks the UPN suffix and finds the example.com domain as federated with SecureAuth IDP, it again redirects back to SecureAuth IDP for authentication.
Resolution:
- If the Azure AD domain is federated with SecureAuth IDP, do not use Azure AD as a data store. Use on-prem AD instead, if that is an option.
- If the only option is Azure AD, consider converting the domain from Federated to Managed using the below command, so that authentication can be done locally by Azure AD without having to redirect back to SecureAuth IDP.
#sign in with Global Administrator of Azure AD.
Connect-MsOnline
#to convert the domain from federated to managed.
Convert-MsolDomainToStandard -DomainName example.com This way, the user's credentials will be validated by Azure AD. In order to enforce 2nd factor by SA IDP, use custom controls feature in Azure AD Conditional Access policies.
26.1 and later version:
In the New Experience, navigate to Entra ID datastore > Actions > View Summary > select Validate user password checkbox.
SecureAuth Knowledge Base Articles provide information based on specific use cases and may not apply to all appliances or configurations. Be advised that these instructions could cause harm to the environment if not followed correctly or if they do not apply to the current use case.
Customers are responsible for their own due diligence prior to utilizing this information and agree that SecureAuth is not liable for any issues caused by misconfiguration directly or indirectly related to SecureAuth products.
Comments
Please sign in to leave a comment.