Now, we are 3/4 of the way there to completing our pinnacle series of the Workspace ONE Admin’s Guide to Microsoft Intune. The previous installments are:

• Workspace ONE Admin Guide Part 1: Core
• Workspace ONE Admin Guide Part 2: Profiles, Baselines, Scripts, and Product Provisioning
• Workspace ONE Admin Guide Part 3: Apps

We’ve discussed security a bit already in the first three parts, but we focus on the core security capabilities that truly matter. We will cover:

• Windows Patching
• Security Baselines
• Leveraging Profiles for Security Hardening
• Account Protection
• Conditional Access
• Remediations
• Final Thoughts and Upcoming Webinar!

Windows Patching

With Windows patching, we have focused on leveraging Windows Update for Business in Workspace ONE. We will briefly discuss how WS1 does it today and transition on how we can achieve it in Intune.

Windows Patching in Workspace ONE

Patching is pretty simple in Workspace ONE. We start obviously by building our Windows Update profile, which for most of us replaced patching in SCCM once Microsoft changed how co-existence works:

Last year, VMware introduced new changes in UEM 2306, which I covered in August. Among those changes, they transitioned the Windows Update capabilities to the Intelligent Hub bringing in some advanced capabilities like the Device Updates view:

VMware also made it possible to pause/rollback Feature and Quality Updates, which was a long-requested feature for the platform. Now, let’s discus show Microsoft Intune builds on these concepts.

Windows Patching in Microsoft Intune

As I covered last week in my popular blog article, “Deep Dive into Windows Patching with Microsoft Intune” Microsoft started the journey with Windows Update for Business, which was certainly a good start.

Essentially, Microsoft took Windows Update for Business and elevated it with Windows Autopatch, which shifts right and has Microsoft do the heavy lifting. The capabilities are similar, but Windows Autopatch Groups will automatically slice up users among rings, but they will also deliver patches for Windows drivers, Microsoft 365 Apps, and more.

The requirements for using Autopatch are:

• Windows 10/11 Enterprise E3+
• Entra ID P1 or P2
• Entra Join or Hybrid Join
• Intune-managed Devices
• Co-management requirements
  • Intune cloud-attached
  • Windows Update, Device Config, and Office C2R workloads are Intune-managed

Feel free to check out my video to learn more about these cool Autopatch groups:

Microsoft even delivers some amazing reporting with the Windows Update for Business workbook filling that gap some could be worried about with SCCM or even Workspace ONE Intelligence reporting.

Windows Security Baselines

The concept of security baselines isn’t new. Server teams have been using them for a long time. In more recent years, they have been picking up steam as VMware and Microsoft both deliver them today. First, we will discuss the baseline capabilities that Workspace ONE has been doing today briefly and switch to how Microsoft handles it.

Workspace ONE Windows Baselines

This is mostly a refresher, but without mentioning it we are sort of skipping over security. Baselines as most of you know are a recommended security configuration for something.

In Workspace ONE, we have the Microsoft “Windows Security Baseline” (21H2/22H2) and CIS Level 1 and 2 (21H2/22H2). One nice thing they provide are the ability to add individual settings to the Security Baseline that are outside the scope. In addition, they support a custom GPO backup aka Custom Baseline. The one issue with custom GPO is that it requires lgpo.exe to be deployed, which has created some issues for some people historically. Lgpo.exe is a Microsoft product that helps you manage local group policy.

They also support the ability to create your own baselines, where you search through a variety of policy settings. You can see an example below:

Intune Security Baselines

You will note I didn’t say “Windows” because they offer so much more. You can deploy security baselines inside of Microsoft Intune for the OS, Microsoft Defender for Endpoint (MDE), Edge, Office Apps, and even Windows 365.

The first thing to note is that Microsoft now supports 23H2 baselines, which VMware does not yet. I don’t think that’s a big deal typically, but it’s always good to note.

One really great pro-tip I learned through my journey is not to deploy the Defender and Windows 11 Security Baseline together as they will throw conflicts with each other. Basically, Defender settings will be found in both, which Intune is not a huge fan of.

