MDM & GP Tips Blog

Companies want to control the background image on their workstations to maintain a professional appearance, reinforce brand identity, and ensure consistency across all devices. It also prevents "genreal messing around" and at least looks tidy. .

Setting up a background image for on prem corporate workstations using Group Policy was straightforward.

• An administrator stored the background image on a network share
• A GPO was created to point to the shared image

However, for mobile and remote machines, this approach is not feasible as these devices are often disconnected from the corporate network.

Intune provides a solution for assigning a background image to any Windows computing device it manages, regardless of location. The first step is to store your shared image on the internet as I have done below.

https://cdnsm5-ss9.fabrikam.com/UserFiles/Servers/Server_136424/Image/Departments/Technology/UserBackground.jpg

Then, using the Microsoft Intune Admin Center navigate to Devices > Configuration > Create New policy and select Windows 10 and later as the platform and settings catalog as the Profile type. Using the Settings picker, do a search for personalization. Then choose Desktop Image URL and input the URL as shown in the screenshot below.

Another key difference here is that with Group Policy, the image is not downloaded to the device. The policy simply points to the image in its shared location. Using Intune, both the policy and image file are pushed to the managed devices, and the image is stored on the device itself.

This makes Intune a preferred solution for off-premises machines. Like any configuration profile, the final step is to assign the policy to the designated groups, and you are done.

Traditional cybersecurity approaches have primarily focused on attack prevention through measures like firewalls, antivirus software, and access controls. Recently however, cybersecurity has transitioned to a resiliency mindset. With the rise of advanced persistent threats (APTs), state-sponsored attacks, ransomware, and other sophisticated cyber threats, it has become increasingly difficult to prevent all attacks through traditional security measures alone. Resiliency acknowledges that breaches are likely to occur and focuses on minimizing their impact and ensuring continuity of operations.

At any moment, attackers can begin exploiting a vulnerability that is unknown to anyone in the world except themselves. These zero-day attacks are particularly challenging because you cannot defend against a threat you are unaware of. The compromise of user accounts has also become common place using phishing and credential stuffing attacks. It has become clear that organizations must prepare themselves for the inevitability that such attacks are probably going to occur. By fostering resilience in their systems and networks, they can limit the blast zone and prevent attackers from moving laterally across the network and obtaining greater privileges. A resilient approach acknowledges that breaches are likely to happen and focuses on minimizing their impact and ensuring continuity of operations.

How Group Policy can Help

A primary means of building resilience within your enterprise is to enforce the principle of least privilege (PoLP). PoLP minimizes security risks by ensuring users and systems have only the necessary access to perform their tasks. This reduces the potential attack surface, limits the impact of breaches, and prevents unauthorized access to sensitive data, thereby enhancing overall cybersecurity in an increasingly complex and threat-prone digital environment. Here are some classic Group Policy settings to harden your attack surface.

You can quickly restrict access to the command prompt completely with User Configuration > Administrative Templates > System and enable ‘Prevent access to the command prompt’. For additional security, you can select ‘Disable the command prompt script processing also’ as shown in the screenshot below. This means that any script that attempts to execute a batch file will fail, and users will not be able to run batch scripts manually.

By disabling both the command prompt and script processing, this setting significantly enhances security by reducing the potential for users to execute potentially harmful scripts or commands.

Enforcing the membership of privileged local groups on all your enterprise computers is a crucial aspect of resiliency building. You can achieve this using either Group Policy Preferences or the Security Settings in Group Policy. In the example below, I have chosen the latter approach. I navigated to **Computer Configuration** > **Policies** > **Windows Settings** > **Security Settings** > **Restricted Groups**. I then selected the local Administrators group and specified domain admins as the only members, as shown below.

These examples illustrate how you can leverage Group Policy to enhance the resilience of your Windows machines against various threats and vulnerabilities. By implementing settings through Group Policy Administrative Templates and Preferences, you can enforce robust security configurations across your Windows environment.

However, these are just a few of the many resilience-focused measures that can be deployed using Group Policy. In the next installment of this article series, we will explore additional resilient settings and configurations that can be implemented through Group Policy to further fortify your Windows infrastructure against cyber threats, insider risks, and potential misconfigurations.

