This is certainly a topic I have written about in the past, but revisiting how to manually update Group Policy is worthwhile, given the ongoing confusion surrounding the topic. The choice between using `gpupdate` alone or with the `/force` option is a common query.

First, let's recap the automatic Group Policy update mechanisms:

1. Computer-side Group Policy Settings automatically refresh upon the restart of a domain member computer.

2. User-side Group Policy Settings refresh when a user logs onto a domain member computer.

3. By default, Group Policy Settings undergo an automatic refresh every 90 minutes, with a random offset of up to 30 minutes to prevent system overload against the DCs, so they dont fall over and di.=e.

However, there are situations where waiting for an automatic refresh or disrupting a user's session with a logoff or reboot is impractical, especially when immediate action is required. That is when the gupdate command comes into play using either command prompt or PowerShell.

While `gpupdate /force` can be used in any situation, making it a go-to for ensuring all policies are applied, it's not always the most efficient method. Let's explore the nuances between `gpupdate` and `gpupdate /force` to understand when each should be used for optimal Group Policy management.

GPUpdate by Itself

This command efficiently updates Group Policy settings for either a computer or user, applying only the changes made since the last refresh without reapplying unchanged settings of other policies. This command is typically used to apply changes made to a single policy. It is a less intrusive option, often employed for routine Group Policy maintenance. Serving as the go-to command for most needs, it ensures that recent policy adjustments are implemented swiftly and with minimal disruption. It's especially useful for testing or when needing to apply a newly created or revised policy to a specific computer or user session.

GPUpdate /Force
This command forces a refresh of all Group Policy settings, regardless of whether any have changed or not. It re-applies all settings, which can be useful for solving issues related to policy application or when a computer or user receives new policies for the first time. However, because it reapplies all policies, it can be more disruptive, potentially causing logon scripts to run again and requiring a logoff or restart for some policies to reapply effectively. If nothing else, it takes longer to enact and leaves you sitting idle. Use `gpupdate /force` when troubleshooting policy application problems or when you need to ensure that all policies apply again, not just the recently changed ones.

How many times has this happened to you? You go about creating a new configuration profile using the Microsoft Intune Admin Center. You complete the setting creation process and now want to assign the profile to the designated groups. But before that, the wizard prompts you about Scope Tags as shown in the screenshot below.

Like other Intune administrators, you might often bypass scope tags by clicking Next, occasionally wondering about their purpose. Scope tags are vital for partitioning and controlling access to Intune resources, such as profiles, apps, and policies, to enable delegated administration. They allow for the classification of resources by department, function, or location, facilitating more efficient resource organization. This ensures administrators can readily manage resources relevant to their specific organizational segments. Although granular access control through scope tags might seem excessive for small to medium-sized organizations, it's incredibly beneficial for larger ones, enhancing security and compliance by restricting administrators' access only to their designated resources. This reduces the likelihood of unauthorized access or alterations to crucial settings.

Create Your Scope Tags

Start by generating your scope tags, envisioning them as segmentation tools that define which admins have access. Imagine a national company with offices across various regions. For this example, you'll create scope tags specifically for the administrative team stationed in this office that is responsible for managing the profiles and policies exclusive to the East Coast office. To configure this arrangement, you need to:

• Create a member group called East Coast Admins which will contain the all admins of the east coast office that will have permission to manage policies and profiles for users and devices within the allotted scope.
• Create a scope tag that will contain the east coast admin member group.

In this case I already have my east coast admin group. To create the scope tag using the Microsoft Intune Admin Center navigate to Tenant Administration > Roles > Scope Tags and create a scope tag and name it as shown below.

The next step is to add member group to the scope tag as shown here:

Next, finish the wizard to create your scope tag. With the scope tag established, you can apply it as necessary. The final step involves creating a configuration profile. When you reach the Scope Tag section this time, add the scope tag you've just created.

Then I will assign the device group that configuration profile will be applied to:

After finishing the wizard, I've set up a configuration profile targeted at East Coast computer devices. This allows East Coast admins to manage these devices specifically, utilizing the scope tag for focused oversight.

With Windows 10, Group Policy administrators could configure whether Windows Defender receives its updates through standard Windows Update channels or alternative sources such as WSUS (Windows Server Update Services) or manually specified update locations. as shown below. You could set whether Windows Defender should receive updates through standard Windows Update channels, or through alternative means like WSUS (Windows Server Update Services) or manually specified sources.

