Skip to main content

Lessons learned while implementing Azure AD Privileged Identity Management (PIM)

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.

Read More

License requirements for administering Microsoft 365 services

Microsoft 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.

If you 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 asked Microsoft in December last year to clarify this, but until now no response was given.

There is 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.

One thing 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”

So let’s see what I found available online and see if it makes sense in some way…

Read More

Stopping automatic email forwarding in your Exchange Online environment in a controlled way

Working 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.

Automatic 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.

Read More

Challenges while managing administrative privileges on your Azure AD joined Windows 10 devices

By 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 coming from?

It is 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.

Read More

Did you already modify your Azure AD consent defaults settings? Here is why you should

As you 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

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.

Read More

Blocking access to Cloud apps by integrating Microsoft Cloud App Security with Microsoft Defender Advanced Threat Protection

Microsoft 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).

Based on 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.

Windows 10 Notification

In this 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 license.

Read More

Did you already enable DKIM and DMARC for your Office 365 domains?

When you host your email on the Exchange Online (EXO) platform part of Office365 you can implement several security measures to make sure that email send from your domain gets delivered to the mailbox of the recipient.

The most known solution for this is by implementing a Sender Policy Framework (SPF) DNS record. By creating a SPF DNS record in your DNS you provide receiving email servers the option to check if the originating IP of the email is also the authorized email server for the domain. If not the email can be considered suspicious and the email system from that point forward can decide to threat the email as spam, phishing and so forth. 

If you decide to make the nameservers of Microsoft authoritative, which allows you to manage your DNS settings from the Office administration portal, the SPF record needed can automatically be enabled for you.

Read More

Conditional Access demystified, part 8: Resources and further references

This article is the last part 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 7: Modifying Conditional Access to suit your special needs

In the last part of this series I will summarize some of the sources I used for writing this series of articles.

Read More

Conditional Access demystified, part 7: Modifying Conditional Access to suit your special needs

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 Access.

Read More

Conditional Access demystified, part 6: Troubleshooting Conditional Access

This article is part 6 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 7: Modifying Conditional Access to suit your special needs
Conditional Access demystified, part 8: Resources and further references

In this part of the series we will go into more detail on where we can find information which can help us to troubleshoot Conditional Access policies.

Read More