While security professionals have traditionally recommended that users change their passwords regularly, this mantra is no longer considered a best practice. In fact, there are valid reasons why an organization may choose to even remove the ability for users to change passwords altogether. By restricting password changes, organizations can ensure that password resets and updates are centrally managed and controlled, aligning with their security policies and compliance requirements.

One scenario where restricting password changes can be beneficial is in educational institutions where student usernames are required to contain assigned student ID numbers. Allowing students to change their passwords could lead to inconsistencies and potential issues with account management.

Other examples include environments where shared accounts are used where permitting individual users to change passwords can lead to confusion, disruption, and potential security risks. By removing this ability, organizations can ensure that shared account passwords are managed centrally and consistently.

Some organizations may already have established password management solutions or processes in place, such as Local Administrator Password Solution (LAPS) or third-party password management tools. In these cases, removing the ability for users to change passwords through Intune can help prevent conflicts or inconsistencies with these existing solutions, ensuring a streamlined and cohesive password management approach.

Creating the Necessary Intune Configuration Profile

To prevent users from changing their passwords using the Microsoft Intune admin center go to Devices > Configuration and create a new policy. Select ‘Windows 10 and later’ as the platform and choose ‘Administrative Templates’ as the profile type. Then name the profile and proceed to configuration settings.

You will find the appropriate settings in User Configuration > System > Ctrl+Alt+Del Options and enable ‘Remove Change Password” as shown in the screenshot below.

While restricting the ability for users to change passwords can address certain challenges, it is recommended that organizations carefully evaluate their specific requirements, security policies, and existing processes before implementing such a policy. They should consider any potential complexity issues in terms of password management and user experience that it may introduce.

Security baselines are used to standardize and enforce security configurations across devices to reduce vulnerabilities and ensure compliance. They allow organizations to rapidly deploy a hardened, secure configuration across their managed Windows devices. The baselines contain groups of pre-configured settings recommended by Microsoft's product security teams, saving significant time and effort in researching and testing individual settings. Pre-configured baselines simplify the deployment of security settings to make it easier for IT administrators to apply comprehensive security policies without having to configure each setting manually. By using predefined baselines, administrators can save time and effort compared to developing and implementing custom security policies from scratch.

Security baselines can be deployed using either Group Policy or Microsoft Intune. Group Policy baselines are typically managed by importing the latest Microsoft Security Compliance Toolkit baselines and customizing settings via GPOs while Intune security baselines are managed directly in the Intune admin console, where admins can create profiles based on the built-in Microsoft-provided baselines and customize settings.

While providing a solid security foundation, baselines can also be customized to meet the specific needs of an organization by adjusting the pre-configured security settings as required. You can assign different Intune security baselines to different user or device groups. This allows you to tailor the security configurations based on specific requirements or roles within your organization. After creating the desired security baseline profiles, you can assign each profile to different user or device groups within your Intune environment. This allows you to apply distinct security configurations to different sets of users or devices based on their roles, locations, or other criteria.

Deploying Security Baselines with Intune

To deploy security baselines using the Microsoft Intune admin center, navigate to Endpoint security > Security baseline and select from the available security baselines. For this example, I will choose the 'Security Baseline for Windows 10 and later' and customize it.

After clicking the selected baseline, click the ‘Create profile’ button to create a new profile.

Name the new profile and then proceed to the Configuration settings section. The baseline template has all the settings configured according to best practices by Microsoft engineers. However, there are a couple of settings I want to customize in this case. For instance, the Allow Password Manager setting is configured to Block by default, but in this case, I want to allow it for certain user roles.

Another setting I chose to change is to block outbound traffic which is not the case by default.

Of course, I could also choose to accept all the preconfigured settings as they are and create a profile too. In this case, deploying the preconfigured baseline makes it convenient to blast out best practice security settings.

In the same manner that Intune configuration profiles are created, you need to assign this customized security baseline profile to designated groups and then finish out the wizard. You can create as many profiles of the same security baseline as you want. By assigning different Intune security baselines to different user or device groups, you can effectively implement a tailored and granular security strategy that aligns with the specific needs and risk profiles of various segments within your organization.

