Using Sentinel to determine application usage

examinatyion using a magnifying glass

In recent article:

Block applications on Windows devices using Intune

I outlined how to prevent an application from running on a Windows device. It would be nice to know how many people are running this application prior to it being blocked (and even before). You can achieve this using Sentinel.

Many don’t appreciate

The extra value that Microsoft Defender provides

apart from security. In a nutshell, Defender for Endpoint sends signals from devices into the Microsoft cloud that something like Sentinel can take advantage of. This is something that can be taken advantage of to see application usage.

DeviceNetworkEvents
| where InitiatingProcessFileName contains “msedge.exe”
| project TimeGenerated, RemoteUrl, RemoteIP, DeviceName, InitiatingProcessAccountName
| summarize count() by bin(TimeGenerated,1day),DeviceName
| render columnchart

an example of this is the above KQL query, which when run provides an output like:

The result is basically a bar graph, over whatever time you specify, of how many times an application has been used. This is a great indicative way to get a feel for how often a device is running a particular application (here msedge.exe). The different bar colours show each particular device and each bar height represents the total usage of that application for one day.

The great thing is that you can further customize and enhance this query to suit your needs to product the output your require. You can then take that query and embed it into a Sentinel workbook so that it is available as part of a dashboard.

There is just so much that you can do and all it takes is becoming familiar with the tools Microsoft provides in your environment.

Block applications on Windows devices using Intune

This series of posts is an approach to implementing Intune inside a business. So far, I have covered off:

1. Create compliance policies and update devices to be compliant

2. Implement LAPS to control the local device admin account that cannot be deleted

3. Remove all other accounts from local administrator group on devices

4. Setting the default search engine in Edge with Intune

5. Managing browser extensions in Edge with Intune

6. Setting an Edge Security Baseline with Intune

7. Setting an individual Attack Surface Reduction (ASR) rule in Intune

8. Setting Edge as the default browser using Intune

Now that we have Microsoft Edge all set up and have done as much as we can to encourage people to shift away from using other browsers, it’s now time block any other browsing options. We can again use Intune to achieve this and, typically, it can be done using a number of different methods. Here, we’ll use what I consider the easiest method.

Once again, create a Configuration profile for Windows 10 and later using the Settings catalog as shown above.

Give the policy a suitable name and continue.

In the search field type ‘specified windows application’ and select Search. The only category that appears should be Administrative Templates\System, which you should select. Then in the lower pane select Don’t run specified Windows applications (User) as shown above.

Enable the Don’t run specified Windows applications (User) and then enter the name of the applications you do not wish to run. Here, we’ll block chrome.exe and brave.exe as shown above.

These settings are covered in the RestrictApps documentation in which you will note:

1. The setting applies to users not devices:

and

2. This policy setting only prevents users from running programs that are started by the File Explorer process. It doesn’t prevent users from running programs such as Task Manager, which are started by the system process or by other processes. Also, if users have access to the command prompt (Cmd.exe), this policy setting doesn’t prevent them from starting programs in the command window even though they would be prevented from doing so using File Explorer.

3. Blocking occurs by filename only. If users can rename the file then it will execute.

As mentioned previously, this is but the simplest method to block existing applications from running. Other options are available if you wish a more comprehensive blocking approach.

Finish configuring the policy remembering to assign it to a user NOT device group.

Once the policy has been deployed to your fleet and these machines have been rebooted, when a user tried to run an application that you have specified as block in the policy they will receive message like that shown above.

The good thing about this policy is that you can easily extend it to include any other applications you don’t users to run on their Windows devices.

Setting Edge as the default browser using Intune

This series of posts is an approach to implementing Intune inside a business. So far, I have covered off:

1. Create compliance policies and update devices to be compliant

2. Implement LAPS to control the local device admin account that cannot be deleted

3. Remove all other accounts from local administrator group on devices

4. Setting the default search engine in Edge with Intune

5. Managing browser extensions in Edge with Intune

6. Setting an Edge Security Baseline with Intune

7. Setting an individual Attack Surface Reduction (ASR) rule in Intune

