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.
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…
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
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
Disable user app consent, and enable admin consent requests as soon as
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.
One of the
disadvantages of being an experienced consultant in IT is the fact that once in
a while you need to re-learn. With re-learn I mean that for some concepts it’s
easier to understand how it works if you come from no-experience. I’ve
experienced this with quite some Microsoft products as well. If you know the
old version, switching to concepts in a new version might not be that easy
compared to when you get to know the new version without any prior knowledge.
I also experienced
this “challenge” lately when trying to figure out when to assign
applications or configuration to either User Groups or Device Groups.
In my blog article series on Conditional Access Demystied I mentioned that Conditional Access can be used to route sessions toward Microsoft Cloud App Security (MCAS). In this article I will go into more detail on what MCAS is, and how to setup Conditional Access App Control.
Disclaimer: This article discusses the full option MCAS product, there are some other flavors providing partial functionality like Office 365 Cloud App Security and Cloud App Discovery (CAD). For information about licensing, see the Microsoft Cloud App Security licensing datasheet.
What is Microsoft Cloud App Security (MCAS)?
This article is part 7 of a series, for which the following articles are available:
Conditional Access demystified, part 1: Introduction
Conditional Access demystified, part 2: What is Conditional Access?
Conditional Access demystified, part 3: How does Conditional Access work?
Conditional Access demystified, part 4: Designing a Conditional Access strategy
Conditional Access demystified, part 5: Implementing Conditional Access
Conditional Access demystified, part 6: Troubleshooting Conditional Access
Conditional Access demystified, part 8: Resources and further references
When you want to integrate other products into your Conditional Access
environment you can use “Custom controls” to include products from
other vendors into your Conditional Access conditions. If a custom control is
used the browser is redirected to the external service, performs any required
authentication or validation activities, and is then redirected back to Azure
Active Directory. If the user was successfully authenticated or validated, the
user continues in the Conditional Access flow. More information and some
samples can be found here: Azure AD + 3rd party MFA = Azure AD Custom Controls
– https://blogs.technet.microsoft.com/cbernier/2017/10/16/azure-ad-3rd-party-mfa-azure-ad-custom-controls/. This feature is still in preview
but very promising for 3rd party vendors who want to integrate with Conditional