Intune provides the capability to enable or disable various BIOS features and settings, enhancing device security before the operating system even loads. Among these features is the ability to set or change the BIOS password, which is crucial for securing the boot process and protecting the device against unauthorized changes to BIOS settings. Additionally, Intune allows for the configuration of boot sequence settings, the enabling or disabling of hardware components, and the management of power management settings, among others. This comprehensive control over BIOS settings helps fortify device security and ensures a consistent configuration across the enterprise. As of right now Intune only supports Dell computers.

Create and Deploy the Dell Configuration File

To create a Dell configuration file, follow these preliminary steps to ensure your devices meet the necessary requirements for successful configuration via Intune:

1. Device and System Requirements:

• Ensure the device is a Dell commercial client running Windows 10 or a later version.
• The device must be enrolled in Intune's mobile device management (MDM) system.
• .NET 6.0 runtime for Windows x64 must be installed on the device.
• Install Dell Command | Endpoint Configure for Microsoft Intune (DCECMI) on the endpoint.

2. Creating the Configuration File:

• Download the DCECMI tool from Dell’s official website. Using this tool, you can create a configuration file tailored to your specific needs, including any OEM-supported configuration settings.
• When creating the configuration file, a corresponding Win32 app, provided by the OEM, will be needed. This app acts as an agent that interprets the configuration file and manages BIOS password settings among other configurations.

3. Deployment:

• Deploy the OEM Win32 app to all relevant devices using Intune. This app is crucial as it reads the configuration file and applies the settings, including BIOS passwords, to the devices

Target the BIOS Configuration Policy

To effectively target the BIOS configuration policy, you should focus on a specific set of devices. Here are two options for doing so:

Option 1: Create a Device Group

• Create a group comprising only the devices needing the policy. Assign both the app policy and the BIOS configuration policy directly to this group during creation.

Option 2: Use an Assignment Filter

• Implement an assignment filter based on the device manufacturer, specifically targeting OEM devices. Apply this filter when assigning the app and BIOS configuration policies.

Creating the BIOS Configuration Policy

Now it is time to create the policy itself. Using the Microsoft Intune Admin Center navigate to Devices > Configuration and create a new policy. Select Windows 10 and later as the Platform and select ‘BIOS configurations and other settings as the Profile Type as shown in the screenshot below.

In the Configuration settings, select your hardware OEM vendor from the list of supported OEMs which is currently, only Dell. Next you will configure ‘Disable per-device BIOS password protection’ by choosing No or Yes.

• No: Intune assigns a unique device password to each device. Users must use this password to access and modify the BIOS settings on their device.
• Yes: The BIOS is not protected by a password. Any previously set passwords are cleared, allowing end users unrestricted access to the BIOS settings.

The final step is to point to the configuration file you made earlier with the OEM tool as shown in the screenshot below.

Then assign the profile to the group you designated earlier, and the BIOS settings will be delivered.

One of the features of Intune is the ability to deploy applications across a wide range of devices and users. For this demonstration I want to install RingCentral for my East Coast Sales users, but first there are some prerequisites to complete first. Using a Windows 11 computer you will need to:

1. Download the Microsoft Win32 Content Prep Tool (IntuneWinAppUtil.exe)
2. Download the installer for the designated program.
3. Create the necessary folder structure for the setup files.

Opting for an MSI file when available is recommended for Intune deployments, as handling EXE files require additional steps and configurations. Once completed, you can begin to wrap the designated application for Intune deployment. Using either PowerShell or a Command Prompt, you will use the series of commands as shown below. In this scenario, the IntuneWinAppUtil is located within a folder named "Intune," containing both a "Source" and an "Output" subfolder for organizing the necessary files.

You can also type a single command that will look like this:

IntuneWinAppUtil.exe -c -s -o

In this example, I didn’t need to specify a catalog folder. When required, the Catalog Folder contains any configuration files, scripts, or other resources required by the application during its deployment process. Including this folder ensures that all necessary components are packaged together, facilitating a smoother and more reliable installation process when the application is deployed via Intune to end-user devices.

When you run the command successfully it should look something like the screenshot below.

The purpose of the wrapping process is to create the required ‘.intunewin’ file as shown below:

With the wrapping process complete, you are ready to upload the file to Intune. Using the Microsoft Intune Admin Center, navigate to Apps > Windows and click Add and select Windows app (Win32) from the dropdown menu as shown below.