In Windows 11, Group Policy administrators are now provided with the capability to select specific channels for acquiring virus signatures for both daily and monthly updates. This new feature offers enhanced control over how and from where these crucial security updates are sourced, aligning with the organization's specific requirements and IT infrastructure. The process is quite similar to the process of assigning devices to channels for Windows Update for Business. The new settings reside in the root directory of Microsoft Defender Antivirus as shown here.

First let’s talk about the different types of updates.

1. Daily Security Intelligence Updates are frequent updates that provide the latest definitions for viruses, spyware, and other malware. These are essential for Microsoft Defender to recognize and protect against newly emerging threats once they have been identified.

2. Monthly Engine Updates enhance the capabilities of Microsoft Defender’s threat detection such as scanning functionality and detection algorithms. In addition to improving threat identification and remediation, these updates help optimize the Defender’s performance and resource usage.

3. Monthly Platform Updates introduce new functionality, features, and user interface modifications. They may also address identified bugs or vulnerabilities within the software itself.

Now, let’s talk about the various channels available.

• Beta Channel: Devices assigned to it will be the first to receive new updates. These devices should be used for testing environments. Devices subscribed to the Windows Insider program are assigned to this channel by default.
• Current Channel (Preview): Devices set to this channel will be offered updates earliest during the monthly gradual release cycle. This is recommended for devices in pre-production or validation environments.
• Current Channel (Broad): Devices will be offered updates only after the gradual release cycle completes. Most of the devices in your production environment should be assigned here.
• Current Channel (Staged): Devices assigned here will get updates later during the gradual release cycle but prior to the release to the majority of devices. Microsoft states that no more than 10% of your devices should be assigned to this channel.
• Critical-Time delay: Devices will be offered updates with a 48-hour delay. This is suggested for devices in critical environments only.

The channel selection process for Monthly Engine and Monthly Platform updates is the same as shown in the screenshot below.

Daily Security Intelligence Updates have fewer channel options as they are much more pertinent.

Convertible 2-in-1 laptops, which seamlessly switch between desktop and tablet modes, offer great versatility for users requiring such adaptability. In tablet mode, these devices automatically display a touch keyboard when the physical keyboard is inaccessible. However, there are instances where activating the touch keyboard in desktop mode is beneficial. Some examples might include:

• In educational settings or other situations where a keyboard configured for a second language is needed.
• For individuals with mobility or dexterity challenges, a touch-enabled keyboard can be more user-friendly than a traditional keyboard.
• At public kiosks or information stands, where a physical keyboard may be impractical or less hygienic.
• - Certain job roles may find a touch-enabled device more convenient, eliminating the need to alternate between a touch interface and a physical keyboard.

Although the touch keyboard is available in desktop mode by default, there are scenarios where you might prefer it to appear automatically for user convenience. In certain cases, access to the touch keyboard might be restricted due to default policy settings. To enable automatic appearance of the touch keyboard on specific Windows machines using the Microsoft Intune admin center navigate to Devices > Configuration Profiles and create a new policy. Choose Windows 10 and later as the platform and Settings catalog as the Profile type. Name the policy and type “text input” into the settings picker. Then select “Enable Touch Keyboard Auto Invoke in Desktop Mode” as shown below.

Complete the setup wizard by assigning the policy to your designated groups.

In my previous blog I showed how to setup LAPS for Azure AD. With everything configured correctly, now it is time to retrieve the password for the local administrator account that our policy addresses. To retrieve the password, go to your Azure portal and navigate to Devices > All Devices > Local administrator password recovery (Preview) and find the selected device. Click on Show local administrator password beside the listed device. Navigate to the right and either show the password or click the copy button as shown in the screenshot below.

Armed with the specified password, you can now log into the device using the local administrator credentials and execute tasks that necessitate local admin privileges.

In an earlier blog I talked about Windows LAPS (LAPS2) that was released in April 2023. It was designed to replace the original version of LAPS, now known as Legacy LAPS. We explored its integration in an on-prem AD setting across multiple articles. Today, let's pivot to applying it within the Azure AD framework.

