Deprecation of Default to 'Email Verification' setting for Azure AD/ADFS connections` Migration Setting

[James.Morrison]

We are deprecating the Default to 'Email Verification' setting for Azure AD/ADFS connections on April 30th, 2021. This affects a small number of free and self-service customers with Azure AD connections created before June 10th, 2020. You may need to take action to update your AzureAD/ADFS connections before that date.

What is changing?

We will be deprecating the Default to 'Email Verification' setting for Azure AD/ADFS connections on April 30th, 2021. This change will force AzureAD/ADFS connections to use the connection level email_verified setting rather than globally defaulting to email_verified = true

Why are we making this change?

This migration flag was an interim step to implement improved security controls for AzureAD and ADFS connections. We have implemented various features to allow connection level control of email_verified defaults and simplify the email verification process for those connections.

How are you affected?

You make use of an AzureAD or ADFS connection and have not yet set the Default to 'Email Verification' migration flag to setting for Azure AD/ADFS connections to ENABLED, indicating you are still using the global default rather than the connection specific setting.

What action do you need to take?

Before you toggle the migration flag, you must ensure that your tenant is ready. We recommend the following actions:

1. Check if you are doing automatic account linking outside of Auth0 rules

• If yes, Update your account linking flow to force a user to log in with the old account before linking. (see docs)

• If no, no action needed for account linking

2. Update how email_verified is set for your users using one of the following two options:

• If you trust the administrators of your connections (i.e you validate them through some sort of onboarding process rather than having a self-sign up that isn’t verified through other means) you can simply set that connection to always set email_verified to true for users from that connection see docs.

• If you don’t verify or trust the administrators of your connections we recommend you set these connections to email_verified = false and utilize our new features for verifying emails from AzureAD/ADFS connections see docs.

3. Toggle the migration flag Default to 'Email Verification' setting for Azure AD/ADFS connections to Enabled in your tenant at a time where you can closely monitor and make sure there aren’t adverse side effects (make sure you test in your dev environment first…)

Note: The Default to 'Email Verification' setting for Azure AD/ADFS connections to Enabled migration flag will only be displayed if you have an AzureAD or ADFS connection with associated active users in your tenant.

The below flow chart provides another view of the steps to prepare for this deprecation.

We will be deprecating the Default to 'Email Verification' setting for Azure AD/ADFS connections on April 30th, 2021 and you’ll need to take the above steps before then.

How can you get additional assistance?

We are here to help. Please let us know with a new topic or below in the comments if you need assistance on this front.

[james13]

I’m seeing a contradiction above, please clarify:

Step 3:

Toggle the migration flag Default to 'Email Verification' setting for Azure AD/ADFS connections to Enabled

In the image, you show it as ‘disabled’. Then again, in the decision tree, you show to set the flag to false.

Please clarify:

1. should we be testing with this flag enabled or disabled

2. what will this setting be defaulted to after deprecation? (I assume disabled, as it will be deprecated, but please clarify the contradictions above).

Thank you!

[James.Morrison]

No problem @james13, I’ll find out these details, and I will share them with the group!

[James.Morrison]

Following up on this after discussing with the team. Enabled means you are ready for the deprecation and email verified will now be based on the value at the connection level rather than globally defaulting to true. Whereas Disabled means you are not running under the new connection-level setting and you will see a change when the deprecation occurs and the connection level setting becomes one which is always used. Please let me know if this helps clear things up!