Then you need to upload the application package file that was created using the Content Prep Tool.

Once I clicked ‘OK’ Intune filled in the required settings under App Information other than Publisher which I provided. In the next screen, Program, Intune then added the install and uninstall commands automatically as shown below.

In the Requirements screen you will need to provide the Operating System architecture as well as the minimum operating system required.

The next screen requires you to create a detection rule for Intune using. You generally define the rule within the Intune application deployment settings to verify if the application is already installed on a device. This involves specifying the path where the application is expected to be installed, and optionally, a file or executable within that path. For example, you might set a rule to check for the presence of an application executable in the "Program Files" directory. If the specified file is found, Intune considers the application installed; if not, it will proceed with the installation. This approach helps prevent reinstallation of applications already present on the device. In the screenshot below I have manually provided the path to the ProgramFiles folder where the RingCentral folder and application resides.

While dependencies and supersendence aren’t necessary here, let’s review what they are. Software dependencies section is for applications that must be installed before this application can be installed. The Supersedence section allows administrators to specify a new version of an application that should replace an older version already installed on devices. By defining supersedence relationships, Intune can automatically update or uninstall the previous version of the app when the new version is deployed, ensuring that users always have access to the latest features and security updates while maintaining a clean and optimized device environment.

Not needing scope tags either, we are ready to move to the final step which was to assign the app deployment policy to the East Sales Users group and then review and create the policy.  Once complete, the designated users will receive the application.

The web browser today has literally become the default app in this era of the cloud and spurred the growth of browser extensions. Browser extensions provide a convenient way to customize and enhance a user’s web browsing experience with added functionalities and features directly within the browser. However, just as you don’t want users utilizing certain applications on corporate devices, you might want to restrict certain browser extensions for reasons of security, compliancy, content control, productivity, and performance. For instance, you may not want users installing a VPN extension to get around your web filtering. Fortunately, there are a couple of ways to achieve this.

Create a Browser Extension Blocklist with Intune

If you use Intune to manage your Windows 10 and Windows 11 laptops, you can create a configuration profile that will specify which extensions a user cannot install. Extensions already installed prior to the deployment of blocklist will be disabled without a way for the user to enable them. Should the blocklist be removed at some point, the extension will automatically become enabled once again.

Using the Microsoft Intune Admin Center go to Devices > Configuration and create a new profile. Choose Windows 10 and later as the platform and Administrative Templates as the Profile type. Assign a name to the profile and then navigate to User Configuration > Microsoft Edge > Extensions and then enable “Control which extensions cannot be installed” and input the extension names you want to filter out. You can look up extension names on the Internet. An example is shown below.

Then assign the profile to the designated groups and complete the wizard. You can also apply Edge browser extension restriction on the Computer side. In the example below, I have configured a block list for the Chrome browser.

Create a Browser Extension Blocklist with Group Policy

You can do the same with Group Policy. Because we are using Administrative Templates, the setting navigation is basically identical. Create a GPO and use the Group Policy Management Editor to navigate to User Configuration > Administrative Templates > Microsoft Edge > Extensions and enable “Control which extensions cannot be installed” as shown below. Once again, you will need to input the names of the browser extensions.

Windows Copilot is a feature designed to enhance user productivity and support through AI-powered assistance directly within the Windows operating system. It offers real-time suggestions, automates tasks, and provides contextual help based on user actions and behaviors. By integrating deeply with Windows, Copilot simplifies navigation, streamlines workflows, and helps users efficiently manage their tasks, making technology more accessible and intuitive for everyone.

Think of Copilot as a specialized variant of ChatGPT, seamlessly integrated into the Windows operating system to provide real-time assistance, task automation, and contextual support directly from the desktop environment. Despite its clear advantages, there are potential concerns that an organization might have:

• Copilot’s ability to analyze user data and behaviors might raise privacy concerns.
• The use of AI tools may conflict with some security compliances concerning the handling of data.
• Copilot may not be suitable for some roles that require precise communication.
• While it promises to boost productivity, reliance on Copilot could diminish users' problem-solving abilities.
• The introduction of Copilot may lead to new errors that can potentially disrupt workflows
• In scenarios such as public kiosks, the functionality of Copilot may be unnecessary or even inappropriate.