Now that Microsoft Edge has been secured in the environment, the next task will be to set Microsoft Edge as the default browser. There are number of ways of achieving this, but I’ll use the more modern Intune Settings catalog approach.

The first step in the process is to take a machine that already has Microsoft Edge configured as the default browser app and run the command:

dism /online /export-defaultappassociations:edgedefault.xml

This will produce an XML with all the application defaults for that device.

If you just want to configure Microsoft Edge as the default browser you’ll need to edit the XML file until it looks something like this:

<?xml version=”1.0″ encoding=”UTF-8″?>
<DefaultAssociations>
     <Association Identifier=”.htm” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”.html” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”.mht” ProgId=”MSEdgeMHT” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”.mhtml” ProgId=”MSEdgeMHT” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”.pdf” ProgId=”MSEdgePDF” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”.svg” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”.xht” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”.xhtml” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”ftp” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”http” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”https” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”microsoft-edge” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”microsoft-edge-holographic” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”ms-xbl-3d8b930f” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
     <Association Identifier=”read” ProgId=”MSEdgeHTM” ApplicationName=”Microsoft Edge” />
</DefaultAssociations>

Next, you’ll need to convert that XML file to a base64 file for us an Intune policy. You can do that using the following site:

https://www.base64encode.org/

The output from this conversion should look like this:

PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4NCjxEZWZhdWx0QXNzb2NpYXRpb25zPg0KCTxBc3NvY2lhdGlvbiBJZGVudGlmaWVyPSIuaHRtIiBQcm9nSWQ9Ik1TRWRnZUhUTSIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0iLmh0bWwiIFByb2dJZD0iTVNFZGdlSFRNIiBBcHBsaWNhdGlvbk5hbWU9Ik1pY3Jvc29mdCBFZGdlIiAvPg0KCTxBc3NvY2lhdGlvbiBJZGVudGlmaWVyPSIubWh0IiBQcm9nSWQ9Ik1TRWRnZU1IVCIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0iLm1odG1sIiBQcm9nSWQ9Ik1TRWRnZU1IVCIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0iLnBkZiIgUHJvZ0lkPSJNU0VkZ2VQREYiIEFwcGxpY2F0aW9uTmFtZT0iTWljcm9zb2Z0IEVkZ2UiIC8+DQoJPEFzc29jaWF0aW9uIElkZW50aWZpZXI9Ii5zdmciIFByb2dJZD0iTVNFZGdlSFRNIiBBcHBsaWNhdGlvbk5hbWU9Ik1pY3Jvc29mdCBFZGdlIiAvPg0KCTxBc3NvY2lhdGlvbiBJZGVudGlmaWVyPSIueGh0IiBQcm9nSWQ9Ik1TRWRnZUhUTSIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0iLnhodG1sIiBQcm9nSWQ9Ik1TRWRnZUhUTSIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0iZnRwIiBQcm9nSWQ9Ik1TRWRnZUhUTSIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0iaHR0cCIgUHJvZ0lkPSJNU0VkZ2VIVE0iIEFwcGxpY2F0aW9uTmFtZT0iTWljcm9zb2Z0IEVkZ2UiIC8+DQoJPEFzc29jaWF0aW9uIElkZW50aWZpZXI9Imh0dHBzIiBQcm9nSWQ9Ik1TRWRnZUhUTSIgQXBwbGljYXRpb25OYW1lPSJNaWNyb3NvZnQgRWRnZSIgLz4NCgk8QXNzb2NpYXRpb24gSWRlbnRpZmllcj0ibWljcm9zb2Z0LWVkZ2UiIFByb2dJZD0iTVNFZGdlSFRNIiBBcHBsaWNhdGlvbk5hbWU9Ik1pY3Jvc29mdCBFZGdlIiAvPg0KCTxBc3NvY2lhdGlvbiBJZGVudGlmaWVyPSJtaWNyb3NvZnQtZWRnZS1ob2xvZ3JhcGhpYyIgUHJvZ0lkPSJNU0VkZ2VIVE0iIEFwcGxpY2F0aW9uTmFtZT0iTWljcm9zb2Z0IEVkZ2UiIC8+DQoJPEFzc29jaWF0aW9uIElkZW50aWZpZXI9Im1zLXhibC0zZDhiOTMwZiIgUHJvZ0lkPSJNU0VkZ2VIVE0iIEFwcGxpY2F0aW9uTmFtZT0iTWljcm9zb2Z0IEVkZ2UiIC8+DQoJPEFzc29jaWF0aW9uIElkZW50aWZpZXI9InJlYWQiIFByb2dJZD0iTVNFZGdlSFRNIiBBcHBsaWNhdGlvbk5hbWU9Ik1pY3Jvc29mdCBFZGdlIiAvPg0KPC9EZWZhdWx0QXNzb2NpYXRpb25zPg==

