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.

Need to Know podcast–Episode 283

I’m once again joined by Jeff Alexander from Microsoft to talk about the latest security developments in the Microsoft Defender platform. I’ll also share the latest news and updates from the Microsoft Cloud.

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 me any feedback or suggestions you may have for the show.

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

Brought to you by


Jeff Alexander

Microsoft 365 Defender

Become a Microsoft 365 Defender Ninja

Microsoft 365 Defender short and sweet videos

Microsoft Digital Defense Report 2021

Current MFA Fatigue Attack Campaign Targeting Microsoft Office 365 Users

Streamlining the submissions experience in Microsoft Defender for Office 365

Cyber Signals: Defending against cyber threats with the latest research, insights, and trends

Helping users stay safe: Blocking internet macros by default in Office

New settings available to configure local user group membership in endpoint security

Announcing general availability of vulnerability management support for Android and iOS

Windows 365 Enterprise: February 2022 updates

Sending From Email Aliases – Public Preview

Defender for Endpoint remediation levels

If you read the Microsoft documentation:

Automation levels in automated investigation and remediation capabilities

you find that there are 5 different levels of remediation automation you can set:

– No automated response

– Semi – require approval for all folders

– Semi – require approval for non-temp folders

– Semi – require approval for core folders

– Full – remediate threats automatically

which are all detailed here:

Levels of Automation


Full automation is recommended and is selected by default for tenants that were created on or after August 16, 2020 with Microsoft Defender for Endpoint, with no device groups defined yet.

Thus, Automation levels rely on Device Groups in Defender for Endpoint.


You see this when you create a Device Group as shown above.


With Defender for Endpoint P2 you find Device Groups via | Settings | Endpoints | Device groups as shown above.


However, with Defender for Business (above), you’ll see that there are no options currently for Device Groups. This basically means that the all remediation will be performed automatically.

I don’t that it is really a problem, but is another difference between Defender for Endpoint P2 and Defender for Business. I have not tested Defender for Endpoint P1 but I assume that it have the same lack of Device Groups as Defender for Business has, but I would to check to be 100% sure.

Defender for Endpoint server licensing

I will preface this with the ‘standard’ disclosure here that:

1. I am not a licensing expert

2. You should speak with a licensing expert to obtain clarification and verification of anything here

3. I have done my best in regards the information presented here but it may change over time, so again see point 2.

With that out of the way, a very common question I receive is around the licensing of servers with Defender for Endpoint. The summary I have found, taken from a reply from Microsoft licensing I found is the following:

In order to be eligible to purchase Microsoft Defender for Endpoint Server SKU, you must have already purchased a combined minimum of any of the following, Windows E5/A5, Microsoft 365 E5/A5 or Microsoft 365 E5 Security subscription licenses. Microsoft Defender for Endpoint Server is an add-on for customers with a combined minimum of 50 licenses of eligible Microsoft Defender for Endpoint SKUs.

Microsoft Defender for Endpoint (Server)

When you have acquired a separate Microsoft Defender for Endpoint (Server) license, you cannot assign them to a specific server or whatsoever. You need to make sure you own the number of licenses with the amount of Windows Servers you want to provision with Microsoft Defender for Endpoint (Server). If you don’t have the right amount of licenses in your Microsoft 365 tenant, then you can still roll out MDE for Server because there is no technical limitation to it, you are just not compliant at that moment in an audit.

Microsoft Defender for Cloud

If you do have not enough licenses of the products from above, you cannot license your Windows Serves with a separate MDE for Server license. Then you have to use Microsoft Defender for Cloud.

When your Windows Servers are already running within Azure, it’s just enabling the Defender Standard license and enabling your server protection. When your Windows Servers are running On-Premise (e.x. VMware ESXi/Hyper-V) you have to install the Arc Agent on your servers and then they are visible as Virtual Machines in your Microsoft Azure Portal.


You got two ways of licensing your Windows Servers with MDE for Servers. Through Microsoft Defender for Cloud, then you do not have to acquire at minimum 50 Windows E5/A5, Microsoft 365 E5/A5, and Microsoft 365 E5 Security User SLs licenses. Or acquire a separate MDE for Server license when you have at least 50 Windows E5/A5, Microsoft 365 E5/A5, and Microsoft 365 E5 Security User SLs licenses.

More info:

For most, this boils down to the fact that if you don’t have at least 50 x Microsoft 365 E5 (and I also assume, or Defender for Endpoint P2), then you need to purchase Microsoft Defender for Cloud using the Azure portal to cover any servers for Defender for Endpoint.

This would seem to imply that if you implement Defender for Business, when it becomes fully available, you’ll need to use Defender for Cloud even if you have 50 or more licenses. That may of course change when Defender for Business goes GA but my guess at this stage would be it won’t.

Now, even if you have 50 or more licenses of Microsoft E5 (or again I assume, or Defender for Endpoint P2), then you’ll need to purchase the Defender for Endpoint (Server) license for each server you wish to cover. That license is available in 2 versions, monthly and annually:

Monthly Billing

MS SKU = 350158A2-F253-4EA3-988E-EEF9D1B828CF

Annual Billing


As I also understand it, this Defender for Endpoint (Server) SKU can also only be purchased via CSP not direct. That means, it has to be purchased through a reseller not via the Microsoft 365 administration portal using just a credit card.

The more common option I suspect, given the limitations, is going to be Microsoft Defender for Cloud, which is purchased via Azure.


Which means you fire up the Azure pricing calculator and plug in the details to obtain a price. That should result in the above result of around A$21 per month, per server.

Hopefully, all this answers most questions and I’ve done my best to ensure it is correct but as always, please check for yourself. For most, the solution to licensing servers for Defender for Endpoint will mean obtaining Microsoft Defender for Cloud and the cost for that will be about A$21 per server per month.

Using Defender for Endpoint to protect your network devices

An added benefit of Defender for Endpoint is it’s ability to scan and report vulnerabilities with your network devices (routers, switches, etc). It does this by using SNMP, so the starting point is to set that up in your environment on your network devices.


Once you have onboarded Windows 10 devices to Defender for Endpoint you can use one of these to ‘scan’ your network devices via SNMP.

To do this follow the step by step process to download and install the scanner in this article:

Network device discovery and vulnerability assessments – Microsoft Tech Community

you can also refer to  this documentation

Network device discovery and vulnerability management | Microsoft Docs

In short, you need to install and agent from the Defender for Endpoint console, then configure it to scan your SNMP environment and IP range. The results from this will be reported back into the Device inventory.

Interestingly, the documentation states:

The following operating systems are currently supported:

  • Cisco IOS, IOS-XE, NX-OS

  • Juniper JUNOS

  • HPE ArubaOS, Procurve Switch Software

  • Palo Alto Networks PAN-OS

but when I set this up in my environment


the Ubiquiti equipment I use was also reporting as shown above (excellent!).


I can drill into any network device and see alerts, security recommendations, etc. None to see here as my gear is up to date but this is a super handy feature when you are facing challenges like Log4j vulnerability, even in small environments.

The main thing is to get the SNMP environment set up for your network devices and then configure a Defender for Endpoint scanner in that environment. Within no time you’ll have additional network device information flowing into your Defender for Endpoint console. This is really going to help you keep your whole environment secure and make it easy to monitor from a single location.