Version Affected: All versions that support Azure AD as a data store
Overview
Authentication fails in an endless loop for realms configured with an Azure Active Directory (Azure AD) data store, when the domain used by Azure AD is federated with SecureAuth Identity Provider (IdP).
Cause
This is expected behavior given how the redirect chain is designed, and results in an authentication loop between Azure AD and SecureAuth IdP:
- The user accesses a resource protected by Azure AD, such as the Azure Portal, Exchange Online, or SharePoint Online.
- On the login.microsoft.com endpoint, the user enters their User Principal Name (UPN).
- Based on the domain in the UPN suffix, Azure AD redirects the user to SecureAuth IdP. For example, if the UPN is user@example.com and example.com is configured as a federated domain with SecureAuth IdP, Azure AD does not authenticate locally and instead redirects to SecureAuth IdP.
- Upon receiving the request, IdP checks the data store configured for the realm. If it is Azure AD, IdP redirects the request back to Azure AD.
- Azure AD again checks the UPN suffix, again finds example.com federated with SecureAuth IdP, and redirects back to SecureAuth IdP for authentication — repeating the loop.
Resolution
- If the Azure AD domain is federated with SecureAuth IdP, do not also configure that realm's data store as Azure AD. Use an on-premises Active Directory data store instead, if that is an option.
- If Azure AD must be used as the data store, convert the domain from Federated to Managed so Azure AD can authenticate the user locally instead of redirecting back to SecureAuth IdP. Sign in as an Azure AD Global Administrator and run:
Connect-MsOnline
Convert-MsolDomainToStandard -DomainName example.comWith the domain converted to Managed, the user's credentials are validated by Azure AD directly. To still enforce a second authentication factor through SecureAuth, use the Custom Controls feature in Azure AD Conditional Access policies.
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.