Microsoft Secure Tech Accelerator
Apr 03 2024, 07:00 AM - 11:00 AM (PDT)
Microsoft Tech Community
Conditional access for the Azure AD combined MFA and password reset registration experience
Published May 16 2019 12:05 PM 64.2K Views

Howdy folks,

 

More and more organizations are using Multi-Factor Authentication (MFA) to protect their access and self-service password reset (SSPR) to reduce support costs and empower their users to manage their credential recovery. Our internal studies show that customers can cut their risk of account compromise by 99% by enabling MFA, so we’re REALLY happy to see this growing trend.

 

With this increasing usage, we also heard loud and clear that you want to control the conditions in which security sensitive MFA or SSPR information can be registered. This helps ensure it’s the right user—not an attacker—registering this security sensitive info.

 

Some common restrictions you requested include ensuring that:

  • Users are on a trusted network.
  • Only users with a low sign-in risk can register security information.
  • Users can only register on a managed device.
  • Users should agree to a terms of use during registration.


We heard you loud and clear!

 

Today, I am excited to announce the public preview of Azure AD conditional access for our combined registration experience for MFA and SSPR. Many of our largest customers have already been using this while it was in private preview to simplify rolling out MFA and SSPR and we’re looking forward to making it more broadly available as part of Azure AD Premium P1 subscription.

 

Here are some instructions to try this out!

 

Getting started

First, create a policy to block registration for users that are not on the corporate network, but are still allowed to manage credentials from anywhere, as long as they can use MFA.

 

Next, make sure that all users you want to apply this policy to are part of the MFA and SSPR preview. This is required because users not on the preview will use the older security information page and the policy will not be enforced.

 

Steps for setting up policy

 

  1. Include the users the policy will apply to using the Users and groups.
  2. Apply policy to the Register security information action, which is now included in the Cloud apps or actions.

    Conditional Access for the Azure AD 1.png

  3. Set the Locations. Include Any location; exclude all trusted networks.

  4. Set the access grant control to require multi-factor authentication.
  5. Enable policy and Save.


Now, if a user is outside of a trusted network and attempts to register MFA for the first time, they’re blocked and shown the following message:

 

Conditional Access for the Azure AD 2.png

 

As soon as they register MFA, they’ll be able to manage MFA and SSPR registration details from anywhere.

 

Go ahead and give it try today!

 

See our Azure AD conditional access documentation for additional information. We’d also love to hear your feedback. If you have a couple minutes please consider filling out our survey. You know we’re listening!

 

Best regards,

 

Alex Simons (Twitter: @Alex_A_Simons)
Vice President of Program Management
Microsoft Identity Division

39 Comments
Copper Contributor

In your example Alex, why are trusted locations being excluded? It feels like this is the wrong way round if you only want to allow MFA registration from a trusted location?

Microsoft

Quick comment: The link under " I am excited to announce the public preview of Azure AD conditional access"  is pointing to another very exciting but different Azure AD feature.

The correct link to the conditional access for the combined MFA/SSPR registration is: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-registration-mfa-sspr-c... 

@Phil Cook because the policy blocks access to the registration page. The rules of the policy is block access unless on a trusted network.

 

You cannot do an allow if on trusted network policy because a user not on the trusted network would not be subject to the policy and therefore would get access to the registration page. See https://c7solutions.com/2019/05/register-for-azure-ad-mfa-from-on-premises-or-known-networks-only which I wrote up last week on how to set this up. 

Copper Contributor

This sounds promising! Since you mentioned a few examples I guess you have it on the roadmap. Can you share any more information on when it will be possible to require users to accept terms of use, and to require managed devices?

Copper Contributor

Is it possible to do the same, but when the user is already registered?

Meaning, if I want to force all of my users to use Authenticator App instead of sms or calls.. ?

Copper Contributor

Nice! We are already using the new portal and to be able to lock down MFA enrollment is perfect. 

Access is blocked as expected from an untrusted device but from this device we are still able to enroll for MFA when using Word. If you add an account in Word from an untrusted device with a new user account (our CA policy needs MFA or hybrid joined deviced or compliant device) it tells the user to enroll for MFA and this works from word but not from the browser. 

