From Feb 29th 2020 Microsoft will remove the “baseline policies” from Azure AD. These were very useful in the past to enable blanket settings like MFA for all admin accounts (well, selected admin roles) and to disable legacy auth for the same admin roles.
With the removal of the baseline policies you need to ensure that before Feb 29th 2020 you have a replacement policy/policies in place. If you are reading this blog post after that date these steps will help you implement MFA for admin roles without using the Microsoft Security Defaults.
The Security Defaults are great for tenants without Azure AD P1 or higher licences (including Enterprise Mobility + Security E3/E5 licences) as they turn all this security on for you. If you have Azure AD P1 or higher licences (including Enterprise Mobility + Security E3/E5 licences) then you can use Conditional Access instead.
These steps below will implement a rule to allow selected admin roles to login only if they perform MFA successfully and to block legacy authentication for the same roles. The configuration below will also include a break glass account so that you always have a way to bypass this security should the need arise (loss of auth code generator device, outage at Microsoft that stops MFA working etc.).
1. Create Conditional Access Policy to force MFA for admin roles
Create a new policy called “Protect All Administrators – Require MFA for All Logins” and set the following options
Users and Groups > Directory Roles > select all roles relevant to your organization. Suggest selecting all those that end “Administrator” as a minimum and maybe include Global Reader as well.
Users and Groups > Exclude tab > Exclude the group that contains your break glass accounts. If you have not done this yet, go and do it and then come back here. As a minimum exclude your account for now.
Cloud apps or actions > All Cloud Apps
Conditions > Client Apps > deselect “Other Clients” to remove clients that only do legacy authentication
Grant > Require multi-factor authentication
Report Only – this is to make sure that we do not lock ourselves out by getting this wrong – we change it to “On” later once we know it is working
2. Create a policy to block legacy authentication clients from doing administrative actions
Create a second policy called “Protect All Administrators – Block Legacy Authentication” and set the following options:
Users and Groups > Directory Roles > select all roles relevant to your
organization.This list will need to be identical to the above list, and when in future you edit the above list because Microsoft add new administrative roles, you need to match those changes to this policy list as well.
Users and Groups > Exclude tab > Exclude the group that contains your
break glass accounts.
Cloud apps or actions > All Cloud Apps
Conditions > Client Apps > deselect all options except for “Other Clients” to remove clients
that do modern authentication (therefore deselect browser and modern clients).
Grant > Block Access
Report Only – this is to make sure that we do not lock ourselves out by
getting this wrong – we change it to “On” later once we know it is working
3. Future changes
As mentioned above, when Microsoft release new administrative roles, you you add the first person to a new role you have not used before, come and edit both of these policies to include that administrative role.
Once you are sure that the policy is working (by reviewing the Conditional Access reports) change the policies to “On” instead of “Report Only”.
This article will look at the various different MFA settings found in Azure AD (which controls MFA for Office 365 and other SaaS services) and how those decisions impact users.
There is lots on the internet on enabling MFA, and lots on what that looks like for the user – but nothing I could see that directly laid out all the options and the impact of each option.
The options that the admin can set that I will cover in this article are:
Default settings for the MFA registration service
The enhanced registration service (now depreciated)
The refreshed enhanced registration service (MFA and Self-Service Password Reset registration combined)
The general impact to the user is that the user needs to provide a second factor to login. In this article I will not detail the above registration for each of the second factors and only cover the general process of registration – your exact experience on registration will depend upon what second factors (app notifications, app code, phone call and text message) you choose to implement.
This article will look mainly at the different between having no MFA and what happens from the users perspective as the admin turns on a requirement to have MFA. The various options that the admin can use to enable MFA are as follows:
Office 365 MFA (aka the legacy method) that is available to all users with or without a licence
Azure AD Conditional Access and setting a rule that requires MFA (when the user is not registered)
Azure AD Premium 2 licence and MFA Registration (register without requiring MFA to be enabled)
Azure AD Free fixed Conditional Access rules (MFA for all users) which is in preview at the time of writing (Aug 2019)
Terminology and Settings
This article refers back to a series of different settings in each of the following sections. To make the article avoid repeating itself, this section outlines each of the general settings, what I mean by the description I use and where I turn that setting on or off.
Office 365 MFA – This is the legacy MFA options set via https://admin.microsoft.com > User Management > Multi-Factor Authentication. This user experience turns on or off MFA for users regardless of app or location (unlike Conditional Access) and has settings for the different second factor methods (for example you can disable SMS from here).
Conditional Access Based MFA – This is where you set rules for accessing cloud apps based on the user, the location, the risk (P2 licence required), the device (domain joined or compliant), the location (IP), the device risk (MDATP licence required), compliance (Intune required) etc. If you rule requires MFA and the logging in user passes the requirements for this rule (and is not otherwise blocked) then this is what I call Conditional Access Based MFA. This is set in https://portal.azure.com > Azure Active Directory > Enterprise Applications > Conditional Access
Azure AD Premium 2 MFA Registration – This is where you can get users to register before you turn on MFA via either of the above routes. Without the P2 licence you turn on MFA and at the next login the user needs to register. With P2 you can turn on registration at login without forcing MFA. You would then enable MFA later or you can have registration at next login (and defer that by 14 days) so that the user registers even if they never hit an endpoint that the need to do MFA on. For example, MFA when external and the user never works remotely. Therefore they will never have to do MFA and therefore never be required to register – which P2 licence you can get them to register independent of the requirement to do MFA. You access these settings via https://portal.azure.com > Azure AD Identity Protection > MFA Registration
Self Service Password Reset Registration – This is shown if the user is in scope for SSPR and SSPR is enabled. This is not MFA registration – but if the user is in scope they will be asked to register for this as well. This therefore can result in two registrations at next login – one for SSPR and one for MFA. We will show this below, but it is best if you move to the combined MFA/SSPR registration wizard mentioned below.
Enhanced Registration (Depreciated) – This was the new registration wizard in 2018 and have been replaced by the next option. If you still have users on this option you will see it, otherwise the option to enable this older wizard is now removed. This is accessed via https://portal.azure.com > Azure AD > User Settings > Manage user features preview
Combined MFA and SSPR Registration – This is the current recommended MFA registration process and it includes self-service password reset registration as well. You should aim to move your settings to this. All the new MFA reporting and insights are based on this process. This is accessed via https://portal.azure.com > Azure AD > User Settings > Manage user features preview. Note that if you still have users on the previous “Enhanced Registration” shown above then this one is listed as “enhanced”. If not – if only one slider is shown – it is the new registration process. You can enable this for a group of users (for pilot) or all users:
Office 365 MFA + Original Registration
This is not recommended to be used any more – use the Azure AD Free Conditional Access rules for all users or all admins instead. But for completion of the process to show all the options, you select a user(s) in the Office 365 MFA page and click Enable. In the below screenshot we can see that Cameron White is enabled for MFA. This means that it has been turned on for him, but he has not yet gone through the registration wizard:
The video below shows the first run experience of this user – they login and are prompted to register for MFA. They register using the legacy experience and are then granted access to the application.
Office 365 MFA + Enhanced Registration
For this scenario I have a user called Brian Johnson. He has been enabled for MFA as above (Office 365 method) but additionally has been added to a group that is configured to support the new MFA+SSPR combined registration process. Brian is not enabled for SSPR. The video shows the user experience. Note that the user needs a valid licence to be able to use this experience. If they do not have any licences they will get the old experience:
Conditional Access MFA
The following video looks at the experience of two users who are enforced for MFA via Conditional Access. The login will trigger the registration for MFA as neither user is already registered. The first user (Christie) gets the old registration wizard and the second (Debra) gets the new registration wizard. The Conditional Access settings are basic – MFA in all circumstances for our two users:
Impact of SSPR on MFA Registration and User Sign-In
When users are set up to register their password reset security methods and MFA, but using the old registration wizard the user needs to do two sets of registration. Again, it is recommended that the combined registration process is used instead of this process.
For this demostration, we are enabling SSPR for our test users. One with the old registration wizard and one with the new one:
Adding SSPR To Already Registered Users
Once a user has registered for MFA (old or new registration) it might come a time where you enable SSPR for them after that (and not at the time of original registration). In this scenario the users that registered with the old registration wizard are asked to register for SSPR, but users who went through the new wizard – though they did not specifically register for SSPR – there is enough details already available for them to use the service (as long as app notifications and codes is enabled for SSPR). If SSPR is left on the default of SMS and Email, then the new registration wizard does not have your alternative email and so SSPR is unavailable to you. The user process and flow is shown in the next video:
Azure AD Identity Protection and MFA Registration
The Azure AD Premium 2 licensed feature called Identity Protection contains the ability to request that the user registers for MFA (and SSPR if via the new combined registration wizard) even if the user is not required to perform MFA for login – all our previous registrations only required registration because the user needed to do MFA. You can ask users to pre-register via https://aka.ms/mfasetup but Identity Protection adds this functionality with a 14 day option to defer. The video shows the settings and the user experience:
Azure AD Free Conditional Access for All Users
Early Q2 2019 Microsoft rolled out new baseline policies for Azure AD Conditional Access. These are available even without the Azure AD P1 licence needed for Conditional Access – but as they are licence free they are heavily restricted – they apply to all users and need MFA if sign-in is risky. So though they do not require MFA on all logins (unlike the O365 MFA legacy settings) they do require registration. But they offer a 14 day deferral process if the user is not ready to register. But unlike Azure AD Identity Protection mentioned above, you cannot do this for some users – it is enabled for all users upon enabling the rule. Lets see the settings and the user experience in the video. The video will also enable the “all admins” baseline policy as well, as that should always be turned on.
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
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!
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!
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.
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.
When this is enabled documents can be viewed in the browser only and not downloaded. So how to do this.
Step 1: Create a Conditional Access Policy in Azure AD
You need an Azure AD Premium P1 licence for this feature.
Here I created a policy that applied to one user and no other policy settings. This would mean this user is always in ReadOnly mode.
In real world scenarios you would more likely create a policy that applied to a group and not individual users and forced ReadOnly only when other conditions such as non-compliant device (i.e. home computer) where in use. The steps for this are:
The pictures, as you cannot create the policies in the cmdline, are as follows:
New policy with a name. Here it is “Limited View for ZacharyP”
Under “Users and Groups” I selected my one test user. Here you are more likely to pick the users for whom data leakage is an issue
Under “Cloud apps” select Office 365 SharePoint Online. I have also selected Exchange Online, as the same idea exists in that service as well
Under Session, and this is the important one, select “Use app enforced restrictions”.
SharePoint Online will then implement read only viewing for all users that fall into this policy you have just created.
Step 3: View the results
Ensure the user is licensed for SharePoint Online (and a mailbox if you are testing Exchange Online) and an Azure AD Premium P1 licence and ensure there is a document library with documents in it for testing!
Login as the user under the conditions you have set in the policy (in my example, the conditions where for the specific user only, but you could do network or device conditions as well.
SharePoint and OneDrive Wizard Driven Setup
For reference, in the SharePoint Admin Centre and Policies > Access Control > Unmanaged Devices, here you turn on “Allow limited web-only access” or “Block access” to do the above process of creating the conditional access rule for you, but with pre-canned conditions:
In the classic SharePoint Admin Center it is found under that Access Control menu, and in SharePoint PowerShell use Set-SPOTenant -ConditionalAccessPolicy AllowLimitedAccess
Turning the settings on in SharePoint creates the Conditional Access policies for you, so for my demo I disabled those as the one I made for had different conditions and included SharePoint as well as a service. This is as shown for SharePoint – the banner is across the top and the Download link on the ribbon is missing:
And for OneDrive, which is automatic when you turn it on for SharePoint:
When configuring Azure AD SSO as part of Pass-Through Authentication (PTA) or with Password Hash Authentication (PHA) you need now (since March 2018) to only configure a single URL in the Intranet Zone in Windows. That URL is https://autologon.microsoftazuread-sso.com and this can be rolled out as a registry preference via Group Policy. Before March 2018 there was a second URL that was needed in the intranet zone, but that is no longer required (see notes).
So this short blog post is how to fix SSO when you do see a popup for this second URL though it is no longer required. The popup looks like:
It has OK and Cancel on it as well, but my screengrab I made when I saw the issue was not brilliant, so I “fixed” the bottom of the image so its approx. correct!
The URL is aadg.windows.net.nsatc.net. Adding this to Local Intranet Zone even though it is not needed does not fix the issue. The issue is caused because on Windows 10 (version 1703 and maybe others) someone has enabled Enhanced Protected Mode. Azure SSO does not work when Enhanced Protected Mode is enabled. This is not a setting that is enabled on client machines by default.
Enhanced Protected Mode provides additional protection against malicious websites by using 64-bit processes on 64-bit versions of Windows. For computers running at least Windows 8, Enhanced Protected Mode also limits the locations Internet Explorer can read from in the registry and the file system.
It is probable that Enhanced Protected Mode is enabled via Group Policy. It will either have the value Isolation (or Isolation64bit) set to a value of PMEM at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main or HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\Main or the policy equivalent at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Internet Explorer\Main or HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Internet Explorer\Main when set via GPO settings.
Here is a good error message. Its good, because I could not find any references to it on Google and the fault was nothing to do with the error message:
The error says “something went wrong” and “Ref A: a long string of Hex Ref B: AMSEDGE0319 Ref C: Date Time”. The server name in Ref B will change as well. It also says “more details” and if you click that there are no more details, but that text changes to “fewer details”. As far as I have seen, this only appears on Outlook Web Access (OWA).
The error appears under these conditions:
You are enabled for Enterprise Mobility + Security licences in Azure AD
Conditional Access rules are enabled
The device you are on, or the location you are at etc (see the specifics of the conditional access rule) mean that you are outside the conditions allowed to access Outlook Web Access
This says “you can’t get there from here” and the reasons why you have failed conditional access.
If you were on a device or location that allowed you to connect (such as a device managed by Intune and compliant with Intune rules) then going to OWA directly will work, as will going via the menu.
So how can you avoid this odd error message for your users. For this, you need to replace outlook.office.com with your own custom URL. For OWA you can create a DNS CNAME in your domain for (lets say) webmail that points to outlook.office365.com (for this it will not work if you point the CNAME to outlook.office.com). Your users can now go to webmail.yourdomain.com. This will redirect the user via Azure AD for login and token generation, and as you are redirected via Azure AD you will always see the proper, language relevant, conditional access page.