Configuring and Migrating From Entra ID Custom Controls to External Authentication Methods

Custom Controls date back to the Azure AD days and the ability to link an external MFA provider into authentication but without the full step of federation. This feature was in preview for years and never left preview, and was limited to I think three companies. Over the years I have seen this a number of times using Duo but no-one else.

Its problem though is that is treats MFA as an outsourced feature and only works with Conditional Access, it does not report success or failure of the external MFA back to Azure AD/Entra ID and cannot be used with other features of Entra ID such as self-service password reset, risk remediation, PIM (privileged identity management), cross-tenant MFA trusts and authentication strengths (step up MFA). It will even work with the Microsoft Partner Center for MSPs, Intune device enrollment, and reporting and logging.

Just before COVID Microsoft announced this was being worked on again, and then everyone’s priorities changed. Well, this is now back and Custom Controls can be replaced with External Authentication Methods. Authentication Methods allow you to pick the best method for the person, so for example high risk individuals (say admins) could be restricted to phish-resistant passwordless authentication methods such as passkeys but all the rest of your users could stay on custom controls for now, with the ability to add in stronger methods or now other providers than the original three. And, given the above list of things that did not work with Custom Controls, it won’t surprise you to see that these now do work. So, features like password reset on high risk, but using Duo or other MFA provider to remediate the risk is possible.

And best of all, the Sign In Logs in Entra ID will now show that Multi-factor authentication (MFA) is in play. Custom Controls never reported this back to the directory.

This blog post will cover two parts. The first part is setting up External Authentication Methods with how to migrate from Custom Controls as the main part of that, and a second part in that what to do now you have a more modern authentication method in place. If you are not migrating from Custom Controls but need to implement an External Authentication Method because you have a third party authentication service in place, for example tied to AD FS, then these steps are the same but the source of the control data will be provided by your provider and not from the Custom Control.

Part 1: Migrating From Custom Controls

To start this process of migrating to External Authentication, you ideally need to have migrated your Authentication Methods to the new unified settings. This is because External Authentication Methods are just that – a new Authentication Method. You need to have either started the migration or completed it so that the Authentication Methods policies are used for authentication and SSPR (and legacy policies are ignored):

To add an External Authentication Method to replace your existing Custom Controls you need to register a new Enterprise App in your tenant. This app will live alongside the Custom Controls Enterprise App, but is a different app. This app is created and registered in your tenant based on information from your external MFA vendor – for example for Cisco Duo you need to enable a configuration in your Duo portal called “Microsoft Entra ID: External Authentication Methods” (see Cisco Duo documentation).

You leave your current Custom Control in place, and you move your users in stages to the External Authentication Method before removing the Custom Control later on. This means that though you have both apps configured, users are given either the External Authentication Method or the Custom Control based on the Conditional Access policy they are configured to use.

Once you have created the new Enterprise App as described by the vendor, go to the Entra ID Admin Portal > Protection > Authentication Methods (here) and click “Add external method” at the top of the page.

You then need to provide the information required. This is obtainable from your External Authentication Method provider. The name is added, and this is fixed once saved. This name appears in the admin portal, and also in the login screen when the user picks their method if they have more than one choice – so choose well. The end user will see “Approve with NAME”, so the below would appear as “Approve with Duo” to the end user.

In addition to the name, enter the Client ID, Discovery Endpoint and App ID also found in the vendors MFA settings page in their portal or instructions. The App ID is the new Enterprise application that was just created in your tenant.

Then click “Request Permission”. This will consent the correct permissions. You need the Privileged Role Administrator or Global Administrator role to grant admin consent.

You will be presented with a consent dialog as shown. This will be the new Enterprise app just created. After consent the app will gain the Microsoft Graph permissions of “profile” and “openid” as shown in the dialog:

Once consented, click Save in the page to create the External Authentication Method. The “Request Permission” button does not change when I was completing these steps and stays blue even though the permissions are granted. Returning to this dialog later and the permissions and set up part of the control will shown via the Configure tab of the External Authentication Method.

Logging in as a user that uses the Custom Control at this point still works – nothing of the changes above breaks the older Custom Control.

On the Authentication Methods page you will now see your new External Authentication Method:

From here you would click your new External Authentication Method and enable it for a pilot group, or if you want for All. To enable it, move Enable to On and then click Add Target and select your pilot group.

Click Save, and then you can test your users who are members of your pilot group. If you set it for All, it will only trigger when a user’s Conditional Access policy says to use “Require Multifactor Authentication” or “Require Authentication Strength”. If the Conditional Access policies are still triggering the older Custom Control then the user will still get their older login experience.

If your External Method vendor does not support just in time registration, and you need to be registered before you can use the external method, then do not enable the External Authentication Method for all users. If the method is enabled for you, but you cannot use or have not registered with the external vendor then you could be routed to the vendor that you get stuck during login. Therefore, only enable the method for users that have already registered with the vendor or where the vendor supports just in time registration.

If you find that you cannot enable your External Authentication Method when migrating from Custom Controls, you can use the Microsoft Graph to complete this.

