How to Prevent Signup and Password Reset for Azure AD Enterprise Connection Users?


We’ve successfully integrated Auth0 with an Azure AD Enterprise Connection for one of our enterprise customers. Authentication is working as expected, but we’re facing challenges in handling signup and password reset scenarios for users who belong to this enterprise connection.

The Issue:

  1. When an Azure AD user tries to sign up, they’re asked for a password, which isn’t applicable for SSO users.
  2. The same issue exists for password reset.

What We’ve Tried:
We attempted to handle this in Auth0 Actions (Pre-User Registration Action and Post-Change Password Action ), but these actions not getting triggered.

This doesn’t seem to work as expected. Any suggestions or best practices for handling these scenarios would be greatly appreciated.

Thank you.

Hey there and welcome to Auth0!

I’m not sure if I understand your issue - is it that you are being redirected to the Auth0 Login page with:

connections by default?

To redirect your users to the Microsoft Azure AD page to log in, you will have to add a relevant connection parameter = name of your Enterprise connection, to the /authorize request:************azure-ad

So that users are redirected to this page:

When you set up your enterprise IdP connection, remember that the connection parameter passed to Auth0’s /authorize, /whr, or /wsfed endpoint will redirect to the upstream IdP unless it’s connected via database or Active Directory.

If you found this post helpful or interesting, please give it a like :+1: . Your interaction makes a difference. Have a wonderful day! :sun_with_face:


:video_camera: Prefer how-to videos instead of written docs? We’ve got you covered! Check out our OktaDev YouTube channel for those helpful resources!

Thank you for your response, but I think there may be a misunderstanding. Our issue is not with the login redirection; that part is working as expected. Users with emails that belong to the enterprise connection are correctly redirected to Microsoft Azure AD Login when using the Identifier First Profile in Universal Login.

Our challenge is specifically with the signup and password reset scenarios for these enterprise connection users. When a user with an email domain that belongs to the enterprise connection tries to signup or reset their password, they are prompted to enter a password, which is not applicable for SSO users.

We’ve tried to address this using Auth0 Actions, specifically the Pre-User Registration Action and Post-Change Password Action, but these actions are not getting triggered for enterprise connection users.

We’re looking for suggestions or best practices to handle these signup and password reset scenarios for users who belong to an Azure AD enterprise connection.

Thank you.

Thank you for clarification - for the Identifier first authentication there is indeed also a sign up button users can choose.
The Pre-User Registration Action - just to confirm - serves for the db and passwordless (not enterprise) connections.

Leaving the topic open so possibly the community can help.
What comes to my mind is to conditionally “force” users with the domain specific email to be redirected right to the Azure AD login page when clicking the login button in the SPA, but I believe the logic for this would require to be applied on the app side and leverage some localstrorage data of enduser or some additional step for the user before redirected to the relevant login page.

I’m pretty sure Home Realm discovery may help you here. If you define the domain name in the enterprise connection both the registration and password reset will behave differently.

When you enter the matching email domain during sign up the screen changes once the email is complete
Clicking on the Log in button sends you to the enterprise IdP
When you try to do a password reset you get this
Pretty sure this is what you want - this is all standard out-of-the-box but from memory it is in ‘classic’ rather than ‘universal’

Thanks Rob for the response. Domain is already on Home Realm Discovery. Universal login acts differently than classic. The classic’s behaviour is what we want. I think it is kind of a bug or missing feature on universal login.

Hi @it119
This same behaviour is what we are also looking into. Did you find any solution for this?