Microsoft provides some different options for securing Office 365 and Azure applications with multi-factor authentication (MFA). For your end users you can choose from:
- MFA for Office 365, which provides basic MFA functionality for Office 365 applications only.
- Azure MFA, which provides more advanced functionality, including the option to configure trusted IPs.
The trusted IP feature is attractive because it allows you to define IP address ranges, such as those of your corporate network, from which you will “trust” the logins and not prompt for MFA codes. This is useful for decreasing the annoyance factor of MFA for your end users, but doesn’t solve the problem for all types of organizations. For example, a staff of roaming sales people will frequently be accessing their applications from outside the corporate network, which will cause them to be repeatedly prompted for MFA codes. Yes there are some apps where you can “remember” the device and avoid repeated prompts, but not all apps provide that. App passwords, which are separate passwords for a user that bypass MFA, are also not practical in all cases as they become difficult to manage over time.
For some customers it’s not just a subset of their users, such as the sales staff, that access apps from “outside” the corporate network. It’s becoming more common for the concept of a corporate network to not exist at all for a company. And even for those that can define a network boundary that traditionally would separate “inside” from “outside”, it’s somewhat of a dated concept. Google’s “BeyondCorp” whitepaper explores this in more detail.
The goal of Google’s BeyondCorp initiative is to improve our security with regard to how employees and devices access internal applications. Unlike the conventional perimeter security model, BeyondCorp doesn’t gate access to services and tools based on a user’s physical location or the originating network; instead, access policies are based on information about a device, its state, and its associated user. BeyondCorp considers both internal networks and external networks to be completely untrusted, and gates access to applications by dynamically asserting and enforcing levels, or “tiers,” of access.
Looking at securing Office 365 access in that context, we can shift our thinking from using trusted IPs to avoid MFA prompts, and use signals about the devices and users. For this article I’m going to focus on the device aspect of the picture.
The devices that users connect from are either managed or unmanaged. A managed device is secured by way of being domain joined, or by being enrolled in Intune, which provides the organization with visibility of what is running on the machine, whether it complies with our security requirements, and so on. Put simply, you can tell whether the user is connecting from a rooted Android phone that is riddled with pirated apps containing malicious code, or whether they’re connecting from a Windows 10 laptop appropriate security settings applied.
Unmanaged devices are those such as home computers where the user might use their web browser to check email, or a mobile device that is not enrolled in Intune.
For this example scenario we’re going to achieve the following outcomes:
- Users of managed devices of any platform are not required to use MFA, on the basis that they are secured and managed by way of being either domain joined or Intune enrolled. This effectively means that corporate owned devices, and BYOD devices that have been Intune enrolled, will not require MFA when the user logs on to Office 365 applications.
- Users of unmanaged devices of any platform will be prompted for MFA when the user logs on to Office 365 applications. We can further secure access from unmanaged devices by using Intune MAM policies, which I demonstrated here so I will not cover that again in this article.
Both of those outcomes can be achieved with a single Azure Active Directory conditional access policy. Only one policy is required because there is no difference in how trusted and untrusted IP addresses are being treated. That said, you could define multiple policies if you needed to break them up for separate device platforms, different sets of users, or different Office 365 applications. For this demonstration a single policy is used.
To create the policy go to the Azure portal and navigate to Azure Active Directory, then choose Conditional Access.
Create a new policy and give it a meaningful name. Configure the assignments for the policy. I’m targeting this policy at the users in my tenant who are licensed for Azure AD Premium, which is required for conditional access. Azure AD Premium is available as a standalone license add-on, or it’s included in the Enterprise Mobility + Security (EMS) bundles. As a side note, if you’re testing any policy that might restrict access to Office 365 or Azure services you can exclude your admin account as a precaution against locking yourself out of all applications and portals by accident. Also, do keep in mind that if you do not target this policy at a user, they’ll be able to login without MFA from any device. Targeting “All users” may be the right approach for your organization.
Next, select the cloud apps that the policy will apply to. Again as a precaution, Microsoft recommends in their best practices doc that you avoid policies that apply to all user and all apps and require specific conditions that might result in completely locking yourself out of Office 365 and Azure.
For the conditions, I’ve chosen all platforms, all locations (no exception for trusted IP addresses), and all client apps.
Finally, set the access controls. This policy will grant access if any of the following conditions are met:
- The user successfully provides an MFA code (the user must be enabled for MFA, and if they haven’t set up their code yet will be prompted to do so)
- The user is logging in from a device that is marked as compliant (which means it must be enrolled in Intune first and meet the requirements of the compliance policy)
- The user is logging in from a domain joined device
Enable the policy and save it. Conditional access policies usually apply quickly but in some of my testing I’ve had to wait more than an hour to see the results.
A simple way to test the policy is to log in to the Office 365 portal, and then try to access one of the applications that the policy applies to (such as opening their Exchange Online mailbox in OWA). Note that prior to August 9th 2017 the Office 365 portal itself is not protected by conditional access policies, so the user will not be prompted for an MFA code. After August 9th the Office 365 portal will be subject to conditional access policies that you configure. If the user is on a domain joined device, or an Intune enrolled and compliant device, they’ll be able to access the application successfully. Intune enrollment requires an Intune license for the user, which is available as a standalone license add-on or as part of the EMS bundle. If they are on an unmanaged device, the MFA prompt will be displayed instead.
This provides the user with a choice. They can live with the MFA prompts when logging in from their BYOD or personal devices, or they can enrol the devices for management by Intune. It’s up to the user to decide which option strikes a balance between convenience (fewer MFA prompts) and privacy (some users don’t like their employer having “control” of their personal devices).
For this managed vs unmanaged device scenario you can also further secure the unmanaged device access by configuring Intune MAM policies to control such things as copying of corporate data to unmanaged apps (e.g. from a user’s corporate OneDrive to their personal Dropbox). You can also look at Azure AD Identity Protection to detect and block high risk logins (e.g. suspicious IP addresses), which I’ll cover in a future article.
Highly descriptive post, I liked that bit.
Will there be a part 2?
MFA doesn’t work at portal.office.com, while using Conditional access when we choose selected apps. It only prompts in the app level. It works when we choose All cloud apps. We don’t want to choose all cloud apps but need some selective apps like Exchange Online, SharePoint Online, Teams and Yammer. Also when you open a new blank document, say from excel online or Word Online it throws you an error saying Unable to open Excel. Any idea how can we fix this?
I have enable conditional access policy to enforce MFA for the intune enrollment App and grant control to allow with MFA only. Also set up up another CA policy to allow all cloud apps if the device is compliant. My users are still getting prompted for MFA on office apps after interval of a week. If the device is compliant, then users should not be prompted for MFA at all for the app approved apps. Can you help me understand this behavior. I also see “50074: User did not pass the MFA challenge” error while checking sign in logs.
Microsoft Windows Azure now officially supports DeepNet SafeID hardware tokens.
The tokens are OATH compliant, and configuration instructions can be found here;
Pingback: Blocking Basic Authentication to Exchange Online - by Steve Goodman
I’m having an issue setting up conditional access. I’ve setup so that the users are prompted for MFA when outside trusted networks. Though, what I am experiencing is that the users are not asked to setup MFA when inside the trusted network. Only when they are going outside this is prompted.
Now, this feels insecure. I got users that most of the time don’t access their Office365-account from outside the company IPs. So if someone gets their username and password, the “hacker” will be able to setup MFA for the user.
Is there any way with conditional access to force the user to setup MFA when on a trusted network? The regular MFA does this, but as you cant auto enable MFA for new user that way, I am trying to find a better way through Conditional Access.
I believe you need have Azure AD identity protection (Req. AADP P2 license) enabled to enforce MFA registration for from inside your corp network.
Jens did you ever find a solution for this? I’m dealing with the same challenge what about the users always working from the office. I’m looking for a way to force them to setup MFA once from the trusted IP’s.
Im having issues with this. This is what we did to initially deploy MFA to users. We had users register themselves by going to https://aka.ms/mfasetup. When they register the office365 portal still shows them as disabled for MFA, but they still get prompted.
When i enable conditional access, users that are on a domain joined PC still get prompted. A new user that hasnt registered yet, will not get a prompt to register on a non-domain joined PC.
This is amazing except anyone using App Password and a none modern authentification app will get quarantined on Office 365, exchange MDM portal.
Any way around to apply this without getting phones blacklisted if they use app password?
Hi Paul, I’ve been round the houses on what should be a simple setup, please help!
So what I’m trying to achieve is Azure MFA enabled for all users but don’t prompt for MFA when on the LAN/trusted network (all users have E3/EMS, so AAD P1). I’ve added the address space to the white list in the MFA portal and created a conditional access policy but I’m still prompted for MFA.
I’ve tried the conditional access policy settings in every configuration possible but it seems to have little effect. Do I have to do anything with device registration/Intune/Azure AD Join in addition to MFA white-listing and a CA policy in ARM?
Did you enable MFA at the user level in this portal? https://account.activedirectory.windowsazure.com/usermanagement/multifactorverification.aspx
If so, that will override your Conditional Access policies. It seems odd but you need to leave them “disabled” at the user level and then allow Conditional Access to take over.
Since you have P1 licensing you can use the “trusted IP’s configuration in the link listed above (Click on Service Settings) and put the IP’s in there. Conditional access lets you get more granular but if you just need a blunt on/off switch by source IP that will do it.
Here’s an article for anyone wondering about that:
Thank you both, I can confirm that disabling MFA for the users allowed me to use Conditional Access to enforce MFA for Citrix Xen Desktop Essentials in Azure when the users are not on a recognised network address space.
This article was written while this feature was in preview as far as i know through testing and have read so far preview wasnt working properly, the way the policies applied were not in the right order. Now if the user is enabled for MFA and has gone through registration they will be enforced and a user who is enforced will always have to use MFA regardless if the device is hybrid azure ad joined or device compliant in intune.
You could be on to something there. I’ve been re-testing this scenario and the behaviour has changed. I am pretty sure that this worked as recently as 2-3 weeks ago when I was recording some training that demonstrated this scenario too.
So, there’s new conditional access policy *conditions* for “Device State” that are currently in preview that allow you to exclude devices from policies. The two conditions you can exclude are “Device Hybrid Azure AD Joined” and “Device marked as compliant”.
The grant controls of the same name are still there, but in two tenants I’m seeing those grant controls no longer work in a “Require one of the selected controls” configuration (e.g. if you want MFA… OR… hybrid joined device… OR… compliant devices).
In my testing, the new preview controls work the way those grant controls used to, in the two tenants I’ve changed the policies to use the new conditions.
I have no tested whether those grant controls still work in a “Require all the selected controls” configuration.
Blog post here with more details:
Good stuff Paul.
I would also like to add that for some of those people who are having trouble with Azure MFA and getting it to work with conditional access, you don’t actually enable any users for mfa, that is just the free mfa. You use CA policies to require users to register and use mfa based on the policy, for example on an unmanaged device they will use mfa but on a hybrid azure ad joined machine they won’t. When using mfa via a ca policy the user state for mfa will still show as disabled you can check either via powershell or in the old mfa console. If a user is manually enabled for mfa then eventually they will be enforced after registration and they will always have to use mfa no matter the policy, enforced mfa overwrites any ca policy. Never enable users manually just catch them using a ca policy.
Indeed. Although what happens with some customers is they progress from basic MFA, to MFA with an IP bypass to reduce the annoyance factor, to MFA via conditional access (maybe for a subset of users), and they end up in a state with some users “Enabled” (not “Enforced”), some CA policies in place, maybe even some Azure AD Identity Protection stuff set up as well, but it all still works together in the end. More complex overall from a troubleshooting perspective. A bit of planning around actual requirements and expectations makes things a lot neater in the long run.
However, I have set up conditional MFA exactly as described here with the exception of requiring device compliance. So I have it set to grant access and require one of the following:
2. Hybrid Joined Device
The issue is, all test devices are still requiring MFA even though they are Azure AD joined. Have others encountered this?
I am seeing the same issue, thought i had it sussed but its as you describe
Azure AD joined or hybrid Azure AD joined?
If I start enabling mfa on users, what does the user need to do after being enforced. So they picked there auth method and are enabled, then I enforce. Do they need to login and out for it to prompt? Or after 24hrs it would prompt no matter what?
Next time they authenticate they’ll need to provide the MFA code. Far as I know it depends on auth tokens expiring. I’ve seen it happen almost immediately, and I’ve seen it take longer. A test/pilot case in your environment is the best way to work out what impact it will have on your users.
If the user isn’t setup for MFA (disabled in Azure) would this block the user if they were logging on from an unmanaged device?
I assume they’ll be prompted to set up MFA. But if you want to know for sure, set up a test and see what happens.
Can you enforce app passwords (for ActiveSync) via Conditional Access only?
Conditional access alone seems to only work for things using modern authentication from what I am trying.
Not sure exactly what you’re trying to achieve, but pretty sure conditional access relies on modern auth, yeah.
What I’m trying to figure out is how Azure MFA (set on a user) and Conditional Access (set by policy) play together.
Does one trump the other? Does Conditional Access “extend” the capabilities of Basic MFA?
So far I have been unable to do any Conditional Access on things like IOS email or Gmail app. It seems app passwords arent available for Conditional Access policies.
If I disable MFA (set on a user), and then create a Conditional Access policy, the policy ONLY works on authentications that use Modern Authentication. CA policies dont apply to ActiveSync (?)
If I enforce MFA (set on a user), then it doesnt seem the exceptions I set in Conditional Access are working, because MFA is trumping Conditional Access (?)
This is what I was getting at in my previous comments. If you use an app that doesn’t support Modern Auth it ignores the conditional access policies. In my case, those non-Modern Auth apps can authenticate without an MFA prompt despite the conditional access policy requiring it.
In the case of apps that don’t support Modern Authentication, you can block them here:
Microsoft Intune | Conditional access – Exchange ActiveSync | Advanced Exchange ActiveSync access settings
I’ve tested setting up a policy similar to what you have here. I’ve found that you can simply bypass the requirement of MFA by using a different mail client other than Outlook. It will allow the user to log in without prompting for MFA. Any idea on how to enforce this so other applications can’t bypass MFA?
Other applications can’t bypass MFA on their own.
They can bypass if you use an app password, if they are connecting from a trusted IP that is allowed to bypass, or during the period between activating MFA and propagation of the change + expiration of cached creds/tokens (mentioned here: https://blogs.technet.microsoft.com/exchange/2016/11/04/multi-factor-authentication-in-exchange-and-office-365/)
My testing is showing otherwise.
I have a test user which has been enrolled for MFA for about a week. Logging on via Outlook presents and MFA prompt but if you log on or setup a new account in something like the default Mail client on a Mac then it will log in without an MFA prompt. There are no App Passwords setup and I was under the impression app passwords cannot be used in conjunction with Conditional Access.
You have Conditional Access rules in place?
Yeah, almost identical to what’s in your article. It seems that if the application is not able to show an MFA prompt (Modern Auth not supported?) then it simply allows you to login without MFA rather than blocking access.
If you think you’ve got a bug that you can repro, by all means go ahead and blog your findings. I can’t repro what you’re saying is happening though, based on what you’ve shared about the scenario.
I have MFA enabled with Trusted IPs.i have one external network policy which excluded the Trusted IPs from MFA.If my requirement is to make the MFA enabled for trusted IPS at least once,how do I achieve ,Is it by creating another ON-network policy including the Trusted IPs.
Thanks in advance.
“my requirement is to make the MFA enabled for trusted IPS at least once”
I don’t understand your requirement. What are you trying to achieve?
Currently my MFA is only for external IPs and network. The existing policy has exclusion for trusted ips and corporate network. If suppose I would like to include MFA for the corporate users at least once that is when they login from corporate it should ask them to set up mfa so that the status becomes enforced and skip mfa in subsequent logins, how do I achieve this. Can I implement multiple policies with different exclusions?
With conditional access policy my understanding is native mail mobile appshould stop working? It isn’t in my case. Any ideas?
Did you ever find an answer to this? I’ve tested and found the same thing. Only Outlook prompts for MFA, other native Android or even PC/MAC mail apps don’t prompt for MFA and continue working.
Hello,i have a question for the team.Can a device be compliant by a third party solution like airwatch?
The Azure docs indicate yes, but you will need to ask Airwatch to confirm whether it will work with them and how exactly to achieve it.
does this applies to Ios and Android also or only to windows 10?
Conditional access rule can apply to Windows, iOS, Android, and they recently added macOS support as well. I don’t know which platforms are supported for Airwatch integration (if it’s possible at all).
I have been beating my head around this for quiet some time now..As far as my research goes, when you configure a conditional access policy to check if the device is compliant or domain joined, this information would have to come from Intunes. Unfortunately i havent found a way to have Airwatch provide this information to Azure AD.
As far as the Azure documentation goes, for windows 10 devices you could have the devices registered with Azure AD(this is a different ball game altogether) and then you could check if the device is compliant or not.
Nice article! I’ve followed the steps, but my test user still gets the MFA prompts. His device is marked as comliant within Intune and he has a EMS E5 license enabled. He configured MFA successfully. Does anyone knows a possible solution or a tip where to search for the cause?
Is the Access Control Grant permission set to Grant Access with “Require multi-factor authentication” and does the policy bypass Trusted IP locations? From my experience if you want to bypass MFA, the Access Control should be set to “Require device to be marked as compliant”
Hi Sam, the Access Control – Grant permission settings are:
Grant access, require multi-factor authentication and require device to be marked as compliant is turned on. It require all the selected controls.
The policy also bypass Trusted IP locations, it refers to “Skip multi-factor authentication for requests from federated users on my intranet”.
Strange that the test user is still getting MFA prompts while the device is compliant in Intune (user is outsite the office when testing).
We would like to have a solution that if a device is not Intune compliant the user gets a MFA prompt.
If you’re requiring *all* the controls then they’ll still be prompted for MFA. In my example in the post above I only require *one* of the controls, and that’s why users on compliant devices no longer get prompted for MFA.
Hi Paul, Yes the Conditional Access policy is working now for my test user. I’ve changed the setting to use *one* of the controls. And i have disabled MFA (account.activedirectory.windowsazure.com/UserManagement/MultifactorVerification.aspx) I think this MFA setting overruled the MFA setting in the CA policy? The only difference is that my test user can not create app-passwords via aka.ms/createapppassword. Do you have the same issue?
Bit of a struggle with this. I have setup conditional access as above and have enabled MFA for users but it continues to prompt for MFA to verify their accounts on our domain joined devices (when they are outside of our trusted network). Even have MFA setup with the NPS extension to 2f our VPN connections. So close to having this production ready.
They must be Azure AD Domain joined Rob, not internally Domain joined
The Microsoft documentation until very recently (August 2017) stated this applied to on-premises AD Joined. However, in the last couple of months the control changed to “Required domain joined (Hybrid Azure AD)” from just “Required domain joined”. As my comment below, we have on-premises AD join with Azure Hybrid joined.
We have the same issue – they are marked “Hybrid Azure AD Joined” – The control states “Required domain joined (Hybrid Azure AD)” so technically they comply to this control. Yet we are still getting MFA prompts.
Hi Dean, I am experiencing the exact same issue. Did you get any joy with fixing this?
Great and useful article!
One thing that i noticed with applying the Intune MAM Policy on ActiveSync devices, is that it can take up to 6 hours for a mobile device to sync a policy: https://docs.microsoft.com/en-us/intune-classic/troubleshoot/troubleshoot-conditional-access
So in a case of blocking native client support, users may be still accessing their data until the policy applied.
And up to 24 hours for a device that is unenrolled to start prompting for MFA again, according to my experience.
So can you configure it to only use MAM policies when a device isn’t enrolled?
MAM policies will apply to unenrolled devices if they are targeted to that user. Is that what you mean?
Excellent article Paul demonstrating a simple and straight forward approach while providing users a choice!