In the Intune console, create a new Device Configuration profile using the Settings Catalog:

Give the new policy a meaningful name and continue.

In the Settings picker search for applications and then select Application defaults and then Default Associations Configuration in the results as shown above.

Into the option Default Associations Configuration paste a copy of the base64 file you created from the original XML.

Complete the policy by assigning it to a group of devices NOT users. This is because the Policy CSP – ApplicationDefaults is only scoped to devices per:

This may mean you need to create a different Edge configuration policy from the one created in previous steps, if that policy was assigned to users.

When the policy has been deployed from Intune, and the device rebooted, Microsoft Edge will be the default browser for the device.

Of course, the user can still change the default back but they will need to do that after every reboot. In the future, you’d create a policy to prevent that, but for now, if the user is that desperate for their old browser they can swap. However, the next policy I’ll cover will show you how to stop other browsers (or any other application) from running on Windows devices.

Setting an individual Attack Surface Reduction (ASR) rule in Intune

This series of posts is an approach to implementing Intune inside a business. So far, I have covered off:

1. Create compliance policies and update devices to be compliant

2. Implement LAPS to control the local device admin account that cannot be deleted

3. Remove all other accounts from local administrator group on devices

4. Setting the default search engine in Edge with Intune

5. Managing browser extensions in Edge with Intune

6. Setting an Edge Security Baseline with Intune

The next recommended setting to implement is Attack Surface Reduction (ASR) rules. I’ve detailed how you can set this on individual devices using PowerShell here:

Show ASR settings for device with PowerShell

I’ve also detailed how to do this with Intune previously:

Attack surface reduction for Windows 10

In a nutshell, ASR is going to prevent child processes from launching, which is typically how a malware infection starts.

To create a stand alone ASR rule navigate to Endpoint security, Attack surface reduction in the Intune portal and select Create policy, as shown above.

Select the platform as Windows 10, Windows 11 and Windows Server and the profile as Attack Surface Reduction Rules.

Then Create the policy

As always, give the policy a meaningful name.

You should then see a list of the 16 standard ASR rule types as well as a rule called Block Webshell creation for Severs.

The best practice is to set all of these to Block. However, you will also see options for Audit and Warn if you want to take a more cautious approach.

The good thing about an individual ASR policy like this is that you get a lot more options that can be configured, unlike other policies in Intune that also include ASR. An example if the above, where you can provide enter a directory or file which will prevent ASR rules from matching. As an example, a path might be defined as: C:\Windows to exclude all files in this directory. A fully qualified resource name might be defined as: C:\Windows\App.exe.

Best practice is not to have any exclusions.

A little further down you’ll see a setting for Enable Controlled Folder Access as shown above. The controlled folder access feature removes modify and delete permissions from untrusted applications to certain folders such as My Documents.

Best Practice is to set this to Enabled.

Under this you can set Controlled Folder Access Protected Folders and Controlled Folder Access Allowed Applications. Controlled Folder Access Protected Folder allows adding user-specified folder locations to the controlled folder access feature. These folders will complement the system defined folders such as My Documents and My Pictures. The Controlled Folder Access Allowed Applications allows user-specified applications to the controlled folder access feature. Adding an allowed application means the controlled folder access feature will allow the application to modify or delete content in certain folders such as My Documents. In most cases it will not be necessary to add entries. Windows Defender Antivirus will automatically detect and dynamically add applications that are friendly.

