Version 2004 – Windows 10 and Server Security Baseline

Version 2004 – Windows 10 and Server Security Baseline

This week Microsoft has announced the final release of the security configuration baseline settings for Windows 10 and Windows Server version 2004. This version sees 1 additional policy and 1 policy removed, Microsoft has also made 2 recommendations that organizations might worth considering.

Download the Microsoft Security Compliance Toolkit that allows you to test the recommended configurations, and customize/implement as appropriate.

Notable changes are as followed;

TitleDescriptionConfiguration
LDAP Channel Binding Requirements In the Windows Server version 1809 Domain Controller baseline we created and enabled a new custom MS Security Guide setting called Extended Protection for LDAP Authentication (Domain Controllers only) based on the values provided here. This setting is now provided as part of Windows and no longer requires a custom ADMX. An announcement was made in March of this year and now all supported Active Directory domain controllers can configure this policy. The value will remain the same in our baseline, but the setting has moved to the new location. We are deprecating our custom setting. The new setting location is: Security Settings\Local Policies\Security Options\Domain controller: LDAP server channel binding token requirements.
 
Note: this new policy requires the March 10, 2020 security update. (We assume that, as security conscious baselines users, you are patching!) Details of that patch are here.
Policy updated
Microsoft Defender Antivirus File HashMicrosoft Defender Antivirus continues to enable new features to better protect consumers and enterprises alike. As part of this journey Windows has a new setting to compute file hashes for every executable file that is scanned, if it wasn’t previously computed. You can find this new setting here: Computer Configurations\Administrative Templates\Windows Components\Microsoft Defender Antivirus\MpEngine\Enable file hash computation feature.
 
You should consider using this feature to improve blocking for custom indicators in Microsoft Defender Advanced Threat Protection (MDATP). This new feature forces the engine to compute the full file hash for all executable files that are scanned. This can have a performance cost, which we minimize by only generating hashes on first sight. The scenarios where you may want to test more thoroughly for performance include devices where you frequently create new executable content (for example, developers) or where you install or update applications extremely frequently.
 
Because this setting is less helpful for customers who are not using MDATP, we have not added it to the baseline, but we felt it was potentially impactful enough to call out. If you chose to enable this setting, we recommend throttling the deployment to ensure you measure the impact on your users’ machines.
Worth considering
Account Password LengthIn the Windows 10 1903 security baselines we announced the removal of the account password expiration policy. We continue to invest in improving this experience. With Windows 10 2004, two new security settings have been added for password policies: ‘Minimum password length audit’ and ‘Relax minimum password length limits’. These new settings can be found under Account Policies\Password Policy.
 
Previously, you could not require passwords/phrases greater than 14 characters. Now you can! Being able to require a length of more than 14 characters (maximum of 128) can help better secure your environment until you can fully implement a multi-factor authentication strategy. Our vision remains unchanged in achieving a password-less future, but we also recognize that this takes time to fully implement across both your users and your existing applications and systems.
 
You should be cautious with this new setting because it can potentially cause compatibility issues with existing systems and processes. That’s why we introduced the ‘Minimum password length audit’ setting, so you can see what will happen if you increase your password/phrase length. With auditing you can set your limit anywhere between 1 and 128. Three new events are also created as part of this setting and will be logged as new SAM events in the System event log: one event for awareness, one for configuration, and one for error.
 
This setting will not be added to the baseline as the minimum password length should be audited before broad enforcement due to the risk of application compatibility issues. However, we urge organizations to consider these two settings. Additional details about these new settings will be found here, once the new article get published in the coming days.
 
(NOTE: As of the today the link is not yet live, we are actively working to ensure it gets posted soon!)
 
As a reminder, length alone is not always the best predictor of password strength, so we strongly recommend considering solutions such as the on-premise Azure Active Directory Password Protection which does sub-string matching using a dictionary of known weak terms, and rejects passwords that don’t meet a certain score.
Worth considering
Turn on Behavior MonitoringIn keeping with our principals of criteria for baseline inclusion we have found that the following setting does not need to be enforced; there is no UI path to the setting, you must be a privileged account to make the change, lastly we do not feel a mis-informed Admin would change this setting.  Based on these principals we are removing Computer Configuration\Administrative Templates\Windows Components\Microsoft Defender Antivirus\Real-time Protection\Turn on behavior monitoringPolicy removed

Regards
The Author – Blogabout.Cloud

Installing PowerShell modules using Microsoft Endpoint Manager

Installing PowerShell modules using Microsoft Endpoint Manager

In this video I show how I install all the common PowerShell modules that I use when building/provisioning Windows 10 devices that are registered in MEM.In this video I show how I install all the common PowerShell modules that I use when building/provisioning Windows 10 devices that are registered in MEM.