You can bypass any issue and turn on the External Authentication Method using Microsoft Graph (or the Graph Explorer) as well as add the pilot group to use (miss “includedTargets” out to enable with All Users):

PATCH https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/<External-Auth-Method-ID>

Plus the below Request Body.

{
    "@odata.type": "#microsoft.graph.externalAuthenticationMethodConfiguration",
    "state": "enabled",
    "includeTargets": [
        {
            "targetType": "group",
            "id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
            "isRegistrationRequired": false
        }
    ]
}

The External-Auth-Method-ID (the ID of the External Authentication Method) you can obtain from the Microsoft Graph with the GET request against https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy. The GUID of the group is the Object ID of the group that you want to enable the policy for. To enable it for all users, use either “all_users” or don’t set a group (includeTargets) in the initial setup.

This ends part one of blog post, setting up the External Authentication Method.

Part 2: External Authentication Methods User Experience

Now that you have turned on External Authentication Methods for a group (or all users, but hopefully that is in a test tenant) we can check out the user experience.

Before you enable External Authentication Methods you got this:

Username, followed by password entry (branded dialog), redirected to the Custom Control provider (Duo in this case, which will look different if using Duo’s Universal Prompt option) and then a “Do you trust yourdomain.com” question which has been in this flow since April 2023.

Once External Authentication Methods is enabled you can sign in again (recommend using an in-private browser session to avoid cached tokens etc. unless you have device specific rules, then do your testing by signing out of the standard browser and not in-private browser). You will see this flow instead (visiting https://portal.office.com as some other endpoints might give a slightly different flow):

Note that you might still see the existing original Custom Control flow. This will be likely due to your Conditional Access rules. If you have a Conditional Access rule that forces the use of the Custom Control then you will need to create a Conditional Access rule for your test group and configure that rule to use “Require Multifactor Authentication” rather than your Custom Control.

Also ensure that your group is exempt from your standard Conditional Access rule that forces the Custom Control. Check your Sign-In logs to see what Conditional Access rules you hit and which ones need updating. If you don’t exempt the original Conditional Access rule you will login to your external MFA provider via the Custom Control and then be redirected to the External MFA vendor and so see two MFA prompts for one login.

There is a possibility that External Authentication Methods do not work with Duo when the Universal Prompt is not enabled, as the Traditional Prompt ended support in March 2024.

External Authentication Methods send the username to the vendor as the User Principal Name. With Custom Controls this was not the case, and you could (depending upon the vendor) manipulate the username in the vendor. For External Authentication Methods the vendor will need to have a user account listed by UPN and not samAccountName or other name alias.

Part 3: What To Do With Authentication Methods

Once you have logged in using your new External Authentication Method, and all your other users are still using the Custom Control, you can look at enabling other features in Entra that now work with External Authentication Method. If you have rolled out your new External Authentication Method to a group, then use that group to turn these features on. This blog post won’t discuss configuring these features, but they are now available to you whereas they where not when using only Custom Controls.

1. Risk – create conditional access rules that allow risk remediation (Entra ID P2 licence required). When a user goes risky the MFA prompt to remediate will be your new External Authentication Method
2. PIM – create rules so admins are not admins all the time (Entra ID P2 licence required). MFA is needed to proof up for Privileged Identity Management (PIM) and so your new External Authentication Method can be used for this
3. Registration Campaign – probably set to disabled already, and if not it should be. This is to push users from SMS based MFA to Microsoft Authenticator. If later Microsoft allows the Registration Campaign to push the user to the External Authentication Method, this could be enabled then.
4. External Identities MFA Trust – when you configure multiple tenants (either Multi-Tenant Organization, or MTO, or partner tenants) for sharing and user sync you can ensure that Conditional Access rules take the external users MFA settings and trust them in the target tenant. External Authentication Methods supports this trust whereas Custom Controls did not. Now your partner tenants can now avoid asking you to set up a separate MFA prompt per tenant.
5. [Available Later] System Preferred Multifactor Authentication – choose which auth method should be selected by default because it is considered more secure. This should be disabled at this time as it does not work with External Authentication Methods in the initial release. If you do have system preferred enabled then you will get a different method (your system preferred one, the one Microsoft thinks is the most secure) prompting automatically – for example you will get a push to Microsoft Authenticator if you have that enabled.
6. [Available Later] Authentication Strengths – you can control which authentication methods you allow your users to register – for example, you can set a phish resistant method (device bound passkey for example) and your new External Authentication Method.
7. [Available Later] Self Service Password Reset – add your group to SSPR. Your new External Authentication Method can be used as a password reset proof if you need to reset your credentials. You need to have migrated Authentication Methods to use this feature.
8. [Available Later] Primary authentication – currently External Authentication Method is considered a second factor.

Custom Controls will be depreciated and the dates for this will be announced once External Authentication Methods goes to general availability.

Photo by Noah Erickson: https://www.pexels.com/photo/turned-on-black-samsung-android-smartphone-displaying-clock-at-12-09-404280/