Best practice is to not have any settings here and to have these both set to Not configured.

When you configure an individual rule you’ll also see the ability to set exceptions for just this rule. As an example, a path might be defined as: c:\Windows to exclude all files in this directory. A fully qualified resource name might be defined as: C:\Windows\App.exe.

Once you have determined your settings you then apply the policy to an audience in your environment. You can use multiple policies if needed for different audiences.

If you want to monitor ASR actions in your environment you can use the following KQL query:

DeviceEvents
| where ActionType startswith ‘Asr’

This going to help you identify which devices and processes ASR is impacting, making troubleshooting much easier.

If you want to read more about ASR then visit:

Understand and use attack surface reduction capabilities

I believe ASR is something that should be enabled fully on all Windows devices, withou any exceptions or exclusions. It is an ability included with Windows for free and just needs to be enabled, either by policy or PowerShell. I would recommend setting an individual ASR policy as I have shown above as it provides the greatest flexibility when configuring as well as the greatest number of exclusions if required. Many other Intune policies include the ability to configure ASR but if you have a stand alone policy you should not configure it elsewhere or you may end up with configuration clashes and errors.

The next recommended policy will be for Defender for Endpoint.

Setting an Edge Security Baseline with Intune

This series of posts is an approach to implementing Intune inside a business. So far, I have covered off:

1. Create compliance policies and update devices to be compliant

2. Implement LAPS to control the local device admin account that cannot be deleted

3. Remove all other accounts from local administrator group on devices

4. Setting the default search engine in Edge with Intune

5. Managing browser extensions in Edge with Intune

The next step in the process is to assign a security baseline to the Microsoft Edge environment. Security baseline policies differ from all other policies in Intune because they already have best practice settings enabled. This compares to other Intune policies where you need to go into each policy item and set them to the desired setting. Another benefit of using Security baselines is that they are easily upgradable when updated policies become available. These two factors save a lot of time and effort securing your environment.

In the Intune console, navigate to Endpoint security | Security baselines and select Security Baseline for Microsoft Edge as shown.

Select the option to Create profile and then give the profile a meaningful name.

You’ll then see a list of the individual settings with values already selected.

You can adjust any of the individual settings if you need to customise the policy. Generally, I find there is no need to make any changes here as I have found no conflicts.

Here we also find an example of one of the challenging things with implementing any policy, duplicate settings. If you remember back to the previous article on

Managing browser extensions in Edge with Intune

you’ll note that extension restrictions was configured there, but now it is also in this Security baseline policy. A best practice recommendation is to only have one place in your policies where a setting is made. This will avoid conflicts and aid troubleshooting. If you do choose to retain the same settings in multiple policies, ensure they are set identically or otherwise you will get conflicts. In this case I’ll leave the setting in place for both policies as they are the same and it is bit challenging to disable just this option in the original ‘Edge configuration’ policy created in the previous post.

With any changes made, continue with the Security baseline policy configuration and assign it to your environment.

When complete you should see the policy you just created, as shown above. Remember, you can create as many policies as you need to accommodate your environment targeted to different audiences, however the aim should be to get to a single Security baseline policy for Edge to keep things simple.

You’ll see that the policy created has a version number. You’ll also note a Change version button on the menu at the top (currently greyed out) as shown above. This is the beauty of a Security baseline policy, when an update is available you’ll be able to use this option to update the policy. You can read more about this here:

Update a profile to the latest version

We are now at a point in our roll out where we have policies to provide a secure Microsoft Edge configuration in our environment. Those already using Microsoft Edge will benefit immediately, users on other browsers still need to ‘encouraged’ to make the shift as soon as possible, but are still not being forced to use Microsoft Edge just yet (they will be eventually, so keep encouraging them to make the shift with your communications because they day when they have no other option but to switch is coming!).

for more information about the:

Microsoft Edge security baseline settings reference for Microsoft Intune

visit the above link and remember the benefit of Security baselines is that they have best practice settings already enabled, so typically all that is needed to apply the policy with these default settings .