Regards
The Author – Blogabout.Cloud

Configuring your Windows 10 devices with custom Desktop and Lockscreen backgrounds with Microsoft Endpoint Manager.

Configuring your Windows 10 devices with custom Desktop and Lockscreen backgrounds with Microsoft Endpoint Manager.

Using Microsoft Endpoint Manager and Azure Blob Storage to deliver customized Desktop and Lockscreen backgrounds.

Regards
The Author – Blogabout.Cloud

Delivering your favourite configuration, tweaks and PowerShell modules to all of your Microsoft Endpoint Managed Windows 10 devices.

Delivering your favourite configuration, tweaks and PowerShell modules to all of your Microsoft Endpoint Managed Windows 10 devices.

In recent times I have had to rebuild a number of my Windows 10 devices and reinstall my favourite scripts, applications and tweaks. Which got me thinking there must be a better way of rebuilding my devices, so heres my approach.

Azure Blob Storage

After transitioning from a very UC focused role I have been learning an appreciation for the whole M365 stack and how Microsoft Azure can work hand in hand with potential problems or scenarios. Microsoft have done a very good job in providing a platform to enable businesses and organisations to leverage their subscriptions in more power ways, so with that being said lots looks at Azure Blob Storage.

First of all we need to log into the Azure Portal as this is where all the required work will now take place. Once logged in you will need to search for Storage account as this is where all files will need stored. In my case, I have already created a Storage Account but you can complete this by using the Add button.

Storage Accounts

As you have now created the Storage Account, you will need to go to Containers as shown below.

Containers

Again in my case I already have a container called intuneblogaboutcloud but you can create your container by clicking + Container

New / Existing Containers

We can now upload all required PowerShell scripts, installers, images etc.. depending on what you are attending to achieve. In my container, I have created folders to structure the data.

Structure to the container

One of the key things to understand with each file uploaded it has a unique URL, please keep this in mind as later in this post I will be demostrating how I use this URL to deliver customizations to my Windows 10 devices.

Example of the blob uploaded

PowerShell Scripts

So Microsoft Endpoint Manager has the ability to deliver PowerShell scripts to any and all Windows 10 enrolled devices. As I was getting annoyed in having to reinstall PowerShell customizations and tweaks I like to perform on my client machines. I created several scripts that do the hard work for me.

Now we will need to connect to Microsoft Endpoint Manager portal. Once logged in browse to Devices –> PowerShell Scripts.

PowerShell Scripts

As you can see from the above I am curently delivering 3 scripts to my Windows 10 endpoints so lets look at them a bit closer.

Microsoft Teams – Custom Backgrounds

Please refer to my dedicated post about publishing custom backgrounds for Microsoft Teams.

PowerShell – Common Modules

In my line of work, I use a number of PowerShell modules to help me achieve the required outcomes to complete a project or ad-hoc work for customers.

The below script installs the following PowerShell modules

One of the unique features of this script is to check for updated versions of the module from the PSGallery. However, this feature isn’t effective using MEM for delivery unless a modified script is upload to the MEM.

https://github.com/TheWatcherNode/blogaboutcloud/blob/master/Get-CommonModules.ps1

PowerShell – Custom PowerShell Tweaks

While working on a customer engagement there was a requirement to deliver customization to Windows 10 endpoint and to be able to achieve this via a “Cloud First Approach”.

The below script has designed to action the following;

  • Create a local directory to download all files from Azure Blob Storage (C:\_build)
  • Download all specified files from Azure Blob Storage
  • Run all applications or scripts
  • Remove C:\_build folder directory
  • Run any necessary PowerShell commands to configure applications.

https://github.com/TheWatcherNode/blogaboutcloud/blob/master/Get-AppsfromBlobStorage.ps1

As mentioned in the Azure Blob Storage section the unique URL will have an important part to play. As you can see from the image below, I have highlighted 3 sections

  • 1 – The unique URL with its our unique variable name $chromeinstaller
  • 2 – The download command
  • 3 – The installer command

Even with limited PowerShell experience, you will be able to understand how this script works and customize to your needs. Whether its an .msi, .exe, .ps1 you just modify the script to your needs.

W32 Apps

Finally, delivering applications to Windows 10 using the native W32 App method. Microsoft have already made it easier with Microsoft Apps for Enterprise aka Office ProPlus but as you can see I have leverage MEM to install a number of MSI files that I like on my machines. I will not going into detail on this section as its quite straight forward.

So there you have it, customizing my Windows 10 devices with my tweaks, modules and applications via Microsoft Endpoint Manager + Azure Blob Storage and PowerShell.

