In this chapter, we will be covering the administration and remote management of Windows devices within an organization. The administration of your devices is a very important task and one that needs ongoing interaction and support to stay current. The foundation of your Windows administration will be developed from your established framework and baselines, as discussed in Chapter 2, Building a Baseline. However, just as important are your policies, standards, and procedures, which should have already been built to direct how you administer your Windows environment. With that, the administration of your devices should become a much simpler task of execution to meet the defined requirements that have been created and agreed upon.
When it comes to remote management, ensuring a secure and locked down model is a must. Support staff who have remote access to your Windows devices are privileged users that have elevated rights to administer your servers and workstations. Because of this, ensuring a rigid structure for your remote management is essential. Any misconfiguration or open back door could allow an attacker to gain easy access to your environment and data. One simple example is if you exposed your server's Remote Desktop Protocol (RDP) access directly to the open internet. This configuration can be highly prone to attacks.
Both your administrative and remote management strategies need to be well defined and implemented based on your standards, policies, and baselines. In order to enforce these baselines, let's look at ways to accomplish this by reviewing the following topics:
- Understanding device administration
- Enforcing policies with Mobile Device Management (MDM)
- Building security baselines
- Connecting securely to servers remotely
- Introducing PowerShell and security
This chapter will cover a range of technologies including several step-by-step instructions. To follow along, you will need the following technical requirements as a minimum:
- Configuration Manager
- An Intune subscription
- Permissions to modify Group Policy
- The Microsoft Security Compliance Toolkit
- The Convert-GPOtoCI PowerShell script: https://github.com/SamMRoberts/Convert-GPOtoCI
- Azure Security Center standard
- Azure Bastion
Check out the following video to see the Code in Action: https://bit.ly/2D7BJFB
Without device administration, the task of ensuring your devices are secured and hardened is unrealistic. Unless you manage a very small number of devices, you are going to need some form of device administration to ensure your devices are set up to meet compliance policies and are secured when they are handed over to your employees. Even after the devices have been handed over, you are going to need to continuously push changes to these devices. Without effective administration, your organization will be putting itself in an extremely vulnerable situation.
We covered the concepts and Microsoft tools used to manage both your end user devices and Windows servers in detail in Chapter 3, Server Infrastructure Management, and Chapter 4, End User Device Management. This chapter will expand on those tools, and you will learn how to administer your devices along with enforcing the predefined baselines your company has agreed upon to ensure your devices are within compliance. First, let's look at how your devices are joined to your environment, as each provides different methods of administration, especially as we move into a cloud-first world.
The following section will provide an overview of what domain join, hybrid, and Azure AD joined are and the differences between them.
Domain join is the traditional model and allows the central administration of your corporate end user devices and Windows servers in an on-premises scenario. When joining your device to a Domain, you are joining that device or server to your Active Directory Domain. Once joined, you can use Group Policy Objects (GPOs) to configure and enforce your policies based on your defined baselines. For your end user devices, you will most likely supplement Group Policy with an additional management tool such as Configuration Manager. This method has served as a very mature and reliable model.
If you want to take the approach of moving to a cloud-only world to administer your devices, then you will need to Azure Active Directory (Azure AD) or (AAD) join your devices. This method directly joins your device to the cloud environment and Azure AD, where you can manage and administer your devices using Intune. This model also supports the ability to use co-management with Microsoft Endpoint Configuration Manager. Moving to the cloud model provides a far more powerful and robust deployment, allowing the improved provisioning of your devices and increased flexibility for your users. Azure AD joined devices will require you to log in with your Azure AD cloud credentials, which can be synced from an on-premises AD.
There is also the concept of Azure AD registered devices, which supports the use case of Bring Your Own Device (BYOD). This allows Windows 10, iOS, Android, and macOS devices access to your corporate resources without being required to sign in to your device with your work account.
Many organizations may face a dependency that still exists with on-premises infrastructure. To provide the ability to take a step into the Azure cloud there's the option of hybrid Azure AD join devices. With this method, your devices will still be joined to your on-premises AD but will also register in Azure AD. This allows management using Group Policy, Configuration Manager, or the option to use co-management with Microsoft Intune. Windows 7, 8.1, and 10 and Windows Server 2008/R2, 2012/R2, 2016, and 2019 all support this method.
The following diagram shows these three different options for your devices:
In the next section, we will provide details on how to enforce policies with MDM using Configuration Manager and Intune.
When a device becomes fully Azure AD joined, it opens new opportunities to layer and enforce security policies. Unlike domain-joined or hybrid-joined devices, a fully Azure AD joined device is not part of an on-premises domain, it never connects to a domain controller, and it does not receive Group Policy. Many organizations have years worth of GPOs that they rely on to harden their Windows systems and the question now becomes how to move and enforce these policies with MDM. The answer is to use Configuration Manager, Intune, or a combination of the two with co-management. Unfortunately, there is no clear lift-and-shift path, and part of the challenge is the auditing and evaluation of what currently exists.
In this section, we are going to learn about creating and enforcing policies with MDM. We will walk through how to build, assign, and enforce compliance settings such as configuration items and configuration baselines in Configuration Manager and how to report on them. Then, we will take a similar approach with Intune to create device configuration profiles and assign compliance policies to be used for device compliance evaluation.
To view all of the compliance settings inside of Configuration Manager, navigate to Assets and Compliance > Overview > Compliance Settings. These settings are used to enforce your Windows baselines to ensure they are securely hardened and in compliance with your policies. Some of the available compliance settings include the following:
- Configuration Items that contain settings for computers or mobile devices. You can create your own custom Configuration Items or download and import them from a vendor.
- Configuration Baselines contain the Configuration Items that you want to deploy to a collection in order to evaluate compliance. Deployments can be put into a monitor or remediate mode.
- User Data and Profiles manage the user's settings for folder redirection, offline files, and roaming profiles.
- OneDrive for Business Profiles is used to configure the OneDrive for Business settings for Windows clients such as known folder redirection.
- Compliance Policies are where you create policies that can be used in conjunction with conditional access. Compliance policies can be created for devices without the Configuration Manager client.
- Conditional Access settings manage conditional access to company resources.
Most conditional access settings will be moving to the Microsoft Endpoint Manager Admin Center at https://devicemanagement.microsoft.com. Later versions of the Configuration Manager current branch now direct you to use this portal.
- Company Resource Access allows you to create VPN, Wi-Fi, and certificate profiles to deploy to your devices.
- Microsoft Edge Browser Profiles contain custom settings to create an Edge Browser policy in Windows 10.
Let's look at what Configuration Items are and how they are used to evaluate settings on Windows 10 devices and servers.
Introduction to Configuration Items
A Configuration Item contains a list of settings and compliance rules that are used for evaluation. When creating a new Configuration Item, you can specify whether the targeted devices are with or without the Configuration Manager client, and then select the supported platforms to choose between different versions of the operating system (OS). Depending on the platform that is selected, different options will be available to choose from. Selecting Windows Desktops and Servers (custom) will provide the greatest flexibility when creating your settings. Each setting is given a name, description, and a setting type to determine the detection method for where this setting exists on the PC.
- An Active Directory query
- An assembly
- A filesystem
- IIS Metabase
- A registry key and registry value
- Using a custom script
- A SQL query
- An XPath query
The following screenshot shows a Configuration Item using an integer registry value as the setting type for the detection method. The specific hive, key path, and value name are all specified:
The checkbox for Create the registry value as a REG_DWORD data type if remediated for noncompliant rules is selected. This allows the REG_DWORD data type to be created if the Configuration Baseline is set to remediate noncompliant rules.
The following screenshot shows a compliance rule with the condition that says the value name must be set to zero to be compliant. Choose the Remediate noncompliant rules when supported checkbox to force this setting onto the PC if found to be noncompliant:
Creating Configuration Items can be compared to creating and organizing GPOs. One example is a Configuration Item for Google Chrome policy settings. You can specify the different policies and set their values using registry keys with a Configuration Item and then assign that Configuration Item to a Configuration Baseline to report on compliance and take any remediation actions. Later in this chapter, in the Creating a Configuration Baseline from a GPO section, we will walk through exporting a prebuilt GPO and creating a Configuration Item from its settings.
Let's walk through how you create a Configuration Item in Configuration Manager.
Creating a Configuration Item
- In the Configuration Manager console, go to Assets and Compliance, choose Compliance Settings, and select Configuration Items. Click on the Create Configuration Item button in the toolbar.
- Give it a friendly name, for example, Google Chrome – Computer. Enter a description and choose Windows Desktops and Servers (custom) under the settings for devices managed with the Configuration Manager client.
- Keep all versions selected in the Supported Platforms section as they are.
- Choose New in Specify settings for this operating system and set the following options:
Name: Chrome – PasswordManagerEnabled
Description: Disable the Google Chrome password manager
Setting type: Registry Value
Data type: Integer
Hive Name: HKEY_LOCAL_MACHINE
Key Name: Software\Policies\Google\Chrome
Value Name: PasswordManagerEnabled
- Select the Create the registry value as a REG_DWORD data type if remediated for noncompliant rules option.
- Click on the Compliance Rules tab and choose New. Set the following options in the Specify rules to define compliance conditions for this setting menu:
Name: PasswordManagerEnabled – 0 – Dword
- In the Setting must comply with the following rule section, choose Equals from the drop-down list and enter the value of 0.
- Select both options to Remediate noncompliant rules when supported and Report noncompliance if this setting instance is not found.
- Choose Information for Noncompliance severity for reports.
- Choose OK and then OK again. Click on Next to see your compliance rule.
- Click on Next to view the summary and create the Configuration Item.
The following screenshot shows the Google Chrome - Computer Configuration Item we created among many other Configuration Items. You can double-click on it to open the properties to add new settings or edits made:
Now that we have covered how to create a Configuration Item, let's look at building a Configuration Baseline using this Configuration Item to remediate any noncompliant configurations.
Building a Configuration Baseline
A Configuration Baseline can contain single or multiple Configuration Items, other baselines, or software updates that are used for evaluation. A Configuration Baseline is assigned to collections where each device downloads it and assesses it against its current configuration. The following screenshot is the Configuration Manager applet from the control panel on a workstation. It shows all of the Configuration Baselines and the Compliance status for each baseline:
- In the Configuration Manager console, go to Assets and Compliance, Compliance Settings and choose Configuration Baselines. Click on Create Configuration Baseline from the top toolbar.
- In the Create Configuration Baseline dialog box, enter the following settings:
Name: Google Chrome
Description: Google Chrome computer policies
- Click on Add and choose Configuration Item.
- In the Add Configuration Items dialog box, find the Google Chrome – Computer Configuration Item that we created earlier. Select it and then click on Add. Select OK.
- Click on OK to commit the changes.
The Always apply this baseline even for co-managed clients checkbox is important to note. Selecting this option will force the baseline to evaluate the device, even if the device configuration workload is configured to Intune in the co-management settings.
- Select Google Chrome Configuration Baseline, and click on Deploy in the toolbar to open the Deployment menu.
- Select the checkboxes for Remediate noncompliant rules when supported and Allow remediation outside the maintenance window.
- Click on Browse next to Select the collection for this Configuration Baseline deployment.
- Click on the drop down and choose Device collections. Then, select the collection you wish to target. In this example, we have a device collection called All Workstations that targets all Windows workstations. Click on OK. We strongly encourage you to test a smaller collection first before scheduling a larger rollout.
- Under Schedule, keep Simple schedule selected and change the Run every option to 3 days. Click on OK.
For non-mission critical baselines, we find that between 1 and 3 days is a good middle ground for policy evaluations. Keep in mind that the shorter the time interval, the more network traffic and strain is placed on the site server and its services.
In the following screenshot, you can see the menu options for Deploy Configuration Baselines:
Reporting on a Configuration Baseline
Configuration Manager is filled with built-in or "canned" reports. Let's look at a high-level view of the overall compliance of the Configuration Baseline we just deployed. Follow these steps to run the Summary compliance of a Configuration Baseline for a collection report:
- In the Configuration Manager console, go to Monitoring, click on Reporting, and choose Reports. Expand the Reports folder in the left-hand navigation to view the expanded tree view.
- Select the Compliance and Settings Management folder and choose the Summary compliance of a Configuration Baseline for a collection report to open the menu.
- Click on Values next to the Configuration Baseline name and select the Google Chrome baseline that we created earlier.
- Click on Values next to Collection, and choose a collection that you wish to report on. In this case, we will choose the collection we deployed earlier.
- Click on View Report to open the report.
We just learned how to create a Configuration Item, building and deploying a Configuration Baseline, and how to report on compliance. Next, let's take a look at assigning Endpoint Protection policies with Configuration Manager.
Assigning Endpoint Protection
Configuration Manager can manage Endpoint Protection policies for Windows Defender ATP and Windows Firewall. If you are using co-management, check where your workload settings are set in the co-management settings to determine whether you are using Intune or Configuration Manager to configure Endpoint Protection. With Assets and Compliance > Endpoint Protection, you can create the following types of policies:
- Antimalware policies are used to determine the actions taken by Endpoint Protection and include setting actions for the following:
--Default actions for how Endpoint Protection responds to detected threats.
--Real-time protection settings.
--Advanced settings such as notifications and when to delete quarantined files.
--Threat overrides for custom remediation actions.
--Cloud protection services allow the collection and sending of information regarding detected malware to Microsoft for analysis.
--Security intelligence updates.
- Windows Defender Firewall policies are used to enable Windows Defender Firewall for domain, private, and/or public profiles. You can choose to block all incoming connections on each and notify the user when Windows Defender Firewall blocks a new program.
- A Windows Defender ATP policy is used to onboard or offboard devices to the Microsoft Defender Advanced Threat Protection (ATP) service. You will need to generate a configuration file from the Microsoft Defender ATP portal to deploy to your devices.
- Windows Defender Exploit Guard policies allow you to manage the settings around attack surface reduction, controlled folder access, exploit protection, and network protection.
- Windows Defender Application Guard policies set the protection used by Hyper-V virtualization, which protects your end users by opening untrusted sites in an isolated container with Microsoft Edge.
- Windows Defender Application Control is a set of policies that dictates which trusted executable files, system files, file paths, and drivers can run on Windows 10 devices.
If you are using the Windows Defender ATP service, machines will need to be onboarded with an onboarding package. We will cover onboarding Windows devices to the Defender ATP service in Chapter 9, Keeping Your Windows Client Secure. Next, let's dive into Intune and learn how to create and enforce policies with Mobile Device Management (MDM).
A great benefit of managed devices is the ability to set compliance requirements that must be met to ensure security settings are in place and the device is compliant. When a Windows device is evaluated, Intune leverages Azure AD to keep a compliance status. This status, coupled with conditional access, allows administrators to block or apply restrictions on devices until they meet the rule requirements set by the policies.
The following screenshot is the device compliance overview of a managed Intune device. There are six separate compliance policies assigned to this device used in the compliance evaluation:
There are three actions that can be configured for devices that are noncompliant, and they are as follows:
- Mark a device noncompliant.
- Send an email to the end user.
- Remotely lock the noncompliant device.
The Device compliance evaluation status can then be used as an access condition for a conditional access policy; for example, a conditional access policy to all users that says access to SharePoint Online requires multi-factor authentication or a compliant device. If the user's device falls out of compliance, then they must use multi-factor authentication to access SharePoint Online even if on a company-issued device.
We recommend configuring Windows 10 compliance policies for the following evaluations:
- Device Health Attestation evaluation rules requiring BitLocker, Secure Boot, and Code Integrity
- Minimum OS version
- Block simple passwords
- Require a Trusted Platform Module (TPM) to be present
- Require the Microsoft Defender AV solution to be enabled and require real-time protection
- Require a machine risk score to be medium or lower from the Microsoft Defender ATP service
Co-management customers can also leverage Configuration Manager compliance as an evaluation condition for devices.
Configuring a device compliance policy
- Log in to https://devicemanagement.microsoft.com.
- Choose Devices and select Compliance Policies from the Policy section.
- Click on Create Policy from the toolbar and provide these inputs:
Name: Windows 10 – Minimum Version
Description: Windows 10 Version compliance
Platform: Windows 10 and later
- Click on Settings and choose Device Properties. In the Minimum OS version, enter 10.0.18363.628 and click on OK.
- Click on OK again and select Actions for noncompliance.
- Let's leave Mark device noncompliant as the action, but note that this is where you can add Send email to user as an additional action.
- Click on Create to build the policy.
- Select your policy from the list of compliance policies. In the Manage section, choose Assignments, and select the Azure AD user security group you wish to target.
Next, let's look at device configuration profiles in Intune and some of the settings that can be applied to Intune managed devices.
Configuring a device configuration profile
Device configuration profiles are where the majority of settings are configured for device security and personalization settings. Examples of the profile types that can be configured include the following:
- Administrative Templates for ADMX-backed policies such as Group Policy preferences that exist today
- Device restriction profiles that contain security features such as password settings, privacy, and personalizations
- Delivery optimization to control the bandwidth and caching for Windows Update for Business
- Device firmware settings for vendors that support the Device Firmware Configuration Interface (DFCI) in UEFI
- Endpoint Protection to configure features of Microsoft Defender such as Firewall, SmartScreen, Exploit Guard, and Encryption
- Trusted, SCEP, and PKCS certificate deployments
- VPN configurations
- Custom profiles for deploying OMA-URIs that have yet to be implemented in the UI
Like compliance profiles, device profiles are assigned directly to Azure AD user or device groups. Profiles that use the Windows 10 and later platforms option also allow the use of applicability rules. Here, they can define a criterion that a device must meet for the settings to apply. Currently, these rules support the property values of the OS version or edition. The following screenshot demonstrates an applicability rule to only assign the profile if the device version is between Windows 10, version 1809 and 1909:
For co-management customers, device configuration profiles will not apply to your devices unless the device configuration workload is configured for Intune. This setting can be found in Configuration Manager co-management settings.
Co-management workload settings can be found in Configuration Manager by going to Administration > Cloud Services and selecting Co-management. The CoMgmtSettingsProd Configuration Item has a Workloads tab with sliders for different workloads.
For more information about how to switch Configuration Manager workloads to Intune, refer to https://docs.microsoft.com/en-us/configmgr/comanage/how-to-switch-workloads.
Next, let's look at where to deploy custom PowerShell scripts to your devices.
Deploying PowerShell scripts
The PowerShell scripts node can be found under the Devices > Policy section. In order to use PowerShell scripts, devices must be enrolled in Intune and joined to Azure AD. On the local device, the PowerShell scripts function relies on the Intune Management Extension service to check for and run scripts. It can be found in the Services app. For devices that are under co-management, be sure to set the app-specific workload to Intune. For more information about PowerShell scripts in Intune, refer to https://docs.microsoft.com/en-us/mem/intune/apps/intune-management-extension.
Next, let's take a look at how to use the Administrative Templates device configuration profile type and security baselines.
Using Administrative Templates
Included in device configurations for Windows 10 and later platforms is the Administrative Templates profile type. These Windows settings are familiar to the GPO settings available in Active Directory, but they are delivered through Intune. Administrative Templates include policies for Windows, Office, and Microsoft Edge.
Assignments are applied to both user and device groups depending on whether the policy is scoped to user-specific or computer-specific settings. Currently, not all the Group Policy Administrative Templates are available yet, and legacy settings for older versions of Windows have purposely been omitted.
When browsing through Administrative Templates, use the familiar path of a group policy setting to find the appropriate path in Intune. For example, in the following screenshot, polices found traditionally in Computer Configuration \ Administrative Templates \ Windows Components \ Windows Remote Management can be found by using the same path starting with Windows Components:
Administrative Templates are great as they provide a match to commonly used GPO policies. Like Group Policy, manually configuring each setting to meet your baselines can be a tedious task. In order to help alleviate some of the administrative overhead of manually setting policies there are security baselines in Intune. Next, let's look at enforcing Intune security baselines.
Enforcing Intune security baselines
Available in Intune are preconfigured groups of Microsoft's recommended Windows 10 security settings known as security baselines. They can be thought of as the cloud equivalent to the recommended security baselines available in the Windows Security Compliance Toolkit. Security baselines can be targeted at both groups of users and devices for Windows 10 and later platforms. Whenever an updated version of a recommended baseline is released by Microsoft, you can compare the new release to your current baseline. When you are ready to append your baselines to the newly released policies, a new profile is not needed. All you need to do is change the instance version to deploy the updated policies.
Intune security baselines provide recommendations for Windows 10 MDM, Microsoft Defender ATP, and Microsoft Edge. With built-in monitoring, you can get insights about how compliant your devices are to the security configurations you set for them. The security baseline posture overview shows how many devices match the baseline, do not match, are misconfigured, or are not applicable compared to the scope of the policy assignment.
In this example, we are going to create a Microsoft Defender ATP baseline using Intune. Follow these steps:
- Go to the Microsoft Endpoint Manager at https://devicemanagement.microsoft.com.
- Log in with an account that has Intune administrative rights.
- Go to Endpoint Security.
- Choose Security baselines.
- Select the Microsoft Defender ATP baseline.
- Select Create Profile.
- Give it a friendly name such as Windows 10 MDATP Baseline.
- Microsoft already preconfigures its recommended settings based on its security analysis. Click on Next to accept the defaults or make any modifications to fit your custom baseline policies.
The following screenshot shows the Microsoft Defender ATP configuration settings that are available when creating a security baseline policy in Intune:
- On the Assignments page, decide which selected groups to include or exclude.
- Review + Create.
To recap, we just covered creating compliance policies and applying configurations to your devices both with Configuration Manager and Intune. We learned about creating Configuration Items and assigning them to Configuration Baselines for evaluation and how to report on them. Then, we looked at applying device configuration profiles in Intune including Administrative Templates and Microsoft-recommended Intune security baselines. Next, let's look at using the Microsoft Security Compliance Toolkit to build your baseline policies and analyze them with the Policy Analyzer tool.
Security baselining is the practice of implementing a minimum set of standards and configurations within your environment. More specifically, it involves capturing a minimum configuration for your Windows devices. Building a baseline provides a minimum defined standard that will help ensure a more secure environment as you deploy systems and devices within an organization. We covered building standards for security baselines in Chapter 2, Building a Baseline. However, here, we want to focus specifically on Windows using the Microsoft Security Compliance Toolkit to create, apply, and analyze your Windows baselines.
We will be using the recommended baselines from the Microsoft Security Compliance Toolkit to build our policies. When downloading the toolkit, the following options are available for selection from the Microsoft download site:
- Windows 10 security baselines
- Windows Server security baselines
- Microsoft Office security baselines
- Microsoft Edge security baselines
- Policy Analyzer and Local Group Policy Object (LGPO) tools
For more information about the tools that are included, refer to https://docs.microsoft.com/en-us/windows/security/threat-protection/security-compliance-toolkit-10.
A direct download to the toolkit can be found at https://www.microsoft.com/en-us/download/details.aspx?id=55319.
The following describes what's included in the security baselines ZIP file(s):
- The documentation folder includes an Announcement.xml file that summarizes recommendations along with a What's New section. It also includes PolicyRules files that are useful when running the Policy Analyzer tool and Excel files that list the configurations and settings in spreadsheets.
- The GP Reports folder lists the outputs of each GPO in HTML format.
- The GPOs folder contains the globally unique identifiers (GUID) for each GPO setting.
- The Scripts folder contains helpful scripts that can be used to map the GPO GUIDs to friendly names or to import baselines into Active Directory.
- The Templates folder includes ADMX and ADML files for group policies that are referenced in the new baselines and might not be included in the latest available download of Administrative Templates.
Comparing policies with Policy Analyzer
The Policy Analyzer tool is useful for comparing GPOs against other GPOs, the local policy settings on the computer, and the local registry. If you have downloaded the Microsoft Security Compliance Toolkit already, ensure you have selected PolicyAnalyzer.zip and Windows 10 Version 1909 and Windows Server version 1909 Security Baseline.zip at a minimum. Extract them if you wish to follow along.
Let's compare the out-of-box Windows 10 settings to the Windows 10 1909 computer security baseline by following these steps:
- Open PolicyAnalyzer.exe as an Administrator.
- Click on Add, choose File, and select Add files from GPO(s)….
- Open the directory where you extracted the Windows 10 security baselines, and select the folder with the GUID for the MSFT Windows 10 1909 – computer policy.
There are many GUIDs inside the GPO folder of the extracted baseline. Clicking on the gpreport.xml file will display the friendly name.
- In the Policy File Import menu, click on Import. Give it a friendly name such as MSFT Windows 10 1909 – Computer, and click on Save.
- This will bring you back to the main menu of Policy Analyzer. Ensure the policy you imported is selected and select the Compare Local Registry option. Click on the View/Compare button to bring up the Policy Viewer.
The column headings are straightforward and provide an overview of the policy group or registry key as well as the policy setting. If you click on a row, detailed information will be presented about the policy in a Details pane. Here are a few notes to keep in mind about the menu options:
- Selecting View > Show only Differences will display all of the differences between the recommended baseline and what's currently set in the local registry.
- Selecting View > Show only Conflicts will display settings that differ from the recommended baseline to the current setting. These will be highlighted in yellow.
- Selecting Export > Export table to Excel will export only the table with differences or conflicts.
- Selecting Export > Export all data to Excel will include the Details pane explanation.
The following screenshot shows the Policy Viewer output after clicking on the View/Compare option. Anything highlighted in yellow is a conflict between the GPO and the current setting in the local registry:
Creating a GPO from the baseline recommendation
Let's create a GPO from the Windows 10 1909 Computer baseline. To do this, we will need to connect to a workstation that can edit Group Policy and has access to the downloaded Windows 10 baseline files from the toolkit. Open the Group Policy Management console, and follow these steps:
- Select an Organizational Unit (OU) that contains the systems you wish to target. Right-click on it and choose Create a GPO in this domain, and Link it here….
- Give it a friendly name such as Windows 10 – 1909 Computer.
- Click on the Group Policy Objects folder and find the policy that you created earlier. Right-click on it and choose Import Settings.
- Click on Next a few times until you get to the Backup location where you can choose a backup folder. Browse to the GPOs folder inside the downloaded and extracted baseline: Windows 10 Version 1909 and Windows Server Version 1909 Security Baseline.zip. Click on Next and then select MSFT Windows 10 1909 – Computer from the list of backed-up GPOs.
- Click on Next until you get to the Migrating References menu, and select Copying them identically from the source. Click on Next and then Finish.
If the Group Policy imported successfully, it will show GPO: Windows 10 -1909 Computer…Succeeded. Now that the policy is imported, let's modify the default settings to change the behavior of the elevation prompt for standard users and set to prompt for credentials on elevation:
- Right-click on the GPO and choose Edit. Navigate to Computer Configuration > Window Settings > Security Settings > Local Policies > Security Options. Find the User Account Control: Behavior of the elevation prompt for standard users policy and double-click on it. Change the drop down to Prompt for credentials on the secure desktop. Click on OK.
This setting will allow us to open the Command Prompt window as an administrator if we are logged on as a standard user. If we left this policy, the user would receive a blocked notice and would need to contact the IT administrator.
Right-click on the GPO and choose Save Report to export a handy HTML of all the settings that will be applied.
Let's connect to a workstation that is targeted by the new policy to validate it. Follow these steps to run a Resultant Set of Policies (RSOP) and use Policy Analyzer to compare the baseline GPO to the applied settings:
- Open Command Prompt and run gpupdate /force to check for policy updates.
- Next, open Command Prompt as an administrator and type in gpresult /r /scope computer. If the GPO was applied, you should see the Windows 10 1909 – Computer policy listed like in the following screenshot of Applied Group Policy Objects:
- Now that we have confirmed the policy was applied, open PolicyAnalyzer.exe as an administrator on the workstation.
- Select the MSFT Windows 10 1909 – Computer policy definition we created earlier, and then select Compare local registry. Click on View / Compare.
- Click on View, then choose Show only Conflicts. Note the conflicts from the policy that we modified before running the RSOP.
The following screenshot shows a conflict between the recommended baseline policy and the modification we made to allow a prompt for credentials using a standard account. Also enabled on this PC is to allow a PIN to be used to log on to the domain:
If choosing the Local Policy option, Policy Analyzer will automatically create a policy definition file to use for comparison later.
We strongly recommend that you test these settings out before deploying them in a production environment so that you can truly understand the effects they will have on your systems and your end user's experience.
Next, let's take a look at how you can use Configuration Manager to report compliance on your security baseline and even force remediation for noncompliance. This is extremely useful in co-management scenarios when devices are Azure AD joined and do not use Group Policy.
To create a Configuration Baseline from the settings of a GPO, we need to export the GPO and create a Configuration Item from the settings. For this task, we are going to be using the Convert-GPOtoCI.ps1 PowerShell script from the SamMRoberts GitHub repository. To download the PowerShell script, go to https://github.com/SamMRoberts/Convert-GPOtoCI and click on Clone or Download to download the ZIP file. It is recommended that you read the README.md file for full usage instructions, including syntax. Follow these steps to import the GPO settings to a Configuration Item:
- Extract the downloaded ZIP file to a system that has access to manage Group Policy Objects and connect to Configuration Manager PowerShell.
- Open PowerShell as an administrator and go to the extracted directory by typing in CD "PATH/TO/Extracted/Folder" and replacing the PATH in quotes with the actual file path of the extracted script. Press Enter.
We are going to target the Windows 10 – 1909 Computer policy that we created earlier. You will need the Fully Qualified Domain Name (FQDN) of your domain and the three-letter site code in order to create the Configuration Item. We will also be using the -Remediate option to allow the settings to be remediated if noncompliance is found.
- In PowerShell, type in the following code and replace the parameters to fit your site and domain settings: .\Convert-GPOtoCI.ps1 -GpoTarget "Windows 10-1909 Computer" -DomainTarget mydomain.prod.com -siteCode ABC -Remediate.
- If prompted, press R to run once.
Depending on the script execution policies, you may see a different security warning. To learn more about execution policies, please refer to https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_execution_policies.
The script will process the targeted GPO. As shown in the following screenshot, it found 86 keys and 100 values:
- Open the Configuration Manager console and navigate to Assets and Compliance > Compliance Settings > Configuration Items. You should see the Windows 10 – 1909 Computer Configuration Item that was created by running the script.
If you open the properties of the Configuration Item and click on the Settings tab, you can see all of the registry values that were imported, as follows:
Click on the Compliance Rules tab and open a rule. You can see that Remediate noncompliant rules when supported and Report noncompliance if this setting instance is not found are both checked.
The severity of the noncompliant items can be changed by specifying the severity setting in the PowerShell command. The default value is Information.
- Navigate to Assets and Compliance > Compliance Settings > Configuration Baselines, click on Create in the toolbar, and then select Create a Configuration Baseline.
- Give it a friendly name such as Windows 10 Security Baseline. Give it a description.
- Click on Add under the Configuration data and choose Configuration Items. Select the Windows 10 – 1909 Computer Configuration Item that was just created and click on Add. Choose Ok. Choose OK back in the Create Configuration Baseline menu to build it.
- Select the security baseline and click on Deploy in the toolbar. We will leave the defaults as they are since the workstations being targeted are domain-joined, and we don't want to enforce policies from two sources. Click on Browse to select a collection to target. We clicked on the drop down to switch to Device collections and chose our All Workstations collection, which contains Windows 10 workstations. Click on OK.
- Change the Run every schedule to 1 day. We will want to ensure this policy is being evaluated frequently. Click on Ok.
Let's head over to our workstation and check whether the baseline is being evaluated.
- Open Control Panel, filter to small items, and choose the Configuration Manager control panel applet.
- Click on the Configurations tab and check for the Windows 10 Security Baseline. Select it and click on Evaluate.
From the Configuration Manager control panel applet, choosing the Actions tab and running the Machine Policy Retrieval & Evaluation Cycle will force the PC to check Configuration Manager and download any new policies.
As shown in the following screenshot, the baseline policy is reporting as Non-Compliant:
- Click on the View Report button to look at an HTML view of the conflicts.
During the import of the GPO to the Configuration Item, some settings might have a null value in the expression and may need to be manually updated for proper compliance to be reported. In the HTML compliance report, the expression column will display Equals, but there will be no value included. Typically, there are only a few settings and they can quickly be remediated by cross-checking the actual GPO, the registry key on the local device, and the compliance rule from the setting within the Configuration Item.
We have just covered how to use the Microsoft Security Compliance Toolkit to build security baselines. We learned how to use the Policy Analyzer tool to compare the Microsoft-recommended baselines to the current configurations on a Windows workstation. Next, we created a GPO from the baseline and deployed it to an OU in Active Directory. Finally, we imported the GPO to a Configuration Manager Configuration Item using the SamMRoberts GitHub PowerShell script that can be used in a security baseline for mitigation of noncompliant settings or reporting purposes.
Next, we will cover the best practices for securely connecting to servers remotely and provide an overview of two Azure services that ensure secure connectivity and Just-in-Time (JIT) access.
There should be extra attention paid when setting up and configuring remote access to your environment. Remote access should be very strategic and the footprint extremely small. Access to your environment directly over the internet should be limited. This exposure poses significant risks and could easily allow an attacker to gain access to your servers. Ensure your standards cover a secure and locked-down remote management strategy, and limit or eliminate internet access to your servers. This section will provide more detail about several tools that you can use to enforce a secure remote access policy.
Remote management is a critical task that is used to support both your end users and the infrastructure within your environment. There are many methods available to remotely manage and access your environment. Your support desk will have some form of remote management tools in place to access end user devices. Ensure whatever remote support tool is selected is thoroughly reviewed and provides a secure connection to your support staff. Additionally, ensure that no one can connect to your user's device without the user providing permission, as this could become a liability issue.
For your infrastructure, your support staff most likely leverages Remote Desktop Protocol (RDP) or PowerShell to manage your Microsoft servers and services. Just like support for your end users, there are many options available in which to access your servers for remote management. It is important, as an organization, that you define and enforce policies that specify exactly how your support staff handles these remote management tasks. Consider the following recommendations when building your remote access strategy:
- Never allow direct remote management from the internet:
--Use a jump server or use VPN at a minimum.
--Change the default RDP port from 3389.
- Enforce strong access policies:
--Ensure separate accounts are used to access servers.
--Enforce multi-factor authentication.
- Enforce encryption and secure access for remote management and limit where connections can originate from.
- Minimize the number of support staff accessing your infrastructure and servers.
- Monitor and audit all access to your infrastructure and servers.
To limit interactive logons to servers, you can deploy Remote Server Administration Tools (RSAT) to administrative workstations: https://docs.microsoft.com/en-us/windows-server/remote/remote-server-administration-tools.
Next, we will review JIT access and Azure Bastion services to provide additional security within your remote access management strategy.
As a feature of Azure Security Center (ASC) standard, JIT access works by creating or modifying Network Security Group (NSG) and Firewall rules in Azure to protect access at the network layer. The ports that you wish to be available are configured in the JIT access configuration. When a user needs just-in-time access, they issue an access request through ASC. Once approved, ASC automatically adds an inbound rule opening the configured ports on the resources' NSG or firewall. The traffic is allowed for the duration of time specified in the request and once the time allotment expires, the NSG rules are returned to the previous deny state. For a user to use the request access functionality through JIT, a custom role-based access control (RBAC) role might need to be created and assigned directly to the user. It must contain these actions:
We covered creating a custom role in Chapter 3, Server Infrastructure Management, implementing role-based access control. To read more information about the resource policy providers specified earlier, visit https://docs.microsoft.com/en-us/azure/role-based-access-control/resource-provider-operations.
These policies must be scoped to the subscription or resource group in which the VM and network interface reside.
Further information about Azure Security Center JIT access can be found at https://docs.microsoft.com/en-us/azure/security-center/security-center-just-in-time.
Let's look at creating a JIT access rule to allow RDP over port 65001. In Chapter 6, Network Fundamentals for Hardening Windows, we covered modifying the default listening port for RDP to 65001 on a Windows Server 2019 host, in the Creating a network security group in Azure section. If you don't have Azure Security Center standard, you can enable a free 30-day trial and deploy the agents directly from the Security Center overview page in order to continue with the step-by-step instructions:
- Open Security Center by searching for it in the Azure portal.
- Click on Just in time VM access under Advanced Cloud Defense.
- In the Virtual Machines section, click on Recommended to view VMs that are recommended for JIT VM access to be applied.
The No Recommendation tab lists VMs that may either not be running or are not part of an NSG.
- Select the VM we previously modified when creating the custom RDP rule. Choose Enable JIT on 1 VMs.
- On the JIT VM access configuration page, the default port rules are already created. Let's add a new rule to accommodate the custom port of 65001.
JIT VM access configuration already has default rules for the following ports:
--Port 22 is common for SSH.
--Port 3389 is the default RDP port.
--Port 5985 and 5896 are WinRM ports.
- Click on Add and enter 65001 for the port number and choose TCP for the protocol. Leave Max request time at 3 hours. Click on OK.
- Click on Save.
Let's take a look at the new configuration. In the Azure portal, navigate to the VM used to configure JIT and click on Networking under Settings. In the following screenshot, notice a new inbound augmented security rule, called SecurityCenter-JITRule, that has all the ports specified in the configuration. By default, the action is set to Deny:
Security Center JIT rules default to a priority of 4096, which is the highest integer value that you can set in a custom security rule. If custom rules were created to allow RDP previously, modify the priority of the new Security Center rule to be a lower integer, or delete the previous rules in order to use JIT effectively.
- Navigate to Security Center in the Azure portal.
- Choose Just in time VM access under Advanced Cloud Defense.
- Under the Configured tab, select the VM to RDP into, and choose the Request Access button.
- Toggle the rule for port 65001 to On, and select My IP in the Allow Source IP column. We can leave the time range as 3 hours.
- Enter a request justification and choose Open Ports.
The following screenshot shows the custom port rule we created. During the access request, you can specifically choose the ports you need for connectivity:
The RDP over port 65001 is now active. Browse back to the VM network interface inbound port rules. A new Allow rule has been added, similar to the following screenshot, using your public IP as the source:
Following the approval of the ASC JIT rule, the source is configured from your public IP address. Network address translation in Azure allows the destination to the VM to be a private IP. In order to connect to this server with RDP, you may need to add the port number at the end of the IP address. In this example, 220.127.116.11:65001 would be used to create the connection and includes the custom port.
Next, let's look at using the Azure Bastion service to connect to a VM without having to expose it directly to the internet.
With Azure Bastion, you provision an isolated or bastion subnet directly inside your virtual network. This keeps all of the RDP or SSH traffic inside of your virtual network, so the protocols are not exposed over the internet. Now, VMs no longer require direct exposure to the internet with public IPs, which helps to protect these endpoints from threats such as port scanning. The Azure Bastion service always uses your resource's private IP address to create secured connections and significantly reduces the attack surface by minimizing what's exposed directly over the internet. Azure Bastion only supports RDP or SSH with HTML5 currently, but development is in the works to support other tools such as Remote Desktop Connection (MSTSC).
Let's look at configuring Azure Bastion. In order to enable the Azure Bastion service, a bastion subnet must be created inside your virtual network, named AzureBastionSubnet, with a minimum Classless Inter-Domain Routing (CIDR) range of /27 before continuing. To create the Bastion resource and connect to a VM, follow these steps:
- Log in to the Azure portal at https://portal.azure.com.
- Search for Bastions and select Bastions under Services.
- Click on Create Bastion.
- Select your Subscription, and choose a Resource group. We selected the resource group our VNET was in.
- Give it a friendly name and choose the region your resources are in.
- Select your virtual network and choose AzureBastionSubnet.
- Create a new IP address and give it a friendly name.
- Click on Review + Create. Then, select Create.
Azure Bastion does not support customized TCP ports. If you are using the VM configured earlier, the RDP listening port must be changed back to 3389 or you will receive a bad connection error. Additionally, NSG rules will need an allow rule to open access to the default 3389 RDP port, and any JIT access rules need to be accounted for or connections may be blocked.
To connect to a VM with Azure Bastion, follow these steps:
- Go to the Virtual Machines pane inside the Azure portal.
- Search for your VM and select it in order to bring it up in the overview pane.
- Click on Bastion under Operations.
- Enter the VM's administrator username and password and click on Connect.
You may have to allow popups if your pop-up blocker is enabled. The following screenshot is the Connect to virtual machine menu. Select the BASTION tab to connect:
Now that we have covered how to connect remotely to Windows servers with RDP, let's take a look at PowerShell. PowerShell has quickly become a standard for many administrative tasks, and there are a few security steps that should be taken to help secure its use.
PowerShell has become one of the most popular tools in the sysadmin's toolbox in recent years. Its uses range from the ability to batch processes and build tools to automating repeatable tasks. There are many importable modules that allow interaction with a range of services such as Azure AD and Exchange Online. As a result, PowerShell can be exploited as an attack tool due to this flexibility. It has close interaction with various OS system-level components, such as Windows Management Instrumentation (WMI), and can avoid detection as it's a commonly used process. Out of the box, there are limited security measures enabled for PowerShell, so let's discuss what we can do to help secure its use.
- PowerShell Transcription allows Windows to capture the input and output of PowerShell commands in text-based transcripts. PowerShell Transcription can be enabled through the following Group Policy and registry setting:
Computer Configuration / Policies / Administrative Templates / Windows Components / Windows PowerShell / Turn on PowerShell Transcription
Enable the policy and specify an output directory. Documents are the default output directory if nothing else is specified:
EnableTranscription DWORD equals 1.
OutputDirectory REG_SZ equals PATH TO DIRECTORY.
- PowerShell Script Block Logging enables the logging of all PowerShell script blocks in the Event Viewer. PowerShell Script Block Logging can be enabled through Group Policy, Intune Administrative Templates, or the registry:
Computer Configuration / Policies / Administrative Templates / Windows Components / Windows PowerShell / Turn on PowerShell Script Block Logging
Enable the policy and select Log script block invocation start/stop events for additional logging:
EnableScriptBlockLogging REG_DWORD equals 1.
EnableScriptBlockInvocationLogging REG_DWORD equals 1.
Additionally, there are Group Policy settings to enable module logging. If enabled, the modules must be added to the list of module names in the policy setting, and anything after the pipeline for events of the specified modules will be captured in the Event Viewer.
If using Log Analytics in Azure, you can choose to collect events from the Microsoft-Windows-PowerShell logs under Advanced settings > Data in your Log Analytics workspace. This will allow you to configure alerts based on the events or forward them to a Security Information and Event Management (SIEM) solution for monitoring.
Consider expanding the Windows Event log size if enabling script block logging to avoid logs being overwritten too quickly.
The PowerShell Constrained Language Mode is used to lock down which "types" can be executed from within a PowerShell session. Some of the default restrictions of constrained language mode include the usage of most COM objects, using Add-Type to load arbitrary C# code or Win32 APIs, and .NET methods that are not of the allowed types. To view the list of allowed types along with a detailed definition of the constrained language mode, open PowerShell and run Get-Help about_ConstrainedLanguage.
The constrained language mode is designed to support User Mode Code Integrity (UMCI) policies though Windows Defender Application Control (WDAC) and Device Guard for enforcement. Specific scripts or even your code-signing authority can be added to the WDAC policy, which allows them to run in full language mode if constrained language is too restrictive. Alternatively, constrained language mode can be set by creating an environment variable via a GPO with a __PSLockdownPolicy value of 4. However, this can easily be circumvented if the user has the right to override these settings.
To check the current language mode of the execution context in PowerShell, run this command:
To read more about the different types of language modes in PowerShell, refer to https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_language_modes?view=powershell-5.1.
Next, let's look at enabling script execution. For best practice, it's recommended that you only allow RemoteSigned scripts to be executed or even use the default restricted mode.
PowerShell execution policies determine which types of scripts can run on the system. While not directly used to deny users from running commands, execution policies are designed to help prevent the unintentional execution of scripts, and they can be circumvented by using the command line. A few examples of script execution policies include the following:
- Restricted is the default for Windows workstations and allows individual commands but prevents scripts from running.
- Bypass is where scripts and commands run freely without warning.
- RemoteSigned requires scripts to be signed by a trusted publisher to run if downloaded from the internet.
- AllSigned requires all scripts to be signed by a trusted publisher, including ones built locally. PowerShell will prompt you before allowing the script to run from unknown publishers.
To learn more about script execution policies in PowerShell, type in Get-Help about_execution_policies. It is recommended that you keep the default of Restricted enabled or use RemoteSigned. PowerShell script execution can be set using Group Policy, Intune Administrative Templates, or the registry. Use the following location for Group Policy or Intune:
- Navigate to Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell > Turn on Script Execution
- Choose Allow local scripts and remote signed scripts to set the MachinePolicy scope to RemoteSigned.
You can list all of the execution policy modes for each scope by typing get-executionpolicy -list in PowerShell. The following screenshot shows five different scopes. If all scopes are set to Undefined except for one, then that is the current effective policy. If setting the script policy through a GPO, as in the following, that will remain the more effective scope:
To recap, we just covered PowerShell and how to enable transcription logging for monitoring events, discussed the constrained language mode, and covered the different types of execution policies for protecting your systems.
In this chapter, we covered what administration and remote management are and their importance for your Windows environment. We started with an overview of device administration and the different ways in which Windows devices can connect and register to your domain. We then learned how to enforce compliance and configured settings on your devices using MDM with Configuration Manager and Intune.
Next, we walked through building a Windows 10 security baseline using the Microsoft Security Compliance Toolkit. We discussed using the Policy Analyzer tool to compare settings and created a GPO from the recommended baseline and assigned it to an Active Directory OU. Then, we learned how to take existing GPOs and convert them into Configuration Manager Configuration Items to both remediate noncompliant settings or use monitor mode for reporting purposes. Finally, we reviewed remote management and provided details on how to deploy Azure Security Center JIT access and Azure Bastion. The chapter finished with several ways to secure and audit PowerShell events.
Moving on to Chapter 9, Keeping Your Windows Client Secure, we will cover Microsoft Defender ATP, learn how to onboard machines, and discuss deploying and configuring Windows Update for Business. Then, we will cover securing and hardening Windows with various configurations before finishing the chapter with Windows 10 privacy settings and the importance of data labeling and classification.