It is now time to look at securing the Windows devices against ransomware. Stay tuned.

Managing browser extensions in Edge with Intune

This series of posts is an approach to implementing Intune inside a business. So far, I have covered off:

1. Create compliance policies and update devices to be compliant

2. Implement LAPS to control the local device admin account that cannot be deleted

3. Remove all other accounts from local administrator group on devices

4. Setting the default search engine in Edge with Intune

The goal we are trying to achieve is to move all users from third party browsers to using Microsoft Edge. The next step in this process will be deploying and managing a constrained set of extensions in Microsoft Edge.

The first step is to visit the Microsoft Edge store for extensions and grab the unique ID for the extensions you want to use. You find this in the URL for the extension as shown above. Here are three common extensions I will use for this example:

Lastpass – bbcinlkgjjkejfdpemiealijmmooekmp

DuckDuckGo Privacy – caoacbimdbbljakfhgikoodekdnlcgpk

Save to Pocket – jicacccodjjgmghnmekophahpmddeemd

Once we have these we need to login to the Intune management portal.

In the last article I created a generic device configuration profile called ‘Edge configuration’ policy that I’ll be extending here. Select the policy name to view its settings.

Scroll down the policy until you locate the heading Configuration settings as shown above, and then select the Edit hyperlink to the right of this.

Select the + Add Settings link as shown above.

Expand the Microsoft Edge option in the top part of the blade that appears and then select Extensions as shown above. In the options that appear in the lower part of the screen select:

– Allow specific extensions to be installed

– Control which extensions are installed silently

– Control which extensions cannot be installed

Close the blade.

You should now see the ability to customise these options in the policy as shown above.

Add the ID’s of the extensions you want silently installed and ensure that each is ticked as shown.

Add ‘*’ (i.e. all) as the option for IDs to be prevented from being installed and ensure it is ticked as shown. Basically all other extensions will not be permitted to be installed.

Add the ID’s of the extensions you want to allow in the exempt from block area and ensure each is ticked as shown.

Save the policy changes and allow it to be propagated to all groups included in the policy.

Once the policy has rolled out, you should find the extensions you entered in the policy have been added to Microsoft Edge as shown above.

You should also find that users cannot add additional extensions to their Microsoft Edge browser as shown above.

The aim of this exercise was to automatically configure a number of ‘standard’ extensions for Microsoft Edge and block everything else. We have been able to achieve this by extending the original ‘Edge configuration’ policy that was created earlier.

The next step in the process will be to lock down the Microsoft Edge browser using a baseline policy. Stay tuned.

Setting the default search engine in Edge with Intune

This series of posts is an approach to implementing Intune inside a business. So far, I have covered off:

1. Create compliance policies and update devices to be compliant

2. Implement LAPS to control the local device admin account that cannot be deleted

3. Remove all other accounts from local administrator group on devices

One of the longer term best practice goals is to move all users to exclusive use of Microsoft Edge as a browser. Doing so will improve overall security, provide greater management of the browsing experience and provide a consistent environment.

In most existing environments today, users in a business are using a variety of browsers. It is my experience that, generally, users are not wedded to the type of browser they use but many are wedded to the search experience they have become familiar with. Changing this experience abruptly is going to reduce user productivity and create resistance to change. In order then to ease the transition from other browsers to using Microsoft Edge a recommended approach is to use Intune to change the default search experience in Microsoft Edge to the one users are familiar with. It is important to remember that Edge will be pretty much 100% compatible with the browser they use today, along with any extensions. Also, the idea with this step is not to force users to use a new browser but start preparing for that change.

The first step in the browser migration project will be to set the search experience in Edge to be what a user is familiar with. To do this you will need to create a new Intune configuration profile.

In the Intune console select Devices then Configuration profiles. Then select Create profile on the right. Select Windows 10 and later for the profile and Settings catalog for the profile type. Select Next to continue.

This policy is something that will be added to overtime so it is suggested you call the policy something like ”Edge configuration” as shown above. Select Next to continue.

Select the +Add settings link