Regards
The Author – Blogabout.Cloud

Microsoft Endpoint Manager – Converting your Windows 10 Pro devices to Enterprise

Microsoft Endpoint Manager – Converting your Windows 10 Pro devices to Enterprise

Hello Readers,

Recently during a rollout of Microsoft Endpoint Manager, I noticed that my configured Lockscreen and Desktop background where not being applied to my newly enrolled Windows 10 devices. 🙁 After a bit of investigation I noticed that the device was running as Windows 10 Pro, even though the image used to build the machine was Windows 10 Enterprise.

Launch https://devicemanagement.microsoft.com and browse to Device –> Configuration Profiles –> New
– Name = Provide a name
– Description = (Optional)
– Platform = Windows 10 and later
– Profile Type = Edition upgrade and mode switch
– Settings = Select Windows 10 Enterprise and provide your key

Now assign the policy to the affected devices and you will now have Windows 10 Enteprise devices.

Regards
The Author – Blogabout.Cloud

Encrypting your Windows 10 devices using Microsoft Intune and non-admin users

Encrypting your Windows 10 devices using Microsoft Intune and non-admin users

Microsoft Endpoint Manager is great however, if you want to encrypt Windows 10 device silently with a normal standard user logged in then you might find it difficult to do so via the MEM Portal settings. So this is where this blog post will come in handy 🙂

In order to encrypt the device silent you need to create a Custom Configuration Policy. Browse to your Microsoft Endpoint Manager Portal or Intune Portal –> Go to Device Configurations Profile –> Create New Profile

  • Enter a Name for the Profile
  • Select Windows 10 and later from Platform
  • Select Custom from Profile type
  • Select Configure from Settings
  • Press Add

We will now need to enter the following information to configure encryption.

NameOMA-URIData TypeValue
AllowStandardUserEncryption ./Vendor/MSFT/BitLocker/AllowStandardUserEncryption Integer 1

Once you have created the policy, assign it to your required devices and BitLocker will now encrypt the devices.

Oh but wait!!!

In my experience in performing this procedure have ran into an issue where Intune recognises the device has compliant against “Require BitLocker” but non-compliant against “Encryption of data storage on the device”.

This is due to the device not being able to backup the BitLocker Encryption Key to Azure Active Directory. The workaround for this was to deploy a PowerShell script using Intune that forces the key to be backup up.

So lets add a script to Intune which will execute the required steps; First go to Device Configuration –> Scripts –> Add

Provide a Name which will easily identify the script in the Intune Portal.

Browse to the script location on your local machine or network drive
Tick Yes to Run script in 64 bit PowerShell host.

And save then assign to the required AAD Group to execute on the client macine.

I cannot take any credit for the script but it resolves the issue I encountered and my compliant policy was once again “Compliant” for all devices. I have made this script available via my GitHub account.

https://github.com/TheWatcherNode/blogaboutcloud

Regards,
The Author – Blogabout.Cloud

Isn’t it time you switch gears into Windows Autopilot

Isn’t it time you switch gears into Windows Autopilot

Windows Autopilot has increased popularity over the past 3 years since its release in 2017. As a consultant within the Microsoft Cloud space, I had more conversations with customers about how Autopilot can change who they deploy Windows 10 devices to their end-users.

Being able to deliver a brand new Windows 10 device from the OEM Factory to the end-users desk that is already configured with all the required security policies and applications has to be the biggest selling point.

This post is how we can move to Windows Autopilot in 3 easy steps;

Step 1 – Register Devices

Option 1 – (Recommended) Have devices registered automatically;

– Request clean images, choice of Windows 10 version at the same time (if available) not all OEM vendors are able to provide clean images. A useful workaround for this is getting a Windows 10 script I have seen available to remove bloatware. If you haven’t seen it I have dropped a copy on GitHub.
– Specify group tag to help segment device by purpose (depending on the size of your organisation this may not be a requirement)
-Device are automatically tagged with purchase order ID

Option 2 – (Recommended for Piloting) Register devices yourself via Intune for testing and evaluation using Get-WindowsAutopilotInfo PowerShell script created by Microsoft.

Once you have the required CSV file from executing the script you can manually register the device.

Option 3 – Register (harvest) existing Intune-managed devices automatically. If you are an organisation that has already enrolled your Windows 10 devices into Microsoft Intune you can register all devices for Windows Autopilot.

Step 2 – Assign a profile

Use Intune;
– Select profile scenario (user-driven or self-deploying)
– Configure required settings
-Assign to Azure AD group so Intune will automatically assign to all devices in that group. (I am a big fan of dynamic groups)

Use a dynamic Azure AD group to automate this step
– Consider static Azure AD groups for exceptions

Here are the deployment profiles that can be configured today.

Coming soon

Azure Hybrid AD join for devices that dont have line of sight to a domain controller, this is currently in testing and will use a VPN to call home. The support has been built into Windows 10 1909.

Step 3 – Deploy

Boot up the device or devices

Connect to a network either wired or wireless

Enter credentials if required (credentials not required for self-deployment profiles)

The device will now go away and provision based on your configuration within Microsoft Endpoint Manager, once complete all that is left to say is…

Welcome to Windows Autopilot!!! I will be writing a more in-depth post about Autopilot soon because off the configuration I am currently using for my home devices.

Image result for Welcome computer

Regards
The Author – Blogabout.Cloud

Delivering your applications to Windows 10 Clients using Azure Blob Storage and Intune

Delivering your applications to Windows 10 Clients using Azure Blob Storage and Intune

Delivering your corporate applications can be a nightmare if you dont have a enterprise delivery solution like System Center or 3rd party mechanism.

So let’s see how Azure Blob Storage and Microsoft Intune can address this issue by using a storage location and PowerShell script.

Azure Storage Account

One of the requirements for this solution is an Azure Storage Account within your Azure subscription, this account will be used for storing the applications which you would like to roll out to your Windows 10 desktops that are managed using Microsoft Intune.

Storage Account

Specify the required settings within the Basic tab for creating a Storage Account.

Basic Properties

Using the default settings as shown below

Advanced Properties

Click Review and Create
Click Create

Configuring Storage Account with required Applications

Click Container
Specify the Name
Select Conditioner (anonymous read access for containers and blobs) under Public Access Level

Blob – Container

Select your container
Select Upload
Select the files you want to upload
Modify the block size if it’s less than the size of the files you are uploading
Select Upload

Once the files are upload they all have a unique url which is used to identify the file as shown below.

The PowerShell Script!!!

I have created a PowerShell script that is available on GitHub and should be self-explanatory.

Step 1 – Download all the required files into C:\_Build
Step 2 – Run installer files
Step 3 – Run additional Powershell scripts (Optional)
Step 4 – Remove C:\_Build
Step 5 – Create RegKeys (Optional)

https://github.com/TheWatcherNode/blogaboutcloud/blob/master/Get-AppsfromBlobStorage.ps1

Publish script via Intune

If you are having issues with script not executing, please visit this URL to ensure you met all the Microsoft pre-requisites.

https://docs.microsoft.com/en-us/intune/apps/intune-management-extension

Regards
The Author – Blogabout.Cloud

Hybrid Azure AD Tip – The device object by the given id (ID of machine) is not found.

Hybrid Azure AD Tip – The device object by the given id (ID of machine) is not found.

Recently when working with a customer I was troubleshooting why their devices were showing up as Azure AD Registered in the Azure portal in Azure Active Directory when they should be Hybrid Azure AD joined. These were Windows 10 1809 devices.

When running “dsregcmd /status” on one of the machines, it would show as AzureAdJoined : NO. When it is Hybrid Azure AD joined, it should still say Yes.

If you run the command as admin, you will see there is Diagnostic Data section. On my devices, it said:

Client ErrorCode : 0x801c03f2
Server ErrorCode : DirectoryError
Server Message: The device object by the given id (guid) is not found.

This is because the device(s) has not been synced to Azure AD by Azure AD Connect. Make sure that the OU’s that the computer objects are in is set to sync to Azure AD. In my customer’s configuration, they had additional filtering where the users and computer objects needed to be in a Security Group to be synced to Azure AD.

Once the Azure AD Connect sync had completed successfully, and the device registration task had run again on the client, the machine now shows as Hybrid Azure AD joined in the Azure portal.

Regards,
Author @ Blogabout.Cloud

This device cannot use a Trusted Platform Module – Windows 10 1909 Virtual Machines

This device cannot use a Trusted Platform Module – Windows 10 1909 Virtual Machines

When testing BitLocker encryption on the new Windows 10 1909 release using my VMWare environment. I ran into the following error;

This device cannot use a Trusted Platform Module. Your administrator must set the “Allow BitLocker without a compatible TPM” option in the “Require additional authentication at start-up” policy for OS volumes.

Go to your Local Group Policy

Locate the following setting under Computer Configuration –> Administrative Templates –> Windows Components –> BitLocker Drive Encryption –> Operating System Drives

Require additional authentication at startup

We will now need to edit this policy to enable the required settings, please use the below screenshot as your guide.

Once the policy has been enabled with the required settings, re-run BitLocker Drive Encryption and this time it’ll be more successful.

Regards
The Author – Blogabout.Cloud