Block with Group Policy

To restrict user access to Windows Copilot, create a GPO using Group Policy Management and then navigate to Computer > Administrative Templates > Windows Components > Windows CoPilot and enabe “Turn off Windows Copilot” as shown in the screenshot below.

Block with Intune

While Intune currently lacks a direct menu option for configuring Windows Copilot, but it can be administered through OMA-URI settings. The essential settings required are as follows:

OMA-URI Path: ./User/Vendor/MSFT/Policy/Config/WindowsAI/TurnOffWindowsCopilot

Data type: Integer

Value: 1

Complete the profile by adding any desired scope tags and assign the profile to your designated groups and finish the wizard.

In the past, group policy administrators focused on limiting standard users' access to various sections of the Windows Control Panel. Today, while controlling access to the Control Panel remains important, it's equally crucial to restrict access to the Windows Settings app. This approach is driven by several key objectives:

• Prevent unauthorized modifications that could undermine system security.
• Ensure compliance of regulatory standards
• Enhance the reliability of client devices and systems to reduce ticket volume.
• Safeguard against both accidental and deliberate data loss scenarios.
• Ensure computers are optimized for business-critical functions.
• Facilitate device management and troubleshooting by maintaining consistent settings across the organization.

One way to approach this is rather than creating an Intune policy that restricts access to specific ms-settings, you use an allow list approach that only allows access to a specific list of settings. To do so using the Microsoft Intune Admin Center go to Devices > Configuration and click “Create” to make a new profile. Choose Windows 10 and later as the Platform and Custom Templates as the Profile type.

Using custom templates, assign the profile a name and apply the following OMA-URI settings:

OMA-URI: `./Device/Vendor/MSFT/Policy/Config/Settings/PageVisibilityList`

Data type: String

For the String value, type showonly: and list each msi-setting you want immediately after the colon. Separate each msi-setting with a semicolon like this:

showonly:bluetooth;camera;about;sound;easeofaccess-audio;windowsupdate-action;workplace-provisioning;sound-devices;apps-volume;privacy-webcam

The screenshot below shows the process using Intune:

Complete the profile by adding any desired scope tags and assign the profile to your designated groups and finish the wizard.

You can find a complete list of ms-settings names on the Microsoft website. 

Conditional Access policies in Microsoft Intune are designed to enhance security by ensuring that only authorized users under specific conditions can access your organization's applications and services. These policies are a critical component of a zero-trust security model, which assumes breach and verifies each request as though it originates from an uncontrolled network. Conditional Access Policies are a potent security mechanism, yet they require careful management to avoid inadvertently locking out individual users including yourself, or even the entire organization.

Let’s say you have all your users and computers contained within Azure Active Directory and you want to create a conditional access policy that restricts access to the Azure AD portal for only Azure administrators or other privileged users that require access to perform their job duties. To create a conditional access policy using the Microsoft Intune Admin Center you navigate to Devices > Conditional Access and create a new policy.

The default action of this policy will be to block access by default to the Azure AD portal. Thus, under “Include” I have selected All users. Note the warning directly underneath this selection that cautions me about locking myself out as the policy will apply to all users, even the person creating the policy and all high privilege administrators.

Thus, it is imperative that I assign groups that will be excluded from the default action. As shown in the screenshot below, I have selected an assembly of users and groups to exclude.

The next step is to select a Target Resource. The target resource refers to the applications, services, or data that the policy will protect. These resources are what the policy conditions apply to, determining how and when users can access them based on specific criteria such as user identity, device compliance, location, and risk level. Target resources can include cloud applications, which in this case is Windows Azure Service Management as shown below.

For this policy, I will not set any conditions, such as location or device platform, because I intend to block access irrespective of these factors. The final step is to specify what action will be granted to the Azure portal. Here I am going to block access for all users except for those specifically excluded from this policy. Since I have yet to exclude my own account or any group that includes my account, Intune is providing a final warning, cautioning that the policy I'm about to implement will prevent me from accessing the Azure portal.

Conditional Access policies are a powerful tool to enforce least privilege access to your critical resources. However, caution is necessary, as a single unintended click could lead to adverse outcomes.