Locate the Microsoft Edge\Default search provider in the top of the blade that appears on the right as shown above. Select this and a list will appear in the lower half. FRom the list in the lower portion, select the following four settings:

– Configure the new tab page search box experience

– Default search provider name

– Default search provider url

– Enable the default search provider

Close the settings picker by selecting the cross (x) in the top right hand corner.

Enable the four new settings, as shown above, and given that Google is the most common search engine, here are the appropriate settings for setting the default search engine in Microsoft Edge to be Google:

New tab page search box experience = Address bar

Default Search provider search URL = https://www.google.com/search?q={searchTerms}

Default search provider name = Google

You can of course use any search provider you wish. My preference would be for DuckDuckGo but remember, the idea here is to provide the lowest amount of friction to migrate users away from the third party browsers they are probably using. However, if you wish to force a new search experience, now is probably the best time to do that.

Complete the policy and assign it to your users. You then need to allow the policy to roll out.

Now when users type a search term into the URL box, while using Microsoft Edge, it will use the search engine you just configured via the Intune policy as shown above.

Remember, at this stage all that has been done is to set a new default search engine for Microsoft Edge. If the users are not yet using Edge then they will be unaffected by this change. The idea is to make the Edge environment as familiar as possible before forcing users to use Edge instead of the browsers they current use.

Of course, if some users are using Edge this change will affect them and you should prepare for that but communicating the reasons for the change and how everyone will be shifting to Edge and this is the first step in the process to provide a more secure and consistent environment for everyone. You could also just target this new policy to users not currently using Edge as their default policy. The choice is yours, but the endgame is to get everyone using a secured version of Edge with consistent settings.

We’ll come back and make more changes to this Edge configuration policy over time but for now we have all versions of Edge using the same search engine.

Controlling local user group membership with Intune

I recently outlined how to

Control local admin on a device with LAPS and Intune

Once you have LAPS in place I suggested that you want to eliminate any local device administrators as a best practice. You can achieve this via a policy in Intune.

The first step in the process is going to be to determine any local administrator accounts and what they are doing in your environment. A good starting point is this KQL query to look for local admin activity in your device fleet:

DeviceLogonEvents
| where TimeGenerated >= ago(7d)
| where IsLocalAdmin == true
| summarize count() by DeviceName, AccountName,LogonType
| sort by AccountName

That will, of course, only show you logon activity by an account that is a local administrator. For dormant local admin accounts you are going to need to do more work to flush them out. However, the query will at least show you active local admin accounts that maybe impacted by any changes made using something like LAPS.

To set a policy to control local groups on Windows devices, login to the Intune management portal and select Endpoint security and Account protection, as shown above. Create a new policy for Windows 10 and later and select Local user group membership as the Profile.

Give your policy a meaningful name and continue.

Select the local group (here Administrators), select the action (here Remove) and Manual for the User selection type.

When you select the Add users hyperlink in the Selected users/groups field you will see the above blade appear. In here, you’ll find a number of different methods of identifying users. If you have a list of local device admins then you can add them here.

Once you have entered all the users you wish to remove from the local device administrators group, complete the policy and assign it to the audience you wish.

The policy will then roll out to your environment and the changes will be made to the local group membership. In this case, it will remove local users from the local device administrator group so they can no longer administrate the device.

Remember, there are lots of options here. You could different policies for different users and/or devices. You could create policies to not only remove but also add. An example maybe where you wish an Entra ID user to be a local administrator of box. In that case, simply select the option to Add the user from Entra ID to the local administrators group. There is a lot of flexibility here with this policy.

Typically, once your policy has completed and there are no more local administrators you can remove the policy, as hopefully no more local accounts will be created with devices being joined directly to Entra ID. However, you may wish to retain it for if new devices are joined to your environment, especially if you don’t use Autopilot.

In summary then, the process so far, is:

1. Create compliance policies and update devices to be compliant

2. Implement LAPS to control the local device admin account that cannot be deleted

3. Remove all other accounts from local administrator group on devices

Typically, these steps will have no impact on users working with their devices and it commences the process of implementing a consistent environment and making it more secure.

You can read more about this particular policy here:

Manage local groups on Windows devices