Windows LAPS is designed to help bolster security by minimizing the risk associated with compromised local administrator passwords that could grant unwarranted access to networked Windows devices. A prevalent scenario in many enterprises is the use of a uniform local admin account across all Windows endpoints, characterized by an identical username and password. This poses a significant security gap because if a single account is breached, a threat actor could potentially gain administrative access to every interconnected device. In the case of a school district, once one student gets a hold of the local admin credentials, it doesn’t take long until the entire student body has admin rights, wreaking havoc on the machines.

Windows LAPS ensures each local admin account is assigned a unique password. For instance, if you oversee multiple Windows devices all having a local admin account labeled 'Admin1', Windows LAPS allows you to set a unique password for each of these accounts. Additionally, these passwords come with a specified expiration period, after which a new randomized password is created. While my earlier blog series delved into setting up LAPS via Group Policy, in this piece, we'll explore its configuration using Intune.

PRE-REQUISITES FOR WINDOWS LAPS AZURE AD

The prerequisites for Windows LAPS are few. There is nothing to install because Intune policies are used to configure the LAPS CSP already on the devices. Here is what you need:

• An Intune license
• All computers need to be on Windows 10 or Windows 11 with the April 2023 Cumulative Update installed
• Requires one of the following roles in Azure AD: Global Administrator, Cloud Device Administrator, or Intune Administrator.

Because Azure is cloud based, you can access Windows LAPS from anywhere and Intune’s scalability allows you to easily manage a great many systems. It is important to remember one downside and that is the dependency on the internet. If your internet service is down and you don’t have an alternative means to reach Azure, you will have no way to retrieve the LAPS password. That being said, let’s get to configuring Windows LAPS for Azure AD.

Configuring LAPS for Azure AD

Before you create an Intune policy you must first access your Azure portal (portal.azure.com) and enable LAPS. Navigate to Devices > Device Settings and scroll down. Then turn on the “Enable Azure AD Local Administrator Password Solution” as shown below.

Once that is completed, you can move on to Intune. Using the Microsoft Intune admin center navigate to Endpoint Security > Account protection and click Create Policy. Choose “Windows 10 and later” as the Platform and “Local admin password solution Windows LAPS” as shown in the screenshot below.

After naming the policy it is time to configure settings as shown below. Of course, in this instance we will choose Azure AD only as the Backup Directory.

For the Administrator Account Name, I chose a custom account called fabadmin. If you are using Windows LAPS to manage any custom local administrator account, you must enter the name of that account here. You can leave this field blank if you are configuring LAPS for the built-in administrator, even if you have changed the name from its default name.  

For Password Complexity there are four options:

• Large letters
• Large letters + small letters
• Large letters + small letters + numbers
• Large letters + small letters + numbers + special characters

Note that four options are the default if you don’t select an option.

Post Authentication Actions is used to specify the actions to take upon expiration of the configured grace period which is 12 days in this instance. There are three options here.

• Reset password: upon expiry of the grace period, the managed account password will be reset.
• Reset the password and logoff the managed account: upon expiry of the grace period, the managed account password will be reset and any interactive logon sessions using the managed account will be terminated. (Default behavior)
• Reset the password and reboot: upon expiry of the grace period, the managed account password will be reset, and the managed device will be immediately rebooted.
• Not configured.

If no selection is made, the setting will default to the logoff option.

Post Authentication Reset Delay Sets the delay in hours before the previous actions above is executed. The default is 24 hours which is also the maximum.

With your settings configured, assign relevant scopes, and deploy the rule to the Azure Ad group you want to manage with this policy. In my next blog I will talk about how to retrieve the password from Azure and how to audit LAPS retrieval.

Group Policy and Intune both offer multiple ways to hide various components of the Windows operating system. One of these is the "Settings Page Visibility" setting that is specifically designed for managing the visibility of individual pages within the Windows Settings app introduced in Windows 10. This is distinct from the practice of hiding individual applets within the traditional Control Panel. By controlling visibility, you can streamline the user experience by ensuring they only see the settings they need, thus minimizing potential confusion or mistakes.

Note that the "Settings Page Visibility" policy only determines whether a page is visible or hidden to users. If you hide a settings page, users cannot see or access it, but this does not deactivate or override the actual functionalities or policies that might be set elsewhere.

I will show you how to configure the "Settings Page Visibility" policy in both Group Policy and Intune.

Group Policy

Create a GPO and go to Computer Configuration > Administrative Templates > Control Panel > Settings Page Visibility. You will then enable the policy and configure the settings as shown in the screenshot below.

You have two options for this setting.