One last reminder don’t create separate policies for these things to avoid unintended consequences. Leverage the baselines they provide and tweak them to meet your standards.

Leveraging Profiles for Security Hardening

This is a bit of a refresher also, but more about being mindful. We will briefly discuss the various profiles you can leverage to secure your Windows deployment.

Using Workspace ONE Profiles for Windows Security Hardening

In Workspace ONE, you leverage the “Windows (BETA)” profile which shows you the various CSPs that are available. The list is significant, but a few of the ones you might leverage are Firewall, LAPS, Defender, or Health Attestation. Below, is a list of all of the different CSPs that are available now:

You can check out my video on how the new profile capabilities work:

Leveraging Intune Profiles for Endpoint Security

The brilliant thing that Microsoft does (which early on I complained about) is creating an “Endpoint Security” section inside of Intune. This gets you thinking about your security policy and what you might be missing. Most WS1 UEM administrators will probably forget to add things to their device security like LAPS, Attack Surface Rules, etc. without these helpful reminders. The seasoned SCCM admin is probably less of an issue, but it’s really helpful.

Intune breaks out these different areas for people to configure:

• Antivirus
• Disk Encryption
• Firewall
• Endpoint Privilege Management (Out of scope for this, but will cover at a later date)
• EDR
• App Control for Business (will be covered at a later date)
• Attack Surface Reduction (this is just where you configure your attack surface rules)
• Account Protection (we will cover that in the next section)
• Device Compliance (covered in part 2, not that useful here)
• Conditional Access (will be covered later)
• Microsoft Defender for Endpoint

Let’s briefly discuss a few of these areas. Starting with Antivirus.

Antivirus Profiles in Intune

The Antivirus section begins with a nice dashboard showing you any unhealthy endpoints, active malware, and a great summary:

You can create a few policies here:

• Defender Update Controls (lets you control the gradual release of defender updates similar to Windows Update rings)
• AV Exclusions
• AV Policy
• Windows Security Experience (customize the Windows Defender Security Center)

Admittedly, I am using a custom policy for Defender settings in a single profile to simplify management of MDE, but this portal makes life really easy by showing you the things you should consider configuring. I will admit early on in my Intune journey I realized I was missing stuff in WS1 because I just didn’t realize. The way they lay it out does make life easier and keeps people aware.

Firewall Profiles in Intune

The Firewall section is similar to Antivirus with its dashboard showing devices with Firewall shut off:

Your configuration options here are:

• Windows Firewall Policy
• Windows Firewall Rules
• Windows Hyper-V Firewall Rules (for VMs enrolled in Intune)

These items I am handling with my baseline, but it gives you some great options here.

Endpoint Detection and Response Profiles in Intune

EDR section is more of the same. They focus here on the onboarding status of devices:

This is by far the best, because you can just configure it to automatically pull the Defender configuration from MDE directly and build the most beautiful enrollment process for MDE that exists. (I had a ton of issues with onboarding Workspace ONE and this is just a life saver).

Below are the EDR settings you can set inside of Intune, which sets the configure of MDE overall:

Account Protection

Account Protection covers a few main areas like rotating passwords, Windows Hello, and even securing local group membership. We can do that in Workspace ONE, but it can be a little complicated. Let’s cover how we can do this today in WS1 and Intune.

Account Protection in Workspace ONE UEM

I covered most of this in a blog post in December about securing local admins in Workspace ONE UEM. Basically, we leverage a script and the new profiles in WS1. First the code, which creates the user and adds the user to the group if necessary:

# Define the user account details
$username = "MyAdminUsername"
$password = ConvertTo-SecureString "MyAdminUsernamePassword" -AsPlainText -Force
$description = "$username user account"

