One of the scenario’s we can build with Conditional Access, is the scenario where we restrict access inside the web application itself. By doing so, you could for example limit the functionality of the web applications on non-managed devices, or when accessing the web application from a country where your company normally doesn’t operate. The web applications can be configured to behave differently if the user is applicable for a Conditional Access policy where App Enforced restrictions are configured.
Within the Office 365 suite of applications, the following web applications are supported for App Enforced Restrictions:
- Outlook Web Access
- SharePoint and OneDrive
In this post I will go into detail on how to setup these app enforced restriction and what the expected behavior will be from an end-user perspective.
In August last year, I published eight articles in a series on Conditional Access, and later when finished I decided to bundle those articles in a paper which I made available on the TechNet Gallery. In March this year, Microsoft decided to retire the TechNet Gallery, so I had to find another solution to host this paper and some of the additional workflows and spreadsheets I posted as well. For now I’ve decided to host these on GitHub since that is an easy accessible location as well.
The articles I wrote at that time, will remains as is, and I’ve decided to update the paper once in a while to reflect the current status of Conditional Access. Even though some of the information in the articles is outdated, I still think that they can be of value.
Below I’ve summarized the articles I published last year:
In February this year, I wrote an article about Admin consent in Azure Active Directory. The article titled: “Did you already modify your Azure AD consent defaults settings? Here is why you should“, explained why giving end-users within your Azure AD the ability to give consent for every Application might not be such a good idea.
While disabling this option for the end-users is recommended by Microsoft, and having a workflow in place to review any requests and approve if found valid is a more secure solution it introduced an administrative burden since each request must be reviewed by one of the defined users in the list of users to review admin consent requests.
In order to address this, Microsoft made some changes to the way the Admin consent workflow is working which allows an Azure AD administrator more control over which requests must be approved and which are allowed automatically.
Note: This post reflects the status of Admin consent as of May 22, 2020. Functionality may change, even right after this post has been published.
One of the advantages of Microsoft having many customers using its services is that Microsoft can leverage data from those customers and apply some real fancy Machine Learning on that data, coming from Azure AD, Microsoft Accounts and even Xbox services.
Based on all that data the Machine Learning capabilities are able to identify identity risks. Based on the risk, automatic investigation, remediation and sharing of that data with other solutions able to leverage it is possible. The outcome of risk is expressed as either High, Medium, Low or No Risk. This outcome can later be used to define policies.
By leveraging Azure AD Identity Protection you are able to use the signals provided by Microsoft and trigger “actions” – the signals can also be leveraged in your conditional access policies.
This article covers the following topics:
Disclaimer: This post reflects the status of Azure AD Identity Protection as of April 7th 2020. Functionality may change, even right after this post has been published.
In this blogpost I will share my experiences with implementing Azure AD Privileged Identity Management (PIM). PIM is a service that enables you to manage, control, and monitor access to important resources in your Azure environment. These resources include resources in Azure AD, Azure, and other Microsoft Online Services like Exchange Online, SharePoint Online or Microsoft Intune.
PIM provides the following functionality:
- Just-in-time privileged access to Azure AD and Azure resources
- Assign time-bound access to resources using start and end dates
- Require approval to activate privileged roles
- Enforce multi-factor authentication to activate any role
- Use justification to understand why users activate
- Get notifications when privileged roles are activated
- Conduct access reviews to ensure users still need roles
- Download audit history for internal or external audit
This article will cover the following topics:
Note: This post
reflects the status of Azure AD Privileged Identity Management as of March 24th
2020. Functionality may change, even right after this post has been published.
licensing is tough and vague but something we must deal with while implementing
our solutions. I’m also aware that some of the features I describe on my blog
are only available in the most expensive licensing options Microsoft provides,
making some of the features I describe not usable for some of my readers.
Update June 23rd 2020: Microsoft has removed the Intune license requirement for administrators, see this blogpost by Peter van der Woude for more information: Quick tip: Allow access to unlicensed admins
administer Microsoft 365 services like Azure Active Directory (AzureAD),
Exchange Online (EXO), SharePoint Online (SPO), Intune and many other products
the license requirements for your administrative accounts are extra vague. I’ve
Microsoft in December last year to clarify this, but until now no response
some fragmented information available in the Microsoft documentation, that in
combination with some other information to be found on the internet, like on
twitter concludes that the license requirements are indeed very vague and could
really use some official documentation from Microsoft to clear things up.
in known, is that when asked about licensing requirements for the online
services provided by Microsoft the statement returned is: “When the user benefits from
the service, a license is required”
see what I found available online and see if it makes sense in some way…
Update: On April 3rd 2020, the Exchange Team announced that due to the COVID019 crisis, they will postpone disabling legacy authentication until the second half of 2021.
Update: On April 30 2020, the Exchange Team announced that OAuth 2.0 authentication for IMAP and SMTP AUTH protocols is now available. In order to leverage this functionality mail clients need to start using it (so they need an update). Michel de Rooij did a nice article on how to configure Thunderbird for oAuth2 which you can read here: Configuring Exchange Online with IMAP & OAuth2
Update: On May 28 2020, the Exchange Team announced that OAuth support for POP is now also available for Exchange Online.
Update: On June 30th 2020, the Microsoft Exchange Team announced support for Modern Authentication in scripts using the new Exchange PowerShell module, see: Modern Auth and Unattended Scripts in Exchange Online PowerShell V2
Update: On July 28th, the Microsoft Exchange Team announced some new changes to Modern Authentication controls in the Microsoft 365 Admin center, see: Basic Authentication and Exchange Online – July Update
Make sure that you also
7, 2018 the Microsoft Exchange Team announced
that on October 13, 2020 it would stop the support for Basic Authentication
(also called Legacy authentication) for Exchange Web Services (EWS) in Exchange
Online (EXO), the version of Exchange offered as a service part of Office 365.
EWS is a web service which can be used by client applications to access the EXO
environment. The team also announced that EWS would not receive any feature
updates anymore, and suggests customers to transition towards using Microsoft
Graph to access EXO.
One and a
half year later, on November 20, 2019 the Exchange Team also announced
to stop supporting Basic Authentication for Exchange ActiveSync (EAS), Post
Office Protocol (POP), Internet Message Access Protocol (IMAP) and Remote
PowerShell on October 13 2020 as well. Authenticated Simple Mail Transfer
Protocol (SMTP) will stay supported when used with Basic Authentication.
of supporting Basic/Legacy authentication Microsoft will move towards only
supporting Modern Authentication for most of the methods used to connect to
default, on Windows 10 devices which are Azure AD joined, the user performing
the join is added to the Local Administrator group. Besides the user and the
local administrator (which is disabled by default), two other SIDs are added
without any friendly name which explain who they are. So where are those SIDs
possible to make the user a normal user while enrolling the device, but then
you have to create a Deployment Profile and use Windows Autopilot. See: Configure
Autopilot profiles or use Bulk enrollment. See: Bulk
enrollment for Windows devices
Note: This post reflects the status of Azure AD
local administrative privileges as of February 11th 2020. Functionality may
change, even right after this post has been published.
may know, it’s possible for your users to sign-in to SaaS based applications
using their Azure AD account. By doing this, a Single Sign On (SSO) experience
is created for the user. Before this SSO for an SaaS based application is
possible though, the user needs to accept (a) permission request(s) from the
application allowing the application to access the users data on its users
behalf, even when the user is not using the application.
Added February 11th: Erik Loef pointed me to the following two interesting articles detailing on how oAuth can be used to exploit Office 365 environments. See:
Shining a Light on OAuth Abuse with PwnAuth
Introducing the Office 365 Attack Toolkit
Added May 20, 2020: Microsoft made some new functionality available, please also read my article: “Some welcome additions to the Admin consent workflow in Azure AD” afterwards for the changes Microsoft made.
TL;DR; – Disable user app consent, and enable admin consent requests as soon as possible!
Note: This post reflects the status of Admin
consent as of February 9th 2020. Functionality may change, even right after
this post has been published.
announced that the Azure AD conditional access baseline policies will not make
it out of their current preview status. The functionality of the baseline
policies will be made in available in a new feature called “Security
Defaults”, Microsoft will remove the
baseline policies on February 29th, so if you are using them you need to
take action in order to make sure to keep their functionality in place. Here is
what you need to know.
discussed the baseline policies in part
5 of my blogpost series “Conditional
Access Demystified“, while they provided a welcome addition, one of
the main disadvantages of the baseline policies in its current preview form was
that there was no option to exclude accounts from the policy, which was in
contradiction with the best practice for break glass accounts and therefore
made the policies not usable in some scenario’s.