It’s a Cloud, Cloud, Cloud, Cloud, Cloud, Cloud world. Except actually most of your stuff is still likely mostly on-prem, or acts that way. Take Windows 10 for instance. Windows 10 has events in the event logs, and maybe you already know about on-prem Event Forwarding.

Tip: If you want to learn more about on-prem Event Forwarding, you can see my Walkthrough of that here video and text.

But how do we take on-prem events from Windows 10 (or Windows Server) and get the up to the cloud for later analysis? If you have 24, 250, or 25,000 domain joined (or even NON-domain joined) machines, say with Windows Intune or PolicyPak Cloud… how can you do the equivalent of event forwarding to some central place?

That is the job of Azure Log Analytics. I’m going to call it “LA” for short.

LA had an original name, OMS which stood for Operations Management Suite, but as near as I can tell, that’s over. But its good to know LA’s original name, because you’ll see OMS pop up from time to time in the walkthrough, docs, and software. Additionally, it’s also good to know that what you’ll see here is build upon the original System Center Microsoft Operations Manager (SCOM); but I won’t be using that function.

The official documentation for LA can be found here; but I had a few stumbles. Some tips o’ the hat to Travis Roberts’ video and blog which also helped give me a leg up. The blog is here and the helpful video series on Azure Log Analytics (though a little old now because of the name and UI changes) can be found at: https://www.youtube.com/watch?v=6hgvjgPBNzE&list=PLnWpsLZNgHzVXXyN9a0jm9xNNDrikHf8I

My goal in researching this project was to give some PolicyPak MDM Customers a quick guide to research interesting events that PolicyPak automatically logs to its own event log. But in this guide, I’m also going to show you how to collect some standard and also some extra event logs.

To get started you need a Log Workspace. This is basically a security block between this collection of logs, and say another collection of logs. Each Log Workspace has a GUID based Workspace ID and two keys (Primary and Secondary.) You’ll use these to send, say, YOUR Windows 10 machines’ event logs to your workspace. And the other Azure admins … you know, those SQL server people or Exchange or whatever … they’ll send their event logs to their workspaces.

To get started use the big search thingie to find “Log Analytics workspaces” like what’s seen here.

Then, there’s a little Wizard (not shown) to help you get started. Basically it’s asking you for names and which Azure region you want to keep the data in. Then after it gets going you’ll see “Your deployment is underway” like what’s seen here.

Then you should be thrown into the Advanced settings like what’s seen here. If not, find the Workspace you just created and click Advanced in the left-side menu. It should get you to this place. Note then the “WORKSPACE ID” and “PRIMARY KEY” like what’s seen here. Hang on to those, you’ll need these in a bit. Then also download the Windows Agent 64-bit or 32-bit to get started for your example machines.

In this example, we’ll be installing the LA Agent by hand on a test machine. In real life you could use, say Windows Intune to deploy it with command line options to just chuck in your Workspace ID and Primary Keys and do the whole thing silently and automatically.

