I have been following this feature request for a while now, and up until recently Microsoft stated that implementing Azure AD role assignment for Azure AD groups wasn’t the issue, the issue was more related to who is able to manage those groups. For example, if enabled how can we circumvent that someone with the “User Administrator” role (capable of adding users to groups) is capable of adding someone to the group used to assign Global Administrator rights. When implemented incorrectly, this new “feature” could then introduce a new security risk in your environment.
Assigning groups to Azure AD roles requires an Azure AD Premium P1 license at minimum, for the Privileged Identity Functionality an Azure AD Premium P2 license is needed.
Disclaimer: This post reflects the status of assigning groups to Azure AD roles as of August 20, 2020. Functionality may change, even right after this post has been published.
So, let’s walk through on what was announced and see..
After returning from my holiday this year, I noticed a welcome addition to the Threat Management Policy page in the Office 365 Security & Compliance center called “Templated Policies”, for now the section Templated policies contains one section called “Preset security policies”
Around 5 years ago (April 2015) Microsoft announced Exchange Online Advanced Threat Protection (ATP), which was renamed to Office 365 Advanced Threat Protection around a year later.
By using Office 365 Advanced Threat Protection you can add additional protection to the email filtering service available in Office 365 called Exchange Online Protection (EOP).
In this article, I will explain the functionality of Office 365 Advanced Threat Protection, and I will share the lessons learned while implementing the solution at several of my customers. I’ll also try to include as much references to other articles or blogposts as possible hopefully providing you with enough information for you to start implementing Office 365 ATP as well.
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.
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
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…
as a modern workplace consultant also means that sometimes you have to go deep
into Exchange Online options in order to make sure that (sensitive) data of
your customer doesn’t leave the organization without the proper security
measurements taken. In the Microsoft documentation titled: “Best
practices for configuring EOP and Office 365 ATP“, the recommended
settings for both Standard and Strict states that Auto-forwarding to external
domains should be disallowed or monitored at least.
email forwarding is one of the possible and still most common way (sensitive)
company data might leave the organization. Giving the users the ability to
automatically forward emails using either mailbox forwarding or message rules
to users outside the organization in that case can be very risky. I’ve seen
many cases where corporate email accounts were configured to automatically
forward all email to personal gmail.com or hotmail.com accounts. Also still
enabled mailboxes which forward mail to users personal accounts while the user
doesn’t work at the company anymore is common practice.
It’s also commonly known that if a user somehow gets compromised, hackers usually put a forward on the mailbox of the user in order to gain knowledge about the user in order further continue with their attack methods, or to retrieve sensitive company data for their own gains.
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
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:
has quietly introduced the option to automatically block connections to
unsanctioned cloud apps from the Microsoft Cloud App Security (MCAS) console.
This is accomplished by integrating MCAS with Microsoft Defender Advanced
Threat Protection (MDATP).
the information available in Cloud App Security, the app’s domains are used to
create domain indicators in the Microsoft Defender ATP portal. Within
Windows Defender the Exploit Guard Network Policy option is used to block the
access to the URLs. This will eventually result in the following notification
sent to the user.
blog post I will explain how to setup this functionality when Microsoft Intune
is used and what the behavior is within Windows 10. This assumes that you are
licensed for both MCAS and MDATP, in my case by using a Microsoft365 E5
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.