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
At our last Windows
Management User Group Netherlands meeting, we had the honor to have Sami Laiho, one of the world’s leading
professionals in the Windows OS and Security flying over to the Netherlands and
present for our user group. In his presentation titled: “Securing Windows
in 2020 and forward”, Sami made us aware that by implementing some simple
Applocker policies on our Modern Workplace and by making sure that the user
working on the device has no
admin rights, we can seriously improve our security. In his presentation
Sami referred to a quote from Mikko Hyppönen (Chief Research Officer at
F-Secure): “Make your security better than your
blogpost I will share my experience with implementing Applocker policy within
my own tenant, and how I started to use these principles myself which
eventually led by removing my account from the local administrator group.
Disclaimer: This blogpost provides a very
simplistic way of enabling Applocker policies, in the real world there are some
caveats which must be addressed when implementing Applocker. I will
address those caveats later in this post
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.