Once you have the download, get it over to your test machine. Machine can be real or virtual. Note that you shouldn’t do this (nor do you need to) for WVD virtual machines. Those have a magical connector to accept event logs to LA; and you shouldn’t need to use this method. (Docs: https://docs.microsoft.com/en-us/azure/virtual-desktop/diagnostics-log-analytics and a blog https://www.mdmandgpanswers.com/blogs/view-blog/windows-10-and-server-event-logs-to-azure-log-analytics-walkthru)

Then, Up, Up and away. Launch the agent.. which requires admin rights. (Or, pro tip: Use PolicyPak Scripts to install it automatically where the script is elevated. https://kb.policypak.com/kb/article/901-policypak-scripts-deploy-software-via-vpn-or-with-policypak-cloud/ )

You’ll need to select “Connect the agent to Azure Log Analytics (OMS)” like what’s seen here.

Then, it’s time to chuck in your Workspace ID and Workspace Key. And you’ll likely keep the default of Azure Cloud: Azure Commercial. Pull the pulldown if you have something unusual to select here.

Yes, you want to check for updates when MS Update kicks in….

And.. you’re basically done.

Now let’s make sure we’re talking in both directions. The Microsoft Monitoring Agent is found in Control Panel… which is a weird place, but, hey… that’s okay.

Then click the Azure Log Analytics (OMS) tab and … see you’re talking outbound.

Back in Azure, in the Advanced Settings page, the zero should be one !

Now it’s time to add in the actual event logs you want to capture. Note that the more you capture, the more you pay. Strictly speaking for the PolicyPak customer I made this blog entry for, he only needed to capture the PolicyPak log (which I do last.) But just for completeness and testing, I’ll capture some more too, since you might not have the PolicyPak Log. (And, why don’t you!? Come on over and check out PolicyPak for Pete’s sake. Really, your sake to be honest.)

So just type Application then +. Then System and + and bingo. Those are “well known” logs which LA knows about and pre-populates this list. But PolicyPak? Not as common.. (Yet !) Therefore you could take a guess that our event logs are named PolicyPak (they are…). But how would you know?

The trick is to find the log you want to capture in Windows, and go to its properties and get its Full Name like what’s seen here. Yeah, this one was easy.

But some are harder. I also wanted to capture the MDM event log which has a goofy and weird name. To get it, I went into an Event inside that log and captured its name microsoft-windows-devicemanagement-enterprise-diagnostics-provider/Operational and its brother microsoft-windows-devicemanagement-enterprise-diagnostics-provider/admin.

You can see that second log here…

Once I pasted in all the logs and added them, I clicked Save and got this !

Data.. data? Do we have data ? Click on Logs and close the sample queries. Let’s just see what have. All of it (which shouldn’t be much.)

In the top box, type
SEARCH *
Then click Run. Bingo.. out should pop all the events that have been captured. You can change the Display Time to make sure that you’re getting the right events, right now.

It took a little while for the non-well-known logs to show up. But maybe it will work faster for you than for me. If you want to give it a shot and try your non-well-known logs, like this, give it a go.
Event | where Eventlog == "PolicyPak"
Then click Run again.
Pow! Here come your logs.

Then I can also dig into an event, and … hey look ! EastSalesUser1 ran Procmon, and PolicyPak did the elevation ! Amazeballs !

That’s it. Well, that’s basics anyway.

Remember this blog is a simple walkthrough / getting started. This isn’t “Magic Tricks with Windows Analytics.” But if I had this guide, I would have been up and running about 10x faster. So I hope this helps you out and shows how you can take on-prem or “Always on the go” Windows 10 machines and record their logs, then sort thru them for actionable items and trends.

There were two big news items this week in GP-land:

1. The Windows "May 2020 Release" for ADMX templates is out.  You can get them here. Martin Briklmann on gHacks.Net already did a breakdown of what's new in the ADMX templates, so I don't have to. That review / overview is here. Nice job.

2. A research team uncovered a flaw in GPPrefs CSE User Based items.The basic gist is that GPPrefs User Side items (were) storing user policies in a user-writable %localappdata%\Microsoft\Group Policy\History directory when Remove this Item when it is no longer applied option is enabled. When GPupdate is called, the contents are read. If "evil" contents are present, the GPupdate process will perform the processing of those evil contents. As such, Microsoft fixed this in CVE-2020-1317. More reading about it and the direct download links to the patches can be found here.

This isn't an underlying problem in GP "the engine" itself; but rather GPPrefs and then specifically the user-side policies, and specifically, the printer policies. The patch will then change the location from user-space to ProgramData space when GPPrefs User side stores these values.

Hope this helps you out !

MDM administrators that utilize Microsoft Endpoint Management (Intune) are familiar with the concept of Security Baselines.  A security baseline is a collection of Microsoft recommended configuration settings that help secure and protect enterprise users and devices.  For instance, MEM offers security baselines for Windows 10, Microsoft Defender ATP and Edge.  Security baselines are an easy and effective way for admins to ensure that they are consistently enforcing a minimum security level that will address fundamental security and compliance issues.  Some admins may be surprised that security baselines are available for Group Policy as well.

The Benefits of Using Security Baselines

While it is perfectly ok to configure your own MDM profile or GPO to select and configure available settings, baselines are a quick and easy way to enforce a default baseline that prevents users from making changes that will result in an insecure state.  There are a number of benefits of using security baselines offered by Microsoft.

• They are already configured by Microsoft security experts
• They enforce settings that mitigates contemporary security threats.
• Baseline settings have been pretested to ensure that they do not cause operational issues that are worse than the risks they mitigate
• They ensure that users and device configuration settings are compliant with the baseline

Security Baselines are not just for MDM

Microsoft has been releasing Security baselines since the Windows XP days.  Because Group Policy offers far more settings than MDM, the simplification that they offer for AD environments is even more of a benefit.  For instance, there are more than 200 Microsoft Edge Group Policy settings for Windows, but only some of these are security related.   By implementing Microsoft Edge baselines, you can rest assure that you are deploying the most up-to-date security settings for Microsoft Edge using your GPO environment.

Security Baseline for Microsoft Edge v83

Microsoft just recently announced the release of the Microsoft v83 of Microsoft Edge.  Microsoft continues to release new versions and settings for the new Chromium Edge browser.  Version 83 includes 19 new computer and user based settings.  The accumulated total of Edge settings currently stands at 311 Computer policy settings and 286 User configuration policy settings.  The current baseline involves 12 of these settings which are identical to the v80 security baseline.

To obtain the security baseline for Microsoft Edge, you need to download the Security Compliance Kit.  The compliance kit the following:

• Importable GPOs
• A script to apply the GPOs to local policy
• A script to import the GPOs into Active Directory Group Policy
• A spreadsheet documenting all recommended settings in spreadsheet form
• Policy Analyzer rules
• GP Reports
• Documentation

Implementing the Baseline into your AD Environment

Keep in mind that you must have the Edge v83 ADMX files contained within your Central Store as a prerequisite.  Once you download the toolkit, open the Scripts folder and run either the local policy script or the AD import script as shown below.

In this example we using the Baseline-ADimport script.  The script will then import a GPO called MSFT Edge version 80 – Computer that involves the following Administrative Templates.

Some of the configured settings include the following:

The toolkit includes a GP Reports Folder that contains an HTML report of GPO templates available in the baseline.

It is recommended that you stay current with the latest security baselines of Edge and Windows 10.  You can keep abreast of future baselines as they become available through the Microsoft website.   

You can learn about the newest policy settings available with Edge v83 on the Microsoft website. 

MSIX App Attach: How do you do it?  Find out in this blog.

That being said, let's first understand the problem MSIX App Attach tries to solve: 

For a long time, golden images were used with a myriad of applications... leading to a myriad of golden images.

NOT a great way to streamline. Images can quickly become bloated and the task of updating and maintaining them is cumbersome and overly time consuming.  VDI and application streaming has been another alternative, but these require complex infrastructure that has to be implemented and maintained. Now with remote work on everyone's mind, we need an easier way deliver applications. 

As such, Microsoft recently unveiled their new MSIX App Attach solution and is positioning it as their main technology for modern application packaging and provisioning.  As its name implies, it allows you to attach an application to the OS.  Some of the benefits of MSIX App Attach include:

• No special deployment servers are needed
• No agents: Everything is just "built into Windows" natively.
• You can use existing MSIX packages without altering or repackaging them.
• There is ultra-low / no performance impact.
• Can be used on-premise or cloud

To help you get started with this new methodology approach to application delivery, I have composed a called “MSIX: Walk before you run” to help you get familiar with the basic approach of how it works.  To keep things simple, we aren’t going to create any MSIX packages here but will use existing ones just to show how to implement an MSIX App Attach solution.

Then you can use the material below to "follow along" and try this yourself.

Step 1: Get a compatible OS

So first and foremost, you need an OS that supports it all.  That means getting a copy of Windows 2004 which is the latest version of Windows 10.  Then you need to upgrade to Build 19631 which at this time may require you to utilize the Windows Insider Program to get it.
 

Step 2: Get MSIX packages

So of course we need some MSIX packages.  Now we could use the MSIX Packaging Tool that you can download from Microsoft, but I am skipping that step for take advantage of some existing packages already available.  There is a great Microsoft repository site called Github Winget Package Manifest Page that features all types of prepackaged applications.  Pull the page up in a browser and do a search for MSIX.  In my video, I then chose MSIX Commander as my feature application and copied it’s URL in order to download it.  Now I have an MSIX package that I can use for my example.  Place it and all other downloads in a separate folder.  In my video, I am using a directory called “Demo.”
 

Step 3:  Using the Script

I went and logged on my local my machine as a domain admin in order to perform the remaining tasks.  Throughout my video I refer to a conglomerated script that I pieced together for you.  I obtained the script from several sources.  I got some from the official Microsoft Setup Document which guides you along in much the same format that I take in the video.  I also used several scripts made available by Tom Hickling’s Github page.  I then cobbled all of these scripts together and I have included the final script in its entirety at the end of this blog. Now let’s go through the script.
 

Step 4: Create a VHD Package

While you see MSIX App Attach associated with Azure and WVD a lot, keep in mind that what we are doing can be performed on local desktops or laptops as well as VDI and WVD machines.  I am doing everything locally in this video.  You will need to download the MSIXMGR Tool and place it in the same directory as your MSIX file (in my case MSIX Commander).  Now we need to utilize the script to create the VHD.  To do this, I used Tom Hickling’s script.  Since he was using VLC as his package, I modified it to accommodate MSIX Commander.  Go create the VHD, I am using the section titled “Make an MSIX into a VHD”

Open an elevated PowerShell session and go to the directory that contains all of the required files I mentioned earlier.  Then paste the VHD script and let PowerShell do its thing.  Now your MSIX VHD file is created with your MSIX file expanded into the VHD.  The VHD will already be mounted.  In my case it mounted as drive E so you can browser its contents.  Be sure to view the package name and copy that name and paste it into Notepad for future reference.  You will also need to know the Volume ID of the VHD file which you can find by using the “mountvol” command.  Then paste in your Notepad as well.

Step 5: Package Staging

In this video, I chose to skip the Certificate section for simplicity which takes us to the next step called Staging.  First go ahead and unmount the VHD.  You will find that the Stage section of the script is broken down into regions.  I advise you to paste the script into PowerShell region by region.  For first region, you will need to modify the VHD name, package name and volume ID you recorded earlier.  Below is what my first region looked like:

#MSIXCOMMANDER

$vhdSrc="c:\ApplicationVHDs\MSIXCOMMANDER.vhdx"

$parentFolder = "MSIXCOMMANDER"

$packageName = "PascalBerger.MSIXCommander_1.0.7.5_x64__ajjbhed1xnq88" 

$parentFolder = "\" + $parentFolder + "\"

$volumeGuid = "5f51883c-6f50-4c6a-9afb-9513c6e7c565"

#NOTE: GET VOLUMEGUID after mounting VHD then use MOUNTVOL command to get volume GUID. Remove {}

$msixJunction = "C:\temp\AppAttach\" 

The second region will mount the disk and the third region will perform what is called the junction.  The final “stage region” will perform the actual attaching.
 

Step 6: Register Script

So now we have attached the app, but we don’t have it within the user space.  I have the variables assigned to the values I mentioned earlier to run MSIX Commander so let’s copy the Register region and paste it into PS.  Once completed, you will then see MSIX Commander in the Windows Start Menu like in the video.  If I log on another user, in this case a standard user, I can’t see the MSIX app because the register script only applied to the user account I was logged on at the time.  So for this demonstration, I will simply open PowerShell logged on as a standard user and paste the Register region script in once again.  While I may have to dig a little through the Start menu to see it, it now appears for the user at hand.

Step 7:  Undoing the MSIX App Attach Environment

Any MSIX package that can be registered can be deregistered as well.  To do so, simply copy the De-Reregister region of the script and paste it into PowerShell and run it.  Now the app will disappear from the start menu.  In the video, I switched over to my original domain admin account and ran the deregistering process as well.  The final step of undoing everything will be to de-stage it so it cannot be applied to users any longer.

That completes the demonstration.  Go ahead and use the script I have included.  Just remember to modify the mentioned variables within the script when working with other MSIX files and such.  With a few run-throughs, you will be running in no time.

Jeremy’s Compiled Script below for reference... !

Make an MSIX into a VHD

#Go and package your app using the MSIX App packager

#Generate a VHD or VHDX package for MSIX

#vlc

new-vhd -sizebytes 2048MB -path C:\ApplicationVHDs\MSICOMMANDER.vhdx -dynamic -confirm:$false

$vhdObject = Mount-VHD C:\ApplicationVHDs\MSIXCOMMANDER.vhdx -Passthru

$disk = Initialize-Disk -Passthru -Number $vhdObject.Number

$partition = New-Partition -AssignDriveLetter -UseMaximumSize -DiskNumber $disk.Number

Format-Volume -FileSystem NTFS -Confirm:$false -DriveLetter $partition.DriveLetter -Force

#Create a folder with your Appname as the name of the folder in root drive mounted above

new-item -path 'E:\MSIXCOMMANDER' -ItemType Directory

#Expand MSIX in CMD in Admin cmd prompt - Get the full package name

.\msixmgr.exe -Unpack -packagePath ".\MSIX Commander-x64.msix" -destination "E:\MSIXCOMMANDER" -applyacls

#Cert

New-SelfSignedCertificate -Type CodeSigningCert -Subject "CN=JeremyTest"

1. STAGE

---

#MSIXCOMMANDER

$vhdSrc="c:\ApplicationVHDs\MSIXCOMMANDER.vhdx"

$parentFolder = "MSIXCOMMANDER"

$packageName = "PascalBerger.MSIXCommander_1.0.7.5_x64__ajjbhed1xnq88" 

$parentFolder = "\" + $parentFolder + "\"

$volumeGuid = "5f51883c-6f50-4c6a-9afb-9513c6e7c565"

#NOTE: GET VOLUMEGUID after mounting VHD then use MOUNTVOL command to get volume GUID. Remove {}

$msixJunction = "C:\temp\AppAttach\" 

#endregion

#region mountvhd

try 

{

    Mount-Diskimage -ImagePath $vhdSrc -NoDriveLetter -Access ReadOnly                 

    Write-Host ("Mounting of " + $vhdSrc + " was completed!") -BackgroundColor Green 

}

catch

{

    Write-Host ("Mounting of " + $vhdSrc + " has failed!") -BackgroundColor Red

}

#endregion

#region makelink

$msixDest = "\\?\Volume{" + $volumeGuid + "}\"

if (!(Test-Path $msixJunction)) 

{

    md $msixJunction

}

$msixJunction = $msixJunction + $packageName

cmd.exe /c mklink /j $msixJunction $msixDest

#endregion

#region stage

[Windows.Management.Deployment.PackageManager,Windows.Management.Deployment,ContentType=WindowsRuntime] | Out-Null

Add-Type -AssemblyName System.Runtime.WindowsRuntime

$asTask = ([System.WindowsRuntimeSystemExtensions].GetMethods() | Where { $_.ToString() -eq 'System.Threading.Tasks.Task`1[TResult] AsTask[TResult,TProgress](Windows.Foundation.IAsyncOperationWithProgress`2[TResult,TProgress])'})[0]

$asTaskAsyncOperation = $asTask.MakeGenericMethod([Windows.Management.Deployment.DeploymentResult], [Windows.Management.Deployment.DeploymentProgress])

$packageManager = [Windows.Management.Deployment.PackageManager]::new()  

$path = $msixJunction + $parentFolder + $packageName # needed if we do the pbisigned.vhd

$path = ([System.Uri]$path).AbsoluteUri

  $asyncOperation = $packageManager.StagePackageAsync($path, $null, "StageInPlace")                                                                                                                

$task = $asTaskAsyncOperation.Invoke($null, @($asyncOperation))    

$task

#endregion

2. REGISTER

----

#MSIX app attach registration sample

#region variables 

#PBI

#$packageName = "PowerBI_1.0.0.0_x64__74tjgdb1s5w2y"

#MSICOMMANDER

$packageName = "PascalBerger.MSIXCommander_1.0.7.5_x64__ajjbhed1xnq88" 

$path = "C:\Program Files\WindowsApps\" + $packageName + "\AppxManifest.xml"

#$path = "E:\VLC\" + $packageName + "\AppxManifest.xml"

#endregion

#region register

Add-AppxPackage -Path $path -DisableDevelopmentMode -Register

#endregion

3. DE-REGISTER

---

#MSIX app attach deregistration sample

#region variables

$packageName = "PascalBerger.MSIXCommander_1.0.7.5_x64__ajjbhed1xnq88"

#endregion

#region deregister

Remove-AppxPackage -PreserveRoamableApplicationData $packageName

#endregion

4. De-stage

--

#MSIX app attach de staging sample

#region variables

$packageName = "PascalBerger.MSIXCommander_1.0.7.5_x64__ajjbhed1xnq88"

$msixJunction = "C:\temp\AppAttach\"

#endregion

#region deregister

Remove-AppxPackage -AllUsers -Package $packageName

cd $msixJunction

rmdir $packageName -Force -Verbose

#endregion

Few things in this world are black and white and that includes software you download. 

There is a lot of "gray-ish" stuff residing on computers today.  A good example is software that comes bundled with the computer or was installed by another software application of a different vendor. 

Most of the time these applications aren’t something you want in the first place.  Other examples include advertising software or evasion software that actively tries to dodge the detection of your cybersecurity tools.   While these software files may not pose a direct threat to your computer in the same way that malware, Trojans and other types of malicious software do, these unwanted applications can impede the performance of your endpoints.  These unwanted software servings are referred to as Potentially Unwanted Applications (PUA).  A PUA is an application that has a poor reputation.  These applications can serve as a time consuming distraction of cleaning up these files.  Over time, these applications can increase the risk to your network. 

Windows 10 Defends Against PUAs

Windows 10 (Professional and Enterprise editions) can detect and block possibly harmful third party and unwanted applications using Windows Defender and does so without requiring Defender ATP or Enterprise licenses.  When activated, the PUA security feature looks for certain file structures and conditions that include the following:

• The file is being scanned from the browser
• The file is in a folder with "downloads" in the path
• The file is in a folder with "temp" in the path
• The file is on the user's desktop
• The file does not meet one of these conditions and is not under %programfiles%, %appdata% or %windows%

Should these conditions be met, the file in question is then quarantined and not allowed to be installed until approved. 

Using PowerShell to Enable PUA

You can use PowerShell to enable PUA within Windows Defender. 

The command options are as follows:

Set-MpPreference -PUAProtection Enabled

Set-MpPreference -PUAProtection AudiMode

The PS command will add and modify the DWORD value in the protected registry key as is shown below.

HKEY_LOCAL_MACHINE\SOFTWARE\ Microsoft\Windows Defender\MpEngine\MpEnablePus.

And assigns one of the following values.

• Disabled: 0 (Does not block PUAs)
• Enabled: 1 (Blocks PUAs)
• Audit Mode: 2 (PUA events are reported in Windows Event Viewer.  PUAs will not be blocked however)

Of course, you can make the changes directly in the registry itself.

The end result is as follows:

Enabling PUA with Group Policy

For domain-joined machines, you can enable PUA protection through Group Policy.  Simply create a GPO and go to Computer Configuration > Administrative Templates > Windows Defender Antivirus and enable “Configure protection for potentially unwanted applications.”

Then choose which your desired option:

You can also use Configuration Manager to deploy the setting as well.

05:07

Enabling PUA with Microsoft Endpoint Manager (Intune)

You can configure the Defender/PUA Protection CSP for your Intune enrolled devices.  You can either create a configuration profile or use the preferred method of enabling and configuring a security baseline.  To create a configuration profile choose Windows 10 as the platform and Device restrictions as the profile type. 

To deploy PUA using a security baseline, go to Endpoint Security > Security Baselines > Microsoft Defender ATP baseline > Profile configure the “Defender potentially unwanted app action” setting as is shown below.

Enable PUA in Chromium-based Microsoft Edge

The new Edge browser (version 80 and greater) contains its own PUA protection ability.  Go to your browser settings and select Privacy and services.  Then enable the “Block potentially unwarned apps” as is shown in the screenshot below.

You can also deploy this Edge setting using Group Policy as well.  Simply create a GPO and go to Computer Configuration > Administrative Templates > Microsoft Edge > SmartScreen settings and enable “Configure Microsoft Defender SmartScreen to block potentially unwanted apps.”

To enable the same setting using Microsoft Endpoint Manager, create a configuration profile and choose Windows 10 as the platform and Administrative Templates as the profile type.  Then go to Microsoft Edge > SmartScreen Settings and enable “Configure Microsoft Defender SmartScreen to block potentially unwanted apps."

You should enable these PUA tools as a part of your multilayer security strategy.  Hardening your desktop devices and reducing their attack surface exposure is critically important.  Another way to stop PUA (or, really any unwanted file download) is application control via PolicyPak Least Privilege Manager.  You can check it out here.

The last thing that standard users need on Windows 10 machines is access to REGEDIT.  It is one of the first things we block access to with Group Policy.  Surprising though, there is no native way in Intune to block it however.  The good news is that you can do it by creating a custom profile in Intune or any MDM.  I have included the information you need to create it below.  Now you can be rest assured that users won't be causing issues and circumventing policies by messing with the registry.

OMA-URI:  ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/IntuneEdu/EXE/Policy

Data Type:  String (XML file)

<RuleCollection Type="Exe" EnforcementMode="NotConfigured">

        <FilePathRule Id="fd686d83-a829-4351-8ff4-27c7de5755d2" Name="(Default Rule) All files" Description="Allows members of the local Administrators group to run all applications." UserOrGroupSid="S-1-5-32-544" Action="Allow">

          <Conditions>

            <FilePathCondition Path="*" />

          Conditions>

        FilePathRule>

        <FilePathRule Id="ce9d9fd5-d765-48df-b87b-e1bafd5653ed" Name="All files" Description="Allows members of the Everyone group to run applications that are located in any folder." UserOrGroupSid="S-1-1-0" Action="Allow">

          <Conditions>

            <FilePathCondition Path="*" />

          Conditions>

                        <Exceptions>

        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="MICROSOFT® WINDOWS® OPERATING SYSTEM" BinaryName="REG.EXE">

          <BinaryVersionRange LowSection="*" HighSection="*" />

        FilePublisherCondition>

                Exceptions>

        FilePathRule>

     RuleCollection>

Group Policy admins have been blocking access to command prompt for standard users since the beginning.  That is why it is frustrating for MDM admins having no native way in Intune to block it in the same fashion of Group Policy.  Well in actuality, you can block the cmd prompt, it just takes a custom profile, which is something that not everyone likes to do much.  Below is how you set it up so feel free to use the settings.  

OMA-URI:  ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/IntuneEdu/EXE/Policy

Data Type:  String (XML file)

Here is the XML code to paste in:

<RuleCollection Type="Exe" EnforcementMode="NotConfigured">

        <FilePathRule Id="fd686d83-a829-4351-8ff4-27c7de5755d2" Name="(Default Rule) All files" Description="Allows members of the local Administrators group to run all applications." UserOrGroupSid="S-1-5-32-544" Action="Allow">

          <Conditions>

            <FilePathCondition Path="*" />

          Conditions>

        FilePathRule>

        <FilePathRule Id="ce9d9fd5-d765-48df-b87b-e1bafd5653ed" Name="All files" Description="Allows members of the Everyone group to run applications that are located in any folder." UserOrGroupSid="S-1-1-0" Action="Allow">

          <Conditions>

            <FilePathCondition Path="*" />

          Conditions>

                        <Exceptions>

                    <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="MICROSOFT® WINDOWS® OPERATING SYSTEM" BinaryName="CMD.EXE">

          <BinaryVersionRange LowSection="*" HighSection="*" />

        FilePublisherCondition>

                Exceptions>

        FilePathRule>

     RuleCollection>

In Part 1, of our blog series outlining the details of Azure security defaults, we left off on the topic of MFA registration, which utilizes the Microsoft Authenticator app.  While all users MUST register for MFA, MFA is not required for all users every time.  Security defaults does enforce MFA for privileged accounts every time they log on as these accounts have increased access to your environment.  Security defaults requires added authentication for the following nine Azure administrator roles.

• Global administrator
• SharePoint administrator
• Exchange administrator
• Conditional Access administrator
• Security administrator
• Helpdesk administrator or password administrator
• Billing administrator
• User administrator
• Authentication administrator

MFA should be standard policy for all Azure admin account as account takeover attacks are one of the leading types of threats today.  Cybercriminals specifically target privileged accounts so special attention is needed.

Protecting all users

Security defaults is about improving the protection for all users, not just admin accounts.  While MFA is not required of every logon attempt, non-admin users are prompted for additional authentication when connecting from a new device or app.  There may be other instances that trigger MFA for standard users as well.

Limitations of MFA using security defaults

As mentioned, security defaults gives you free access to Azure AD MFA.  Free however, has its limitations.  Some of these shortcomings are listed below.

• Admins have no control over verification methods
• SMS and phone calls are not available as second factors
• You cannot configure trusted IPs for MFA exclusion
• An exclusion account for emergency access
• No MFA reports or fraud alerts

Again, keep in mind that Azure security defaults gives you the bare security minimum.  To obtain more features and control over MFA, you will need to ante up some additional money.  If you have a license for Conditional Access but have not yet enabled it, you can use security defaults as a temporary security band-aid until you are ready to enable Conditional Access policies.

Blocking legacy authentication

The majority of compromising sign-in attempts come from legacy authentication.  These credential stuffing or account takeover attacks tend to be automated and performed by bot nets.  Legacy authentication utilizes protocols that only use basic authentication.  These outdated protocols only require single factor authentication and cannot enforce a second factor as part of the natural authentication flow.  This is in contrast to modern authentication, which does support second factor authentication.  Using legacy authentication, an imposter can simply bypass your active MFA policy.

Client applications or services that use legacy authentication also have a blaring vulnerability in that credentials are collected and then stored until validated against an authority.   Apps or services that utilize modern authentication never store credentials.  Instead, they only present them.  In other words, modern authentication never trusts the app or service that is requesting your credentials. 

For these reasons, it is highly recommended that legacy authentication protocols such as IMAP, SMTP and POP3 be blocked.  This means that clients cannot use an older version of Office 2010 but can use a more current version such as Office 2016.  Some email/faxing software and other types of applications require the use of these older protocols.  Make sure that none of your applications are using legacy authentication protocols before enabling security defaults.   

Protecting privileged actions

We mentioned how security defaults uses MFA to protect privileged user accounts.  It also protects privileged actions as well.  This is important because non-admin users can be delegated to Azure Resources.  Azure services can be managed through the Azure Resource Manager API.  These services include:

• Azure portal
• Azure PowerShell
• Azure CLI

These services give users tenant wide powers such as the ability to modify configurations, service settings and billing subscriptions.  This is why it is imperative to verify the identity of users that utilize them.  When enabled, security defaults will require added authentication before allowing delegated access. 

Conclusion

Azure AD security defaults certainly has its shortcomings and should not be considered a long-term solution for any sizable organization.  It also does not provide the rich security protections that many organizations need to satisfy security policies or compliances.  It does provide a “one-click” easy button that new tenants can use to protect themselves right out of the gate while they begin to learn their solution options.  While it may provide ample protection for small organizations, tenant owners should view it as a transitory measure only.  Security defaults is a great first step and one that hopefully, will better secure the entire O365 community as well. 

The old adage, “You can lead a horse to water but you can’t make them drink,” certainly applies to cybersecurity today.   You can provide users and organizations with all types of cybersecurity tools and policies, but as long as they are optional, you cannot make them utilize them.  A case in point is the enforcement of multifactor authentication (MFA) for Azure.  Despite the fact that Microsoft attests that MFA will prevent 99.9 percent of account compromises, only around 8 percent of administrative accounts in Azure AD use it.  In a world in which credential stuffing attacks initiate billions of malicious login attempts on a monthly basis, MFA should be an enforced policy for every organization.  The hard truth is that we live in a digital world in which security is no longer optional. 

Depreciation of Baseline Security Policies

Microsoft has already been providing a set of predefined policies to help organizations protect themselves against common attacks.  There were four baseline policies.

• Require MFA for admins (preview)
• End user protection (preview)
• Block legacy authentication (preview)
• Require MFA for service management (preview

Azure admins could enable or disable them for their Azure userbase.  Unfortunately, too many organizations have not taken advantage of these policies or the rich set of security capabilities such as Conditional Access.  This not only makes them more vulnerable, but adds to the collective threat environment for everyone else as well.  Every computer that is compromised serves as one more potential attack vehicle that perpetrators can use for malicious deeds towards others.  The IT industry is starting to recognize that organizations not only have a responsibility to protect their own users, but share in the universal collective effort to make the world a less vulnerable place.  By hardening up our own attack surfaces, we harden the world as well.  As a result, Microsoft is depreciating these predefined policies on February 29, 2020, replacing them with the new “Security Defaults.”

What are Azure Security Defaults?

The intention of Security Defaults is simple; provide an enforced default security state for all Azure organizations that do not implement security policy initiatives on their own.  Security Defaults are available to all tenants and like Baseline Security policies, are offered at no additional cost.  New tenants will automatically have security defaults enabled by default.  If your tenant was created on or after October 22, 2019, chances are that security defaults is already enabled.  In the coming phase, Microsoft will begin retroactively enabling it for existing domains who have failed to enact any security measures on their own.  These security defaults enforce the following:

• Unified Multi-Factor Authentication registration
• Multi-Factor Authentication enforcement
• Blocking legacy authentication
• Protecting privileged actions

If you are an existing tenant prior to the October date and currently and currently do not utilize security policies of any kind, you will need to enable Security Defaults for now.  You can do this by going to Azure Active Directory > Properties > “Manage Security defaults” and set the Enable security defaults toggle to Yes as is shown below.

If you currently utilize Conditional Access, Classic or Identity Protection policies that consist of settings that may conflict with any of the security default offerings, you will receive an error message when trying to enable default security policies as is shown below.

Note that you will have to disable Security defaults before creating conditional access or other security policies that involve conflicting settings.  Keep in mind too that Security defaults is a bare minimum.  While they may be appropriate for small organizations, medium or large enterprises should expand into policies that are more comprehensive. 

MFA Registration

Let’s start with multifactor authentication.  Security defaults require all users within the tenant to register for MFA.  MFA requires a user to use a second method of authentication to prove their identity in addition to their logon credentials.  The most popular method currently is SMS MFA in which the user must type in a unique one-time code sent to their cell phone after logging on with their assigned credentials.  While this and other methods are available in Azure Conditional Access policies, it is not an available option under Security defaults.  Azure Security defaults only utilizes the Microsoft Authenticator app

Once you enable Security defaults, users are required to register for MFA within 14 days.  The 14-day clock starts from the time the user logs on for the first time once the security defaults are enabled.  Should a user fail to register within this required time frame, the user will not be able to logon until the FMA registration is completed.  The screenshot below shows what users will see during the 14-day registration period.

In addition to completing the MFA registration process, users must also install the Microsoft Authenticator app on their cell phone.  We will cover Multi-Factor Authentication enforcement in Part 2 of this blog series. 

MSIX … What it means for you… and managing those Applications

Do not be alarmed if you see a file with an .msix extension to it.  MSIX is the latest application installer for Windows applications.  Now that you know what it is, the next question is probably, why does the world need another application installer?

Good question.  After all, we already have three installer formats.

The current set of Installer Choices

The former trilogy of application installers include EXE, MSI and AppX packages.  EXE installers are the most recognized and best suited for manual installs.  They incorporate GUI driven wizards that guide users through the installation process.  This allows for customized options such as multiple languages, add-ons and selected file paths.  EXE installers can also detect previous installations.  Because they are so accommodative to customization, they are also complex.   This makes unattended installs challenging.  EXE files also make admins very nervous in a malware world. 

MSI installers are simple, which is why they are best-suited silent unattended installations.  They too use graphical interfaces but do not offer extras or customized options, nor can MSI installers detect prior installations.  Finally, there are AppX installers.  These are used for Universal Windows apps and have similar characteristics to MSI installers in that they are simple and straightforward.  One thing that sets them apart from the other two is that they rely on container technology.  This isolates them from the rest of the operating system.  This makes them much more secure.  Unfortunately, AppX packages can only be used for Windows 10 so legacy machines cannot utilize them.

The new alternative called MSIX

MSIX is the new kid in town.  It is not very popular as of yet as it was just released in 2018.  It is the alternative to the current three and Microsoft intends that the MSIX packaging solution to be the centerpiece of its deployment toolset eventually.  Like many great ideas from Microsoft, new tools and ways of doing things take time for organizations to digest them.  The MSIX installer platform does not have a great market presence as of yet.   That does not take away from its many benefits however.  MSIX has definite improvements over its predecessors as it combines the best features of MSI and APX into a single format.  Basically, it installs like an MSI file, but behind the scenes, installs like an AppX.  You can create MSIX packages with either an interactive user interface or command line sequence.  Let’s look at the advantages associated with this new installer format.

Advantages of the MSIX Installer

One thing common to traditional applications is that tend to leave a footprint.  This footprint consist of AppData files and registry entries that never seem to get deleted after the application is uninstalled.  This clutter then lives on for the lifetime of the hosted machine.  MSIX has alleviated this.  Like AppX, MSIX is based on a containerized model.  This simplifies both the install and uninstall processes.  Uninstalling an MSIX package will remove any files and registry entries created by the app within the AppData folder, reducing machined clutter.

Unlike AppX installers, MSIX installers work on more than just Windows 10 machines and they support 32-bit applications.  Microsoft has released an SDK, which provides all API’s necessary to unpack an app package on multiple platforms.  Its cross-platform compatibility includes iOS, MacOS, Android, Linux and Windows 7.  In addition, the process of converting older applications to the MSIX format is far easier than to AppX.  You can also convert AppX applications to MSIX as well.  MSIX package bundling allows a single package to contain multiple language or device specific items, except unlike EXE installs, they options can be automatically selected by Windows. 

MSIX can also hand over the updating process to the operating system.  This streamlines the updating process by making it more secure and reliable.

Security is at the epicenter of MSIX.  MSIX applications are tamper proof because they must be digitally signed regardless of how the packages are installed.  For software vendors creating MSIX packages to publish in the Microsoft Store, Microsoft will sign the package once the approval process has been is complete.  Organizations intending to publish MSIX for direct download or internal network distribution must sign it with a valid code-signing certificate purchased from a certificate authority.

The MSIX Packaging Tool

You can download the MSIX packaging tool from the Microsoft Store.  The package tool requires Windows 1809 and later.  Microsoft recommends that you create a clean VM for the conversion host.  Keep in mind that the MSIX Packaging Tool will assume the processor architecture of the Windows 10 OS version in which the conversion process is taking place. You must convert your installers in the same environment where you expect to deploy them.  Once installed, simply open the tool to begin the packaging wizard.  You will be first be asked to choose the selected task.  In this example, we are creating a new application package.

You will then choose the desired packaging method.

The packaging tool will perform an assessment of the machine that will handle the conversion process.

You will then set out to create the package.  You need to select the installer you want to package.  Then you must select a signing preference.  Your choices are as follows:

In the example below, we have selected an MSI installer with no arguments.  We are signing using a certificate from a certificate authority with the assigned password.

Next, fill out required packaging information.

Click “Next” and the installation process will begin. During this process, the packager will capture the registry or any files needed to install or configure the app.

At this point, the conversion process will listen for any executables that are triggered at the initial launch of the application.  This is why it is essential use a quiet machine for the conversion process.  Captured executables will be displayed on the screen.  It is here that you will manage any first launch tasks.  You should launch the application at least one time in order to capture any first launch tasks. 

Upon clicking “Next” you will asked to confirm that you wish to culminate the listening process.

Now choose a destination folder for the final package and click Create.

That completes the MSIX packaging process.  Be prepared to see MSIX packages a lot more down the road.