Any idea how to fix this?

Microsoft

@mattiasnyholm, these examples are possible today using the preview. Instead of requiring MFA as the required access control just pick a terms of use page or require a compliant device.

 

Microsoft

@andrii_ua, that's outside of this feature, but on the roadmap.

Microsoft

 

@Rolf Troendle, I just tried to reproduce this using Office ProPlus and wasn't able to. Let me know if you are still seeing this and we can take a look.
Copper Contributor

@caleb_b  Thank you for your reply. I have just tried it again and I was blocked by CA - so everything is fine

Copper Contributor

Is it possible to use CA to only allow password resets from a trusted network? I can't seem to find this anywhere. The above allows registration from a trusted network only, we'd love to go one step further and only allow the use of SSPR from the trusted network as well.

Anyone seen or done anything like this before?

Copper Contributor

Its possible to bypass the MFA setup block with the new "Baseline policy: End user protection" policy. If you click "Skip for now (14 days until this is required)" box it will successfully log you into the Office 365 portal without requiring MFA setup, or blocking access.

 

 

Copper Contributor

Hi, i've created a policy just to test this and I can't get it to work on my own account.

Does this only apply the very first time a user enrolls their MFA? As in, i've destroyed my app's token for this tenant and attempted to re-register my MFA details through the normal process from different un-trusted networks and it does not prevent me re-registering my MFA.

 

I've set up the policy exactly as described above but when I audit the sign-in, the conditional access policy is not triggered at all no matter which network i attempt to re-register from. Appreciate any ideas you may have?

Cheers

Copper Contributor

Beautiful, thanks @Brian Reid. Working nicely after I enabled the access panel preview features.

Yes - MFA registration blocks only work against the latest registration page

Copper Contributor
Hello, I followed your instruction to enforce MFA registration with a trusted network only. It is working well, user is well blocked when accessing https://aka.ms/mfasetup from an untrusted network. However a user, without MFA registered, can still enroll a new device in Intune (MFA is required) on an untrusted network and it will ask him to set up his account for additional security verification. Then he is able to setup the MFA on this untrusted network. Thanks for your feedback on this Guillaume
Copper Contributor

Did anything break in this condition lately?

It used to work before, but now, even when I set a condition to block registration from Any network even, it just nicely continues to the registration page.

@Alex Simons (AZURE) @Sadie Henry I read in the Azure update notice that this enhanced registration wizard is going out of preview on Setp 25th. Does this just replace the earlier preview that has been around two or so years or both it and the original registration process that has been in Azure AD for almost since it started? 

Steel Contributor

@Brian Reid I wonder this too. Where did you actually see this announcement in your tenant? I want to check it too for our customer’s tenant since we’re right now rolling it out to 10.000+ users and making it GA is definitely something that would make it easier from a support perspective.

Jonas - no announcement in the tenant. There was an email to affected Admins and the notice was in the What's New in Azure AD blog page.

 

Sadie on Twitter said that the settings for the original preview are merged with the new preview on 25th. It does not affect the original registration wizard at this time

Copper Contributor
Good morning Is there a way to let the user opt-in for MFA at his earliest convenience if within a grace period ? I try to explain the scope. I'm going to enable MFA for a large number of users, however I want to give them 40 days to self-register for MFA. After that period all users will be enabled in a bounce. 1) I cannot do it enabling them in Office365 admin page otherwise they will receive immediately a MFA request as soon as they access any Office365 Application. 2) If they are not enabled and they go to https://aka.ms/mfasetup they register only the security info and after that MFA, is requested only if you access again the mfasetup and nothing is requested for the other O365 resources. 3) Is there a way to activate MFA for all O365 when you register your info on mfasetup page ? Maybe with a conditional access when you visit a specific url ? Thanks
Copper Contributor

@Chris2705: yes it is for 14 days with "Multi-factor authentication registration policy". 14 days is not configurable and you need Azure AD Premium P2 for this policy.

What we have done is telling the users to pre-register during the next 14 days and afterwards we enforced it using CA.

Reference: https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/flows

 