# Check if the user already exists
$userExists = Get-LocalUser -Name $username -ErrorAction SilentlyContinue
if (-not $userExists) {
    # Create the new local user
    New-LocalUser -Name $username -Password $password -Description $description -AccountNeverExpires -PasswordNeverExpires
    Write-Host "User $username created."

    # Add the user to the Administrators group
    Add-LocalGroupMember -Group "Administrators" -Member $username
    Write-Host "User $username added to Administrators group."
} else {
    Write-Host "User $username already exists."

    # Check if the user is a part of the Administrators group
    $isAdminMember = $false
    $administrators = Get-LocalGroupMember -Group "Administrators"
    foreach ($member in $administrators) {
        if ($member.Name -eq "localhost\$username" -or $member.Name -eq "$env:COMPUTERNAME\$username") {
            $isAdminMember = $true
            break
        }
    }

    # Add the user to the Administrators group if not a member
    if (-not $isAdminMember) {
        Add-LocalGroupMember -Group "Administrators" -Member $username
        Write-Host "User $username added to Administrators group."
    } else {
        Write-Host "User $username is already a member of the Administrators group."
    }
}

For LAPS, we can now configure the LAPS settings with the new profile creation wizard in Workspace ONE:

For securing the local administrator group, you can use this XML as it is not well supported in the new profile interface in WS1. They DO support it, but it’s probably easier for most to work with the XML import given how they have it currently. I don’t think this is the easiest to work with:

The code that Grischa wrote works well, to replace local administrators with only the admins you require:

<Replace>
  <CmdID>c0fdee89-572c-4cd9-ab75-dbdd1cffce32</CmdID>
  <Item>
    <Target>
        <LocURI>./Device/Vendor/MSFT/Policy/Config/RestrictedGroups/ConfigureGroupMembership</LocURI>
      </Target>
    <Meta>
      <Format xmlns="syncml:metinf">chr</Format>
      <Type>text/plain</Type>
    </Meta>
    <Data><![CDATA[<groupmembership>     <accessgroup desc = "Administrators">    <member name = "Administrator" />      <member name = "mmworks\RestrictedGroup" />         <member name = "mmworks\domain admins" />    <member name = "mmworks\admernst" />  </accessgroup> </groupmembership>]]]]></Data>
  </Item>
</Replace>

One other part on Account Protection are Windows Hello profiles known as “Passport for Work” as seen below:

Account Protection in Microsoft Intune

This is another thing I covered in depth recently here.

Basically, we create a profile to build the local admin account:

You can check out a few videos below on deploying LAPS and locking down the groups, which is super easy to do:

The last part of account protection is Windows Hello, which Microsoft makes it super easy to deploy:

Windows Automated Remediations

With automated remediations, it’s pretty easy.

On Workspace ONE, today you might use Freestyle Orchestrator. That delivers IFTTT where we say, “check for something” and if true then do something. We run things like check for a version of Dell Command Update and update it if its old. We might also do something like if this version of Office is insecure, execute a script to update it.

The logic of this can be seen below:

We do also have Workspace ONE Intelligence, which delivers tons of automations for creating tickets, sending alerts, and tying various systems together to deliver a well-integrated experience. One of my favorite things was incorporation of CVEs and scores into Workspace ONE to automatically remediate various issues:

Intune Automated Remediations

With Intune, they do have automated remediations. See this example below on restarting the Office C2R service:

Basically, we have a detection script:

#=============================================================================================================================
#
# Script Name:     DetectClickToRunServicecState.ps1
# Description:     Purpose of this script is to detect if Office 16 installed and further if "Click to Run Service" is running
# Notes:           No variable substitution should be necessary
#
#=============================================================================================================================

# Define Variables
$curSvcStat,$svcCTRSvc,$errMsg = "","",""

# Main script
   
   
If (-not (Test-Path -Path 'hklm:\Software\Microsoft\Office\16.0')){
    Write-Host "Office 16.0 (or greater) not present on this machine"
	exit 0   
} 

Try{        
    $svcCTRSvc = Get-Service "ClickToRunSvc"
    $curSvcStat = $svcCTRSvc.Status
}

Catch{    
    $errMsg = $_.Exception.Message
    Write-Error $errMsg
    exit 1
}

If ($curSvcStat -eq "Running"){
    Write-Output $curSvcStat
    exit 0                        
}
Else{
    If($curSvcStat -eq "Stopped"){
        Write-Output $curSvcStat
        exit 1     
    }
    Else{
        Write-Error "Error: " + $errMsg
        exit 1
    }
}

If that evaluates true, it will do this:

#=============================================================================================================================
#
# Script Name:     RemediateClickToRunServiceState.ps1
# Description:     Purpose of this script is to start the "Click to Run Service" and change its startup type to Automatic
#       Notes:     No variable substitution needed             
#
#=============================================================================================================================

# Define Variables
$svcCur = "ClickToRunSvc"
$curSvcStat,$svcCTRSvc,$errMsg = "","",""
$ctr = 0

# First, let's make sure nothing has changed since detection and service exists and is stopped
Try{        
    $svcCTRSvc = Get-Service $svcCur
    $curSvcStat = $svcCTRSvc.Status
    }

Catch{    
    $errMsg = $_.Exception.Message
    Write-Error $errMsg
    Exit 1
    }
        
# If the service got started between detection and now (nested if) then return
# If the service got uninstalled or corrupted between detection and now (else) then return the "Error: " + the error
If ($curSvcStat -ne "Stopped"){
    If ($curSvcStat -eq "Running"){
        Write-Output "Running"
        Exit 0
    }
    Else{
        Write-Error $errMsg
        Exit 1
    }
}

# Okay, the service should be there and be stopped, we'll change the startup type and get it running
Try{        
    Set-Service $svcCur -StartupType Automatic
    Start-Service $svcCur
    $svcCTRSvc = Get-Service $svcCur
    $curSvcStat = $svcCTRSvc.Status
        While ($curSvcStat -eq "Stopped"){
            Start-Sleep -Seconds 5
            $ctr++
            if($ctr -eq 12){
                Write-Output "Service could not be started after 60 seconds"
                Exit 1
            }
        }
    }

Catch{    
    $errMsg = $_.Exception.Message
    Write-Error $errMsg
    Exit 1
    }

This is new technology but is definitely an interesting idea. We will be evaluating it on a daily basis, but I think there is a ton of potential. Alternatively, I am currently using  ControlUp Edge DX, which powers my automation journey today.

Conditional Access for Windows Devices

Conditional Access is an interesting one, but it’s essential when discussing security for Windows devices. We will primarily discuss Intune on this section as most companies handle conditional access at the IDP level, like Entra, Okta, or Ping. Workspace ONE does integrate well there by passing compliance to Intune (but not for Windows devices).

Let’s check out conditional access in Intune/Entra a bit deeper. I wrote about conditional access extensively over the last few years like my article here. We even discuss Entra deeper in my multi-part series of Entra vs Okta here.

If we keep it simple, the policies come down to signals, decisions, and applied policies.

Let’s start with signals. Our signals are users and groups, devices, apps, locations, etc. Basically, these items:

One new entry to this are authentication flows. An auth flow is to deal with device code attacks, which have been making a comeback as of late. They focus on a few areas:

• Device Code Flow (trying to sign into devices that lack local input like digital signage), which is recommended to block everywhere possible.
• Authentication Transfer (very similar to Apple’s Handoff, passing authentication state from one device to another e.g. passing authenticated state from desktop to mobile devices).

You can now create policies to block these attacks as featured here.

Signals will use a decision like block or grant access, based on specific capabilities like:

In addition, you have session controls now to combine with the grant access enforcements:

Simply, your app policies run through conditional access to tell a story:

• A group of users accessing Salesforce from Windows or MacOS with machine names that start with CloudPC in the United States require phishing resistant MFA on a compliant device and must re-authenticate every 60 minutes.
• A specific user accessing Microsoft Outlook using modern authentication is granted access if it is protected with an app protection policy.

Final Thoughts

Well, we have finally come to the end of this 4-part series. It has been a long journey with some interesting content. People have enjoyed it which makes it ALL worth it. So where do we go from here? This is the roadmap:

• In late May, we will be hosting an AMA webinar where we open the floor for people to ask questions, converse, and discuss the entire series. Always open to feedback and anything people want to know who might be considering this journey.
• We will have an API article coming out as a P.S. article on this series comparing using the API in Workspace ONE vs. the API in Intune.

I hope everyone enjoyed this. I am looking forward to my first MMS in two weeks and would love to discuss any of these topics more there for anyone who has questions or needs help.