Register For Azure AD MFA From On-Premises Or Known Networks Only

A long request within Azure AD/Office 365 has been the request to be able to register your security info from a known location or only on certain other conditions. Well it looks like this has appeared in Azure AD in the last few days!!

Its visible under Azure AD > Conditional Access > New/Existing Policy > Cloud Apps or Actions:

So, what does this look like in practice? Lets put this preview to the test.

Create the Conditional Access Policy for User Actions

Open the Azure AD portal at https://aad.portal.azure.com and click Enterprise Applications

From here click Conditional Access (this is also accessible under Azure AD > Security as well)

Click Add Policy and give the policy a name. I have chosen “Register Security Information On-Premises” for here

Click Users and Groups. I have selected “Users and Groups” rather than “All Users” as I plan to test this out first! I have picked the group that I use for testing Conditional Access changes. Eventually I will change this to All Users so that no-one can register security info apart from when on a trusted location. Note that this would also I think include guest users – I need to test that! Guest users are by their very nature not on my network but I might have MFA required for them – so they need to register, but I don’t want to apply the below to them

Select Cloud Apps or Actions (this was recently renamed to support this functionality we are describing here)

Select User Actions in the slider and check the option for Register Security Information (Preview)

Select Conditions and select the conditions you want to apply when users are registering security information. Its probably location based, so I will set that up here.

Select Locations, click Yes under Configure and select Any Location under Include and then under Exclude select Trusted Locations. Note that you need to have set up trusted locations in Conditional Access as well – I’m going to assume the public IP of all your offices is added and marked as trusted.

This setting will ensure that all locations other than trusted locations cannot register security information – note that this is the reverse of what you might expect. We need to block the locations we don’t want to access the MFA/SSPR registration process rather than the reverse. This is because we are required to add a control to the rules

With Azure AD P2 licences you could user a sign-in risk condition, ensuring that registration does not happen on medium or high risk sign-ins!

Click Done to bring you back to the first blade of settings and set Enable Policy to On to turn on this feature

Under Access Controls, click Grant and choose Block Access – be very careful here – don’t block all your access to everything!

Click Done

This takes us back to the first blade in the Conditional Access settings.

Click On in the Enable Policy slider

Now the Create button is available – this is not available if you do not create the reverse of what you might expect to do – block unknown locations rather than allow trusted locations!

Click Create

You will get your notification – you can test this in a few minutes:

Enable The New Combined MFA/SSPR Registration Page

Though I noticed that this conditional access restriction works against the older MFA registration page, Microsoft have said in their release blog article for this feature that it will only work against the new MFA/SSPR combined registration page. Therefore you should turn this on for your users impacted by the above policy – initially for your pilot users and then for all users.

See https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Cool-enhancements-to-the-Azure-AD-combined-MFA-and-password/ba-p/354271 for more on setting up the combined MFA/SSPR registration page.

Testing Register Security Information (Preview)

In an in-private browser session on the Wi-Fi of your favourite coffee company, browse to https://aka.ms/mfasetup (as this is not a trusted location!)

After logging in you would expect to be take to the registration page for MFA and SSPR – but you are not!

Repeat your test from on-premises, and you will get the MFA and SSPR registration pages (or both if you have the new combined MFA+SSPR wizard enabled):

Note that for a brand new user where you have SSPR enabled, they are required to register by default every 180 days. This will mean they have to register at first login – therefore first login needs to be from a trusted network (in this example) – you could use Trusted Device as the only place to register from, but adding a user to a trusted device requires MFA by default, so watch out for an issue here and if you want to do this, test it very well.

I have not had the opportunity to test this with the 180 day refresh of your settings – presumably that should work from any location and only changing them would be blocked, but this is something that needs to be tried out.

Posted

8 May 2019

Azure Active Directory, Azure AD, conditional access, enterprise mobility + security, Office 365, security, self-service password reset, sspr

Brian Reid

Tags:

Comments

11 responses to “Register For Azure AD MFA From On-Premises Or Known Networks Only”

Rkast

11 May 2019

Thanks a lot Sir for mentioning this feature, totally missed it. But even better a nice detailed write up. PS what is your fav coffee (Company) ? 🙂

Reply
1. Brian Reid
  
  22 May 2019
  
  Manumit
  
  Reply
Lennard Kuijten

21 May 2019

This will also block acces een users need to change their security settings. When you select Require MFA as access control. The initial registration is only allowed from trusted locations and users van change their settings in the future.

Reply
1. Brian Reid
  
  22 May 2019
  
  It is initial registration that is restricted with this feature. Future changes are not restricted, as they are protected by MFA. If admin resets all of a users MFA settings (“require re-register MFA” via the AAD Portal > Users > Select User > Authentication Methods) then that user will be subject to the restrictions again for registration.
  
  Reply
Brian

31 July 2019

I just tested this out, and found a possible issue most likely due to our setup. We trusted certain locations and if you connect from these you never get prompted for MFA, even enrollment. If you then turn on the policy you mention it blocks access to enroll unless you are in a trusted location. Except now you have a catch 22 where you cant enroll unless in a trusted location, but the trusted location also does not prompt you to enroll. A easy solution is to have the users go to the aka.ms/mfasetup site and manually enroll, but that is not easy to enforce. Any other ideas on how to keep MFA from occurring while in a trusted location, but also lock down enrollment? Or even if we cant lock down enrollment, how to get the prompt to occur even if in a trusted location without going to the url manually?

Reply
1. Brian Reid
  
  10 August 2019
  
  Without AADP2 you cannot do this. There is no forced registration process in AAD Plan 1. Plan 2 includes Identity Access Management which includes the ability to roll out registration to a group of users and they have 14 days to register. You then, after 14 days turn on MFA for these users. You change the group and start enrollment for other group etc. With AADP1 you either ask users to register themselves and tell them the deadline and then turn on MFA if external after the deadline (which could be immediately) and so they have to register or they cannot connect from external locations. But if you already have Conditional Access in place for external users and now you want limited registration to a different location you need to have all users register before you start and add this to a part of an enforced on-boarding process (new hire etc) to catch new users.
  
  Reply
  1. Brian Lilly
    
    9 October 2020
    
    Hi Brian,
    Great post. I’ve configured this CA rule on my test tenant, limited it to a test user group and it appears to be working as expected. The concern in my head is that if specified “All Users”, would this force all users to register for MFA? I take it from what you are saying above “There is no forced registration process in AAD Plan 1”, essentially the users must opt-in and then register themselves manually? Only using Identity Protection (AAD P2) can force users to register? Can you confirm?
    Thanks !
    
    Reply
    1. Brian Reid
      
      3 November 2020
      
      “There is no forced registration process in AAD Plan 1” means that you cannot be forced to register before you hit a Conditional Access managed service, but when you do connect to the Conditional Managed endpoint you will be required to register if you have no already. The only way with Azure AD Plan 1 licence to get users to register in advance is to ask them nicely to do this (by visiting https://aka.ms/mfasetup) and giving them some time to do this before turning on Conditional Access. But that means you are delaying your rollout of security whilst waiting for your users – so ask them the register, but don’t wait too long – I would say give them a week. If you cannot do this, justify the purchase of the AAD P2 licence or just use Security Defaults instead.
      
      Reply
Bob Ryley

9 August 2019

Hey Brian,

Is it possible to force all users to use MFA prompt outside of your IP range, while only requiring MFA Registration to occur inside your IP range, but NOT require MFA inside the IP range for the Apps? In other words, you wouldn’t then have to register 100% of your users with MFA (really difficult to do with tens of thousands of users) but attackers can’t register your MFA for you outside the IP range either if you haven’t done it yourself already. I.E. A lot of users will never access the Apps outside of the company so why make them have to register for MFA then?

So to summarize…

1. Many users have not registered for MFA, and won’t ever need to use it.
2. However, I don’t want an attacker to register their MFA for them and get in remotely after phishing the users creds.
3. I don’t want it to prompt the user for registration inside the company. Registration should only occur inside an IP range, but I do not want it to prompt MFA registration when you open any O365 app, but rather require them to go to the ‘my profile’ Microsoft site or another site to register instead if they want to register MFA.

Otherwise any big company would have to register THOUSANDS of users with Smart Phones Apps / Tokens and change their new-hire orientation processes for tons of users who don’t care or ever need it in the first place. Any thoughts on how to accomplish this ?

Reply
1. Brian Reid
  
  10 August 2019
  
  So yes, you can do as you require. But I think (not tested yet, its on my list of things to do) that your users might need to register for MFA anyway. Not sure exactly, but you would use the above to restrict registration to your LAN and Conditional Access to require MFA when not on LAN (or variations on this theme, including block legacy auth and MFA for admin regardless). You might find that all users required to register but never need to use MFA for app access. That said, you are also registering for SSPR as well and all users can/should use this regardless of whether they access apps remotely. SSPR removes a basic help desk role but also ensures only the user knows and sets their own password.
  
  Regarding your comments on access to apps outside the company LAN I would say that you should look at restricting access to registered company devices only – then you can have access to anything from anywhere and use the device you access the data from as the proof rather than allow any device and require MFA from separate device.
  
  I would generally expect large organisations to MFA register all accounts or restrict their use to company devices or IPs only
  
  I run workshops on helping companies navigate their options and scenarios the above can raise if you are interested as well.
  
  Reply
2. Eddie O’Shea
  
  18 September 2020
  
  Hi Bob, Did you find a way to do this so not all users need to register for MFA? We have exactly the same requirement .
  
  Reply