@Chris2705 the new (in preview) feature of  "Baseline Policy: End user protection" also does this. 14 registration window and implements MFA on a risky sign in. Impacts all users, including break glass accounts (unfortunately @Alex Simons (AZURE)) but does not require AADP2 license 

Brass Contributor
@Alex Simons (AZURE) Can you clarify a detail about this capabilty. After implmenting a CA rule to block registration from outside our internal network, would the same CA rule prevent the user from updating their contact information from outside the network? The distinstinction here is an intitial setup vs and update to existing information?
Microsoft

Hi @Manoj Sood ,

 

This capability will apply to registering and managing strong authentication information. This includes the phone number used for strong authentication. It doesn't cover contact info. The phone number a user would register for contact info is stored separately than the number they would register for strong auth. So this policy will not impact updates to contact info. The strong auth and contact phone number are stored separately for a variety of security and privacy reasons. For example, just because somebody registers a phone number for strong auth it doesn't mean they want it published to their organization as contact info.

@Manoj Sood the CA rule can be used to block registration only. Once you have registered further updates are not blocked because once you have registered you need to use MFA to make any changes to your MFA settings (and as mentioned above, these are not your contact details). If your IT department resets your registration you will need to be in scope of the CA rule, but only to register again. 

Brass Contributor
@caleb_b Thanks for the reply. I should have been a little more specific in my question. The "contact info" I was referring to is "Authentication Contact Info" found on the users AAD account in the "Authentication methods" blade. This contact info is not published as part of any organizational contact info that I am aware of. Scenario: CA policy prevents user from initial registration outside corp network. User gets new phone and is unable to receive SMS message for SSPR until info is updated. The same reasons for not wanting users to do their initial registration apply to preventing users from updating their Authentication contact Info from off the corp network. Should a CA rule blocking user registration also block updating info?

User gets new phone and is unable to receive SMS message for SSPR until info is updated

@Manoj Sood Only if the phone number on the new phone has changed. If its the same number then SMS will work.

As I mentioned above, updates are not registration. You can update from wherever because you have to do an MFA proof to get to the https://aka.ms/mfasetup page. 

Brass Contributor
@Brian Reid My scenario was "User gets new phone and is unable to receive SMS message" so a new number would be involved. You of course correct that a new phone with the same number would not have an issue. Bottomline is that updates are not blocked by CA rule. Thanks for clarifying that for me.

i have already registered for MFA, now i want to block the registration MFA setup from Un trust network.. i have implement the same, but still allows after the authentication with MFA

Copper Contributor

When I enabled this in our tenant. Hello device registration is failing. In-fact all MFA device registration is failing as it is landing in My Apps portal.

after i enable this setting, it force me to register in the internal network...please let us know whether it will force who does not registered before or for all the users 

Microsoft

@Sankarasubramanian Parameswaran If the user has already registered before and the conditional access policy was configured with grant control to require multi-factor authentication as per the blog instruction. These users will just perform MFA to update security information. 

@DeorVikas  we have tested this option and even update not working from outside.  This is good secured ,but want to make sure that that is the right way to test.

Microsoft

@Sankarasubramanian Parameswaran do you have block access or grant access and require multi-factor authentication selected in the policy. If you have block access selected then this will currently apply the conditions on already registered users updating registration information. However, if you have grant control set to require multi-factor authentication as per the blog instruction. These users will just perform MFA to update security information. 

Copper Contributor

Is it possible to use CA to only allow password resets from a trusted network? I can't seem to find this anywhere. The above allows registration from a trusted network only, we'd love to go one step further and only allow the use of SSPR from the trusted network as well.

Brass Contributor

What will happen when the new combined reg workflow takes effect on Sept 30th 2022. Will this still work?

Enable combined security information registration - Azure Active Directory | Microsoft Docs

 

When testing in lab I was unable to access the new workflows such as https://aka.ms/MySecurityInfo, https://mysignins.microsoft.com and https://myaccount.microsoft.com

 

 

Brass Contributor

Thank you for implementing this! It greatly helps users & orgs to stay in the bell curve, as advised in the newest report:

http://aka.ms/mddr

 

Version history
Last update:
‎Nov 09 2023 11:10 AM
Updated by: