Azure AD Identity Protection basics

Azure AD Identity protection is available with Azure AD P2 and provides risk detection and policy enforcement for sign ins and users. It can also be incorporated with Conditional Access policies to provide even more flexibility. This video shows you the basics of Azure AD Identity Protection as well as showing you an example of a login process that generates creates risk.

You can find the video here –

and more information here – What is Identity Protection?

Azure AD access reviews basics

Azure AD reviews are a capability provided with Azure AD P2 licenses that allow you to automate the discovery and access control of user account in Azure AD groups and roles. This video give you a walk through of the basics of creating and using access reviews to ensure your environment remains secure.

You can find the video here –

You can learn about Azure AD access review here:

What are Azure AD access reviews?

Escalating to multiple roles using Privileged Identity Management

Privileged Identity Management or PIM, is great way to ensure that users are not given standing administrative access. Instead, with PIM, these rights can be requested, approved and removed in an automated and audited way.

In the scenario where a user may need administrative rights to multiple services at the same time, say Exchange Online administration and SharePoint Online administration together, you can achieve this by using the capability in Azure AD to assign multiple roles to an Azure AD group. You then have users go through the PIM process to become members of that group. When they do, they automatically get access to the roles that are part of that group. Once PIM deactivated them, they are removed from that group and lose those permissions.

This video take you through that process.

remember, to achieve this you’ll need to have an Azure AD P2 assigned and that currently this feature is in preview.

For more information consult the following documentation from Microsoft:

Management capabilities for Privileged Access groups

Privileged Identity Management basics

In this video I provide a walk through of the basics of Azure Privileged Identity Management or PIM for short. PIM allows users to escalate their rights and roles on demand as well as having that escalation controlled and audited. PIM requires a subscription to Azure AD P2.

PIM is an excellent way to minimise standing administrator privileges and ensure they are only given greater permissions when they require and request them.

You can find the video here:

See the following link for more details on PIM from Microsoft:

What is Azure AD Privileged Identity Management?

Automated user tenant access control


If you ever used an on premises Active Directory (AD) you may be aware of the setting, shown above, that allows you to set users login times. This was typically done to prevent users logging in after hours, say from 9pm to 6am.

Unfortunately, with Azure AD there is no direct equivalent setting but we can create something similar quickly and easily using Power Automate.


The first step in this process is to create a new Azure AD security group that will contain the users who will be prevented from accessing the tenant. You can also create this security group in the Microsoft 365 portal but it is better to do it in Azure as you’ll need to get the ObjectID for this group as highlighted above. There is also no need to actually put any users into this group as they’ll be added dynamically by Power Automate.


To prevent access to the tenant you’ll need to create a Conditional Access policy as shown above. This will require you to have a license for Azure AD Premium P1 or P2 for each user. Microsoft 365 Business Premium already includes Azure AD P1, so if that is already in the environment you need nothing additional.

Give this new Conditional Access policy a name and set it to include just the Azure AD security group created previously. It is also best practice to exclude at least one administration account to prevent you from being ‘locked out’ of your tenant. Ensure that All cloud apps is selected and that Block access is configured, as shown above. Finally, turn this Conditional Access policy On.

With no members in this Azure AD Security group, no one will be restricted from accessing the tenant.


Next, create a List in SharePoint that contains a list of users you want to be blocked. You can achieve this by adding the Person field to the list in question. This will basically allow you to enter users who are in your tenant by doing a lookup from Azure AD.


Create a new Flow and use the Recurrence action to trigger it as shown above. Select an appropriate time once a day when users will be prevented from accessing the tenant, say 9pm.


Add the Get items action as shown above next. Configure this action to retrieve from the list of users from the SharePoint list just created.


Then use the Apply to each action to loop through all the users returned by this Get items as shown above.


Inside the Apply to each action use the Get user profile (V2) action as shown, with the users email address, which is effectively their Azure AD identity.


Also inside the Apply to each action add the Add user to group action as shown above. Populate this action with the ObjectID of the Azure AD security group obtained at the start and the Id from the Get user profile (V2) action.


Now test the Flow manually to ensure it works correctly.


Once the Flow completes, the users in the list in SharePoint should now appear in the Azure AD security group as shown above.


Now when a user on that list attempts to login, because they are part of a security group that is part of a blocking Conditional access policy, they will no longer have access to the tenant.


To allow access again for users simply create another scheduled Flow executing at say 6am that uses the Get group members action and then a Remove Member from group action inside an Apply to each action as shown above. In essence, this removes all users from the Azure AD security group that is part of the blocking Conditional Access policy, resulting in those users no longer being blocked from accessing the tenant.


Run this Flow manually and ensure it completes,


and you should find that Azure AD security group to be empty, as shown above.


The users in the list who were previously blocked,  should now be able to access the tenant as normal. Left to its own devices, users in the SharePoint list will have their access blocked from 9pm to 6am each day now.

This automation is very quick and easy to set up. It can solve the challenge of ‘forcing’ users to take a break from work after hours, rather than being ‘on’, aiding their mental health and making them more productive when they do work. It could be used to improve security but allowing account to only operate during ‘business hours’ and limiting attacks after hours, which is when many attacks happen.

This process could be extended and enhanced to provide more granular options to suit any need as well as alerting. However, hopefully, it demonstrates how easy it is to solve business challenges thanks to the Power Platform and the integration of Microsoft 365. Remember, the only extra you need is Azure AD Premium P1 to enforce Conditional Access, something already part of Microsoft 365 Business Premium.

Create a dynamic group in Azure AD

The purpose of a dynamic group in Azure AD is to be one based on a query. This means the membership of this group is then constructed on the successful matching of that query. The use case I’m going to build here is a dynamic Azure AD group that will contain devices that I wish to retire from an Azure AD.

To use dynamic groups in your environment you are going to need to be licensed for Azure AD P1 or P2. Thankfully, if you are using Microsoft 365 Business Premium, you’ll have Azure AD P1.

The way that the machines to be retired will be identified is by their unique Device ID as it appears in Azure AD. Thus, first stop will be the Azure AD portal to record these unique Device Ids.


Navigate to the Azure AD portal as an administrator ( and select the Devices item on the left hand side as shown above to see all the devices your Azure AD knows about.


In the page that appears, select All devices on the left and then search for the device(s) you wish using the search box on the right as shown above. Here, I’m searching for the device called VPC02. Select the device name to get more information about that device.


On the details page for the device you should now find the unique Device ID, as shown above. You should take a copy of this as it will be needed later.

Repeat the above process to obtain the unique Device ID of all the devices in Azure AD you wish to retire.


Return to Azure AD portal home page and now select Groups from the menu on the left.


Select the option on the top right for a New group.


Set the group type to Security. Give the group a meaningful name (here To be retired) as well as a description. Finally, ensure that the Membership type is set to Dynamic Device, because in this case we want to query a list a devices in Azure AD.


At the bottom of the options, select the Add dynamic query hyperlink as shown above.


On this page you will build the dynamic query for the membership of the group. Here we want to query the deviceid property to see whether it equals the Device Id we obtained initially for the device(s) we wish to retire.

Each unique device will generally require its own unique query line with the And/Or set to Or for this use case.


Once you add the entries at the top of the page you’ll see the actual rule syntax displayed in the box below, as shown.


To test the query returns the expected results, select the Validate Rules (Preview) option at the top of the page as shown. Next, Add devices you wish to test the query with. In the case above, I selected a machine I knew should match (VPC02) and one that wouldn’t (WIN10ENT). These selections will be validated and results displayed.

Here, the validation returns the expected results for this use case, so I can select the Save button at the top of the page to continue.


In the list of Azure AD groups, you should now be able to see the one that you just created.


If you now select this new group you will probably find that it doesn’t have any members as yet as seen above.


Fear not. Because the group is dynamic, it will take a few moments to run the query you created and populate it with matching members. When it has done this after a short time, you will be able to find the results in the Members option on the left hand side as shown above. Check that they match the expected results.


At that point, the Overview page should also display the correct count of members as shown above.

You can of course edit this Azure AD Dynamic Group at any point and change the membership criteria. In the case of retired devices, we’ll need to go in again and add any new Device Id’s for devices we want retired from our environment down the track.

A dynamic group can be based on just about any criteria and you may use it to identify new devices, users in the marketing department and so on. The queries can also be quite complex and it is recommended you consult this documentation from Microsoft for more information:

Dynamic membership rules for groups in Azure AD

In this case, we can now use this dynamic group of old devices to off board them cleanly from our Microsoft 365 environment. Stay tuned for upcoming articles on how to do this.

Need to Know podcast–Episode 275

Join for an episode with MVP Rory Braybrook where we learn more about modern identities, especially Azure including B2B and B2C. Identity is so critical to everything we do in IT these days it is important to have a refresher to understand what’s what and how it can be used effectively. I’ll also bring you the latest news and updates from the Microsoft cloud world so listen in and share your feedback.

This episode was recorded using Microsoft Teams and produced with Camtasia 2020.

Brought to you by

Take a listen and let us know what you think –

You can listen directly to this episode at:

Subscribe via iTunes at:

The podcast is also available on Stitcher at:

Don’t forget to give the show a rating as well as send us any feedback or suggestions you may have for the show.


Rory Braybrook – LinkedIn, Authory

Windows 11: A new era for the PC begins today

Welcome to the new Whiteboard

Mailbox storage limits

Microsoft Ignite

How cyberattacks are changing according to new Microsoft Digital Defense Report

Microsoft Digital Defense Report

Defending Windows Server 2012 R2 and 2016

End to End email protection with Microsoft 365–Part 4

This is part of a series of articles about email security in Microsoft 365. Please check out previous articles here:

End to End email protection with Microsoft 365 – Part 1

End to End email protection with Microsoft 365 – Part 2

End to End email protection with Microsoft 365 – Part 3

These articles are based on a model I have previously created, which you can read about here:

CIAOPS Cyber protection model

designed to help better explain expansive security included with Microsoft 365.

In previous parts, we covered how an external email was delivered into the Microsoft 365 service and all the protections that it passed through until it finally came to rest in the Data container (user’s inbox) ready to be viewed. The next step in the process will therefore for the user to fire up their device to read the email. This article will therefore focus on the protections available for that device.

For the sake of simplicity we’ll focus on that being a modern device running at least a Windows 10 Professional. Of course, email from Microsoft 365 can be viewed on just about any devices these days, Windows or not, and all of these have unique and overlapping protections. However for the sake of brevity let’s just focus on the more common Windows 10 device for now.

A range of hardware device protection is available and recommended including:

and should already be in place to protect the device.

We will also assume that the Windows device is fully up to date

How to keep your Windows computer up to date

The device in question should also already live inside the Device container as shown in the above model. This is largely achieved thanks to being joined to Azure Active Directory (AD):

Azure AD joined devices

Join your work device to your organization’s network

Tutorial: Join a new Windows 10 device with Azure AD during a first run

When that device is turned on we want it to complete the:

Secure Windows boot process

Once the machine has booted and before the user has logged into the machine, thanks to being Azure AD joined, Microsoft Endpoint device policies have already been pushed and implemented on that machine per:

Manage device security with endpoint security policies in Microsoft Intune

Such policies could be enforcing disk encryption, implementing Attack Surface Reduction (ASR) and so on.

Importantly, you can also enforce device compliance policies to ensure devices meet a security standard before they are allowed to access any data:

Use compliance policies to set rules for devices you manage

All of this is achieved via:

Microsoft Endpoint Manager

which I have also written a whole series of articles to help provide a better understanding of the role that it plays with device security. You can read these articles here:

Modern Device Management with Microsoft 365 Business Premium–Part 1 of 10

Assuming that the device has booted and successfully completed all the protection processes associated with that have been correctly applied, it is now time for the user to login to that devices. This means that we now follow the User connector in our model shown above, into the Service container from outside, then onto the Device Container and so on.

The user’s identity is protected inside the Microsoft 365 service via a variety of mechanisms. When logging into a Windows 10 device they will typically need to provide their account and password details that were set up with the service. However, best practice would now be to use Windows Hello for Business.

Windows Hello for Business Overview

Windows Hello addresses the following problems with passwords:

  • Strong passwords can be difficult to remember, and users often reuse passwords on multiple sites.

  • Server breaches can expose symmetric network credentials (passwords).

  • Passwords are subject to replay attacks.

  • Users can inadvertently expose their passwords due to phishing attacks.

Many mistakenly believe that the Windows Hello PIN is all that protects a users access to device and the service when at login. That is in fact not the case as Windows Hello leverages the TPM hardware to provide a highly secure login to the service.

Why a PIN is better than a password

How Windows Hello for Business works

These days just a login and password are not enough to secure any identity, you MUST implement Multi Factor Authentication (MFA). Why? As Microsoft will tell you:

Your password doesn’t matter, but MFA does! Based on our studies, your account is more than 99.9% less likely to be compromised if you use MFA.

Your Pa$$word doesn’t matter

All your creds are belong to us!

So MFA, along with a number of other recommended steps, are what can be done with Microsoft 365 to protect user identity.

Five steps to securing your identity infrastructure

Windows Hello for Business requires all users perform multi-factor authentication prior to creating and registering a Windows Hello for Business credential. Importantly, Windows Hello for Business replaces passwords with strong two-factor authentication on PCs and mobile devices. This authentication consists of a new type of user credential that is tied to a device and uses a biometric or PIN. Many don’t appreciate that correctly configured Windows Hello for Business DOES provides MFA when users access their devices, while making the device login process seamless. If you are however still concerned about this ‘single credential’ being compromised then you can also implement:

Multifactor Unlock

It is also important to remember that MFA is provided FREE on all Microsoft 365 accounts and support a variety of methods including authenticator apps, hardware token and more.

Enable multi-factor authentication for free

Once the user has correctly provides a login and password, then completed their MFA challenged (or equivalent thanks to Windows Hello for Business) they would then be subject to Azure AD Conditional Access.

It is important to remember that Azure AD Conditional Access is evaluated AFTER a successful login from a user, not before! This means that it can’t be used to block things like Password Spray Attacks.

Conditional Access policies at their simplest are if-then statements, if a user wants to access a resource, then they must complete an action.

Conceptual Conditional signal plus decision to get enforcement

What is Conditional Access?

For example, user account access can be blocked if it comes from outside a specific country or region.

Conditional Access: Block access by location

and enforcing MFA

Conditional Access: Require MFA for all users

Conditional Access: Require MFA for administrators

Once any Conditional Access policies have been met the user will be able to login to their device. At this point additional Microsoft Endpoint Manager policies will be applied to that specific account now logged in. Such policies could restrict applications the user has access to, limit Windows functionality and so on.

Remember, all of these protections have taken only during the user has logging onto their device. They have not as yet run an application like Outlook to read the inbound emails. That is what is going to happen next and I’ll cover that process in the next part of the series, so stay tuned.

End to End email protection with Microsoft 365–Part 5