• Use the hide: command to hide specific pages.
• Use the showonly: command to show only specific pages and hide all others.

You then follow either command by the Uniform Resource Identifier (URI) of the resource you want to apply the command to. For instance, if you want to hide the Window game bar you would type the following:

Hide: ms-settings:gaming-gamebar

If you want to hide additional settings, simply separate each URI by a semicolon. For instance, if you want to hide the Windows gamebar as well as advanced network and internet settings, the command will look as follows:

Hide: ms-settings:gaming-gamebar;ms-settings:network-advancedsettings

Let’s use an example for the showonly: command.

showonly:display;bluetooth

You can add as many URIs as you need to the policy. Once completed, assign the GPO to your designated groups and you are ready to deploy. You can refer here for a list of URIs.

Intune

To configure the "Settings Page Visibility" equivalent in Intune go to your Microsoft Intune admin center portal and navigate to Devices > Configuration profiles.

• Create a new profile and choose “Windows 10 and later” as the Platform and choose “Settings catalog” as the Profile type.
• Name the profile and click Add settings.
• In the settings picker type “visibility”
• Choose between the 2 Page Visibility List options

In this example I will choose Page Visibility List because I want to apply the profile to users as shown below.

Use the same command structure as in Group Policy.

Then assign any scope tags, your designated groups and complete the creation process.  

LAPS offers an effective method to limit local administrative privileges by generating a unique password for each Windows computer in your enterprise. However, for enhanced security and compliance, it's advisable to monitor who is accessing the passwords for specific machines. For Azure-joined devices go to your Azure portal and navigate to Devices > Audit Logs and then search for “Recover device local administrator password” as shown in the example below.

You can then click on the event to view more information as shown here.

This system effectively restricts access to clear-text passwords, ensuring only individuals with specific administrative roles, like Global Administrators, Cloud Device Administrators, and Intune Administrators, can access them.

Microsoft Defender for Identity (formerly known as Azure Advanced Threat Protection or Azure ATP) is a cloud-based security service offered by Microsoft to help protect your on-prem Active Directory environment. It leverages artificial intelligence, network, and behavioral analytics to detect abnormal behavior and activities that could be potentially threatening.  It can then provide security alerts and actionable insights to protect against cyber threats targeting identities and credentials. Some of its capabilities include the following:

• Analyze user behaviors and activities with learning-driven metrics
• Safeguard user identities and credentials within Active Directory
• Identify and investigate abnormal user behaviors and advanced threat patterns
• Provide incident details on a streamlined timeline for efficient resolution.

Requirements for Microsoft Defender for Identity

To use Microsoft Defender for Identity you will need a license for Enterprise Mobility + Security E5 (EMS E5/A5), Microsoft 365 E5 (M365 E5/A5/G5) or Microsoft 365 E5/A5/G5. Standalone Defender for Identity licenses are also available. You will also need an Azure AD tenant with at least one global/security administrator with a Directory Service account with read access to all objects in the monitored domains.

In this article I am only going to cover how to configure your on-prem Group Policy and AD environment for audit events. You can refer to this installation guide as to how to install Microsoft Defender for Identity on Active Directory or Active Directory Federation Services (AD FS) servers.

Configuring Group Policy

For Microsoft Defender for Identity to fully function, you must enable and configure certain audit events in Group Policy. Microsoft Defender for Identity then uses this audit data to detect suspicious activities and security vulnerabilities in real-time. To configure the audit events, you need use Group Policy Management Editor to either create a new GPO and link it to the Domain Controllers OU or edit and configure the Default Domain Controllers Policy. In the example below I am choosing to modify the existing policy.

Start by going navigating to Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies. Start with the Account Logon policy and select “Audit Credential Validation.” Configure this and all the following audit events for both Success and Failure events as shown in the screenshot below. This will trigger Event ID 4776 in the security logs in Event Viewer.

Next will be the Account Management audit policy where you will enable the following subcategories for both Success and Failure.

Then move to the DS Access audit policy and enable “Audit Directory Service Access” for Event ID 4662 and then enable “Audit Directory Service Changes” for Event ID 5136. Wrap things up by moving on to the System audit policy and enable “Audit Directory Service Changes” audit for Event ID 5136.

Configure Object Auditing

Note that to collect 4662 events you will need to configure object auditing on the user, group, and computer objects. This is performed using Active Directory Users and Computers. Make sure you select the View menu and select Advanced Features as shown below.

Then right click on your domain, select Advanced Features > go to the Security Tab and click Advanced as shown here.

In Advanced Security Settings> choose the Auditing tab and Select Add.

Select Everyone as the principal. Upon returning to the Auditing Entry, configure these settings:

Choose "Success" for the 'Type'.

For 'Applies to', opt for 'Descendant User objects'.

In the Permissions section, navigate downwards and click the 'Clear all' button.

Now scroll up and choose "Full Control," which will auto-select all permissions. Next, deselect "List contents," "Read all properties," and "Read permissions." Click OK. This action sets the Properties to "Write" mode. As a result, any pertinent changes to the directory services will register as 4662 events. The final configuration is shown below.

Now complete the same steps but select the following object types for Applies to:

• • Descendant Group Objects
  • Descendant Computer Objects
  • Descendant msDS-GroupManagedServiceAccount Objects
  • Descendant msDS-ManagedServiceAccount Objects

Enable auditing on an ADFS object

In the steps above we configured auditing for the entire Domain. Some detections only require auditing in specific Active Directory objects however. Return to the Active Directory Users and Computers console, and choose the domain you want to enable the logs on.

• Navigate to Program Data > Microsoft > ADFS.
• Right-click on ADFS and choose Properties.
• Navigate to the Security tab and click on Advanced.
• Within Advanced Security Settings, go to the Auditing tab and click Add.
• Click on 'Select a principal'.
• In the field labeled 'Enter the object name to select', input 'Everyone'. Click 'Check Names', and then click OK.
• You'll be taken back to the Auditing Entry. Configure the following settings:
• For 'Type', choose 'All'.
• For 'Applies to', pick 'This object and all descendant objects'.
• In the Permissions section, first click 'Clear all'. Then select 'Read all properties' and 'Write all properties'.

Click OK out of all windows.

Enable auditing on the Configuration container

We just have one more step to go and here you will need to launch the ADSI Edit consol which you can access by typine ADSIEdit.msc in the Run Command.

• From the Action menu, choose Connect to.
• In the Connection Settings pop-up, from the 'Select a well known Naming Context' dropdown, choose Configuration, and then click OK.
• Navigate to the Configuration container and expand it. Inside, you'll find the Configuration node, which starts with "CN=Configuration,DC=..."
• Right-click on this Configuration node and choose Properties as shown below.

• Now navigate to the Security tab and click "Advanced."
• Once inside Advanced Security Settings, opt for the Auditing tab and click "Add."
• Click on "Select a principal."
• In the ensuing field, input "Everyone", then click "Check Names", followed by "OK."

Now, back in the Auditing Entry, adjust these settings:

• Set 'Type' to 'All'.
• Under 'Applies to', choose 'This object and all descendant objects'.
• Within Permissions, first hit 'Clear all', then check 'Write all properties' as shown in the example below.

Click OK out of all windows and you are done.

Most organizations have more than one wireless SSID for their users. For example, a school might designate separate SSIDs for staff and students. Similarly, a business could have distinct SSIDs for regular employees and those with privileged access. These SSIDs are then paired with specific access policies, managed either through the native wireless manager or external tools like SD-WAN solutions. In our school scenario, the student's SSID might provide direct internet access, whereas the staff's SSID offers connectivity to internal resources like printers. For IT teams or personnel requiring complete network access, there's typically an unrestricted SSID in place.

With Intune, you can designate a specific wireless SSID for users. Additionally, Intune facilitates the use of WPA2-Personal wireless configurations, automatically supplying computers with the pre-shared key. This eliminates the need for users to manually enter it and allows for the implementation of intricate passwords of up to 64 characters, bolstering security. With this setup, you can also keep SSIDs hidden so that the visible SSID on your premises is for the guest network.

To configure wireless policies using the Microsoft Intune Admin Center go to Devices > Configuration profiles and click Create Profile. Select Windows 10 and later as your Platform and WiFi Templates as your Profile. Name your profile and then configure the settings as shown below. Here I have enabled “Connect automatically when in range” and “Connect to this network even when it is not broadcasting its SSID.”

Once configured, assign the profile to your designated groups. When onboarding new computers using Autopilot or a package you will need to manually connect the Windows device to a wireless SSID. Once Intune delivers WiFi profile, the computer will possess the necessary SSID details to connect automatically to an assigned SSID depending on the user that signs in.