Hardening domain controllers

Domain controllers are the vaults that host the “crown jewels” of any Windows Server network. Attackers who can compromise a domain controller can compromise the Active Directory instance hosted on that domain controller. This gives attackers the ability to grant themselves any Active Directory domain privilege they desire. You want to ensure that your organization’s domain controllers are as secure as possible. Some obvious steps you can take to secure your organization’s domain controllers include:

• Only run the Server Core installation option. The Server Core installation option of Windows Server has a smaller attack surface than the Server with Desktop Experience version of Windows Server.

• Only host AD DS and DNS on domain controllers. Generally, you should also avoid hosting workloads other than DNS on a computer configured as a domain controller as a further way of minimizing the attack surface. The more workloads a domain controller hosts, the more components there are for an attacker to attempt to exploit to gain control of that computer.

• Run the most recent version of Windows Server. Domain controllers should always run the most recent version of Windows Server. When a new version of Windows Server is released, the first thing you should do is deploy domain controllers running the new operating system and retire domain controllers running previous versions of Windows Server. Newer versions of Windows Server are inherently more secure than previous versions of Windows Server.

• Stay up to date with monthly software updates. You should ensure that you keep domain controllers patched with the most recent software updates. You should aggressively update domain controllers. As you should not run workloads beyond Active Directory and DNS on a domain controller, you are unlikely to encounter compatibility problems with new software updates (though you should still test on one domain controller before rolling out to all of the others).

• Enable Device Guard. Only authorized applications and processes should be able to run on an Active Directory domain controller. Application whitelisting is the process by which only authorized applications and processes can be run; any application or process that is not explicitly authorized will be unable to run. The most effective method of applying application whitelisting is enabling Device Guard. You’ll learn more about Device Guard in Chapter 20, “Security systems and services.”

• Block domain controllers from directly communicating with hosts on the Internet. You should configure perimeter network firewalls so that domain controllers on internal networks can’t directly communicate with hosts on the Internet. Software updates from domain controllers should be obtained from sources on the internal network, such as a WSUS server.

• Only accept administrative connections from authorized hosts. Domain Controllers should only accept RDP and remote PowerShell sessions from specific authorized hosts. These hosts should be privileged access workstations or jump servers, which you learned about in Chapter 1, “Administration tools.”

• Keep domain controllers in domain controllers OU. Avoid moving domain controllers out of the default domain controllers OU because this can lead to unexpected configurations being assigned through group policy.

• Ensure that Directory Services Restore Mode (DSRM) passwords are changed regularly. This password allows out-of-band access to a domain controller. Passwords should be different for each domain controller; passwords should be updated every couple of months; and passwords should be stored in a secure location, such as a safe.

Least privilege

Least privilege is the practice of assigning only the minimum required privileges to an account for the account to perform its assigned tasks. Put another way, accounts should not be assigned rights and privileges in excess of those required to perform the specific tasks for which the account is used.

The benefit of using least privilege is that in the event that an attacker manages to compromise an account, that attacker is limited to acting with the privileges assigned to that account. Least privilege also reduces the chance that damage might inadvertently be done to a system. For example, an account used for backup and recovery can’t be used to add or remove software from the server if that account doesn’t have permission to do anything beyond backup and recovery.

When it comes to assigning privileges, a very bad habit of many IT professionals is to simply add an account to the local Administrators group on the computer where the privilege is required. This is especially true with service accounts where proper procedure is to edit the local security group policies and assign very specific rights; however, many administrators take a quick shortcut and assign all necessary rights by adding the service account to the local Administrators group. This is one of the reasons that attackers go after service accounts, which often use a single, unchanging, and organization-wide password and that also are members of the local Administrator groups on which they are installed.

Role-Based Access Control

Role-Based Access Control (RBAC) operationalizes the least-privilege principle. Instead of having all-powerful administrator accounts that can perform any task on any system, you instead parcel out administrative privileges that limit what an account can do and where an account can do it.

For example, rather than giving help desk support staff the ability to reset the passwords of any user in the domain, you instead delegate them the right to only be able to reset the passwords of user accounts in a specific organizational unit. This way, you allow the support staff to reset the passwords of a specific class of user account; for example, you could grant support staff the authority to reset passwords that are used by people in one department without giving them the ability to reset the passwords of domain administrator accounts.

You delegate privileges for organizational units in Active Directory using the Delegation Of Control Wizard, as shown in Figure 19-1.

Password policies

Account policies include both password policies and account lockout policies. You configure the domain password and lockout policies by configuring the default domain GPO. You can override the domain policies for specific security groups or user accounts using fine-grained password policies. You configure fine-grained password policies using the Active Directory Administrative Center console.

Default password policy settings include:

• Number Of Remembered Passwords. Users cannot change their passwords to a password remembered by the system. By default, Active Directory remembers the previous 24 passwords that have been used by an account.

• Maximum Password Age. This is the maximum amount of time in days that a password can remain the same before it needs to be changed. The default value is 42 days.

• Minimum Password Age. This is the minimum amount of time in days that a newly changed password must be kept. This policy prevents users from cycling through password changes to exceed the password history setting, so they can return to using the same password.

• Minimum Password Length. This is the minimum number of characters required for a password. The default is 7. Services such as Azure now require a minimum of 12 characters for administrator account passwords on IaaS virtual machines.

• Password Complexity Requirement. This setting determines whether passwords must include three of the four following characteristics: uppercase letters, lowercase letters, numbers, and symbols. This setting is enabled by default.

Lockout policy determines:

• The period of time an account is locked out when a user enters a specific number of incorrect passwords in a specific amount of time. The default is that an account is not locked out when incorrect passwords are entered. This means that an attacker or someone who is just forgetful can brute-force guess passwords without any lockout occurring.

• The number of incorrect passwords that trigger a lockout over a specific period of time. When configuring this policy, you should allow users to make a reasonable number of guesses. If you don’t, you’ll end up flooding the service desk with password reset calls.

• The amount of time that must elapse before the account lockout counter is reset. A correctly entered password also resets the lockout counter.

Account security options

There are additional security options that you should consider configuring for highly privileged accounts. These include configuring the following settings:

• Logon Hours. Use this setting to configure when users can use an account. AD DS does not authenticate someone attempting to sign in outside of these hours. By default, accounts are configured so that users can sign in at all times. Consider configuring privileged accounts so that users can use them only at specific times. This stops a user from signing in after hours, either specifically or with a compromised account, to get up to no good when they assume that no one is watching. Organizations that do need to use privileged accounts to perform after-hours maintenance tasks can create special accounts for those tasks, or they can temporarily modify an existing account.

• Logon Workstations. Use this setting to limit the computers to which a particular account can sign in. By default, users can use an account to sign in to any computer in the domain. Use this setting to ensure that users can use privileged accounts only on specific, specially configured administrative workstations or certain servers. Limiting which computers’ users can use an account reduces the locations where that account can be used.

• Password Never Expires. You should use this setting reluctantly when configuring privileged accounts because it absolves the account from the domain password policy. You can use products such as Microsoft Identity Manager to assist with password management for privileged accounts.

• Smart Card Is Required For Interactive Logon. Use this setting to ensure that a smart card must be present for the account sign in to occur. In high-security environments, you should deploy smart cards and enable this option to ensure that only an authorized person who has both the smart card and the account credentials can use the privileged account.

• Account Is Sensitive And Cannot Be Delegated. Use this setting to ensure that trusted applications cannot forward the account credentials to other services or computers on the network. Enable this setting for highly privileged accounts.

• This Account Supports Kerberos AES 256 Bit Encryption. Use this setting to allow Kerberos AES 256-bit encryption. Where possible, you should configure this option for privileged accounts and have them use this form of Kerberos encryption over the AES 128-bit encryption option.

• Account Expires. Use this setting to configure an expiration date for an account. Configuring privileged accounts with expiration dates ensures that privileged accounts do not remain available to use beyond when they are required.

When you join a computer to a domain for the first time, it creates a computer account in the Computers container. If you want to create an account in a specific container, you’ll need to pre-stage the computer account and place it in the appropriate OU. A pre-staged computer account must have a name that matches that of the computer that is joining the domain.

Computer accounts can be made members of the domain security group. This group membership influences how the Local System and Network Service accounts on the computer function. This is because, by default, these services use the computer’s credentials when interacting with resources on the network. This gives the computer account the rights and privileges assigned to any security group to which the computer is a member.

Computer accounts have automatically assigned passwords that are updated every 30 days. If a computer doesn’t connect to a domain within 30 days, a new password is assigned the next time a connection is established. If you disable a computer account, the computer cannot connect to the domain, and domain users are unable to sign in to the computer until the account is re-enabled.

Resetting a computer account removes the relationship between the computer and the domain. To fix this, you’ll need to either join the computer back to the domain, or reestablish the broken trust relationship using the following PowerShell command, specifying the credentials of a member of the Domain Administrator group:

Click here to view code image

Test-ComputerSecureChannel -credential <domain><admin> -Repair

If you delete a computer account, it’s necessary to rejoin the computer to the domain manually. When you delete a computer account, all information associated with the account is removed from Active Directory. You should only delete computer accounts once a computer has been decommissioned.

Protected accounts

The Protected Users group, shown in Figure 19-2, provides you with a method of protecting highly privileged user accounts from being compromised. It does this by blocking the use of less-secure security and authentication options.

For example, credentials are not cached if an account that is a member of the Protected Users group signs in to a computer running Windows 8.1, Windows 10, Windows Server 2012 R2, Windows Server 2016, or Windows Server 2019. Additionally, accounts that are members of this group cannot use the following security options:

• Default credential delegation (CredSSP)

• Windows Digest

• NTLM—NTOWF

• Kerberos long-term keys

• Sign in offline

If the domain functional level is Windows Server 2012 R2 or higher, user accounts that are members of the Protected Users group cannot:

• Use NT LAN Manager (NTLM) for authentication

• Use DES for Kerberos pre-authentication

• Use RC4 cipher suites for Kerberos pre-authentication

• Be delegated using constrained delegation

• Be delegated using unconstrained delegation

• Renew user tickets (TGTs) past the initial 240-minute lifetime

Only user accounts should be added to the Protected Users group. You should not add computer accounts or service accounts to this group. In secure environments, all privileged accounts should be members of this group, with exceptions occurring only when specific incompatibilities arise that cannot be resolved in another way.

Authentication policies silos

Authentication policy silos allow you to define relationships between the user, computer, and managed service accounts. A user, computer, and managed service account can only belong to a single authentication policy silo. This provides a more robust security method that goes beyond configuring log in restrictions and restricting which accounts can access specific servers in your environment.

Accounts in an authentication policy silo are associated with a silo claim. You can use this silo claim to control access to claims-aware resources. For example, you can configure accounts so that only accounts that are associated with a specific silo claim can access particularly sensitive servers. This means only accounts that are associated with a Certificate Services silo claim can sign in to a computer that has the Active Directory Certificate Services role installed.

Authentication policies allow you to configure settings, such as the TGT lifetime and access-control conditions, which specify conditions that must be met before a user can sign in to a computer. For example, you might configure an authentication policy that specifies a TGT lifetime of 120 minutes and limit a user account so that users can only use it with specific devices, such as privileged access workstations. You can only use authentication policies if you have configured the domain functional level at the Windows Server 2012 R2 or higher.

You configure authentication policies and authentication policy silos using Active Directory Administrative Center, as shown in Figure 19-3.

Disable NTLM

NTLM (NT Lan Manager) is an older authentication protocol that is not as secure as Kerberos. You can disable NTLM by configuring the Network Security: Restrict NTLM: NTLM Authentication In This Domain policy in the default domain GPO and setting the policy to Disable, as shown in Figure 19-4. This policy can be found in the PoliciesWindows SettingsSecurity SettingsLocal PoliciesSecurity Options node of the default domain GPO. Prior to disabling NTLM authentication, you should configure the Network Security: Restrict NTLM: Audit Incoming NTLM Traffic policy to determine if and where the NTLM protocol is still being used in your organization’s environment.

Block server operators from scheduling tasks

Configuring the Domain Controller: Allow Server Operator To Schedule Tasks policy as disabled, as shown in Figure 19-5, will block someone who is signed in to a server using the AT command to configure scheduled jobs. By default, AT jobs run under the SYSTEM account, and attackers often exploit the AT command to elevate privileges. If you configure this policy, it will be necessary to specify account credentials when configuring a scheduled task.

Enable Local Security Authority protection

There are multiple techniques that you can employ to reduce the chance of an attacker successfully executing a “pass the hash” attack. Enabling LSA protection makes it more difficult for the Local Security Authority to be compromised. To configure LSA protection on a domain controller:

1. Open the Registry Editor (RegEdit.exe) and navigate to the registry key that is located at: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa.

2. Create (or set the value of) this registry key: "RunAsPPL"=dword:00000001.

3. Restart the computer.

KRBTGT account password

While you should definitely change the KRBTGT account password if your domain is compromised by an attacker or when someone who has had Domain Admin privileges leaves the organization, it is also good security hygiene to change the KRBTGT account password every six months. Changing the KRBTGT password involves an initial password change, waiting for replication to occur, and then changing the password again. Many people wait 24 hours between the first and second changes. You must perform the password operation twice because of the way the password history of the KRBTGT account functions. Updating the KRBTGT password twice means that replication cannot occur using an older password. If you only do it once, and the domain has been compromised, an attacker might leverage the second stored password.

You can reset the KRBTGT account password by performing the following steps:

1. Open Active Directory Users And Computers.

2. In the View menu, click Advanced Features.

3. In the Users container of the domain, click the KRBTGT user account, as shown in Figure 19-6.

   

4. From the Action menu, select Reset Password. You should then type in and confirm a new password. The password you enter in this dialog box isn’t important because Active Directory will trigger the creation of a separate strong password that is independent of the password you configure.

Enhanced Security Administrative Environment forest

Enhanced Security Administrative Environment (ESAE) forests are an approach to Active Directory privileged access design in which you deploy a dedicated administrative Active Directory forest to host privileged accounts, privileged groups, and privileged access workstations for a production forest. In this design, the ESAE forest is configured with a one-way trust relationship with a production forest. A one-way trust relationship means that accounts from the ESAE forest can be used in the production forest; however, accounts in the production forest cannot be used in the ESAE forest.

The production forest is the Active Directory forest in which an organization’s day-to-day activities occur. You configure the production forest so that administrative tasks in the production forest can only be performed by using accounts that the ESAE forest hosts.

The ESAE forest design provides the following benefits:

• Locked-down accounts. A standard non-privileged user account in the ESAE forest can be configured as a highly privileged user account in the production forest. For example, you make a standard user account in the ESAE forest a member of the Domain Admins group in a domain in the production forest. You can lock down the standard user account hosted in the ESAE forest so that it cannot sign in to hosts in the ESAE forest and can only be used to sign in to hosts in the production forest. Should the account be compromised, the attacker cannot use that account to perform administrative tasks in the ESAE forest.

• Selective authentication. ESAE forest design allows you to leverage a trust relationship’s selective authentication feature. For example, you can configure sign-ins from the ESAE forest so that they can only occur on specific hosts in the production forest. One strategy is to configure selective authentication so that privileged accounts can only be used on privileged access workstations or jump servers in the production forest.

• A simple way to improve security. ESAE forest design provides substantive improvement in the security of existing production forests without requiring a complete rebuilding of the production environment. The ESAE forest approach has a small hardware/software footprint and only affects IT users. In this design, standard user accounts remain hosted in the production forest. Only privileged administrative accounts are hosted in the ESAE forest. As part of the transition to the ESAE forest model, you eventually remove almost all privileged accounts that are native to the production forest. Because they are hosted in a separate forest, privileged administrative accounts can be subject to more stringent security requirements than standard user accounts in the production forest.

An ESAE forest design should have the following properties:

• Limit the function of the ESAE forest to hosting accounts of administrative users for the production forest.

• Do not deploy applications or additional resources in the ESAE forest. An exception to this is when you deploy technologies such as Microsoft Identity Manager, which is used to increase security when implementing Privileged Access Management (PAM).

• The ESAE forest should be a single-domain Active Directory forest. The ESAE forest only hosts a small number of accounts that need to have strict security policies applied.

• Only use one-way trusts. You should only configure a one-way trust where the production forest trusts the ESAE forest. This means that accounts from the ESAE forest can be used in the production forest but that accounts from the production forest cannot be used in the ESAE forest. Accounts used for administrative tasks in the production forest should be standard user accounts in the ESAE forest. If an account is compromised in the production forest, it cannot be used to elevate privileges in the ESAE forest.

Configure ESAE forest servers in the following ways:

• Validate installation media. Use the available checksums to validate that the media hasn’t been modified.

• All servers should run the most recent version of the Windows Server operating system.

• Servers should be updated automatically with security updates.

• Security configuration toolkit baselines should be used as the starting point for server configuration.

• Servers should be configured with secure boot, BitLocker volume encryption, Credential Guard, and Device Guard.

• Servers should be configured to block access to USB storage.

• Servers should be on isolated networks. Inbound and outbound Internet connections should be blocked.

Role-capability files

A role-capability file is a special file that allows you to specify what tasks can be performed when connected to a JEA endpoint. Only tasks that are explicitly allowed in the role-capability file can be performed.

You can create a new blank role-capability file by using the New-PSRoleCapabilityFile cmdlet. Role-capability files use the .psrc extension. For example, run this command to create a new role capability file for a role that allows someone to manage a DNS server:

Click here to view code image

New-PSRoleCapabilityFile -Path .DNSOps.psrc

Once the .psrc file is created, you edit the role-capability file and add the cmdlets, functions, and external commands that are available when a user is connected to the endpoint. You can allow entire Windows PowerShell cmdlets or functions or list which parameters and parameter values can be used.

You can edit a role-capability file in PowerShell ISE, as shown in Figure 19-9. Editing the file involves commenting out the appropriate sections and filling them in with the configuration items that you want to set.

Table 19-2 describes the different options that you can configure in a role-capability file.

Session-configuration files

Session-configuration files determine which role capabilities are mapped to specific security groups. For example, if you wanted to allow only members of the CONTOSDNSOps security group to connect to the JEA endpoint that is defined by the DNSOps role-capability file, you would configure this in the session configuration file.

You use the New-PSSessionConfigurationFile cmdlet to create a session configuration file. These files use the .pssc extension. For example, to create a new session configuration file for the DNSOps role, run the following command:

Click here to view code image

New-PSSessionConfigurationFile -Path .DNSOps.pssc -Full

Session configuration files include the elements described in Table 19-3.

JEA endpoints

A JEA endpoint is a Windows PowerShell endpoint that you configure so that only specific authenticated users can connect to it. When those users do connect, they only have access to the Windows PowerShell cmdlets, parameters, and values defined by the appropriate session-configuration file that links security groups and role capabilities. When you use endpoints with virtual accounts, the actual activity that a user performs on the server that hosts the endpoint occurs using the virtual account. This means that no domain-based administrative credentials are stored on the server that hosts the endpoint.

A server can have multiple JEA endpoints, and each JEA endpoint can be used for a different administrative task. For example, you could have a DNSOps endpoint to perform DNS administrative tasks and an IISOps endpoint to perform Internet Information Server related administrative tasks. Users are not required to have privileged accounts that are members of groups, such as the local Administrators group, to connect to an endpoint. Once connected, users have the privileges assigned to the virtual account configured in the session-configuration file.

You create JEA endpoints by using the Register-PSSessionConfiguration cmdlet. When using this cmdlet, you specify an endpoint name and a session-configuration file hosted on the local machine.

For example, to create the endpoint DNSOps using the DNSOps.pssc session-configuration file, enact the following command and then restart the WinRM service:

Click here to view code image

Register-PSSessionConfiguration -Name DNSOps -Path .DNSOps.pssc

You can use the Get-PSSessionConfigurationFile to determine which endpoints are present on a computer. A user wanting to connect to a JEA session endpoint uses the Enter-PSSession cmdlet with the ConfigurationName parameter. For example, to connect to the DNSOps JEA endpoint on server MEL-DNS1, you would use the command:

Click here to view code image

Enter-PSSession -ComputerName MEL-DNS1 -ConfigurationName DNSOps

Once you’ve verified that JEA works, you’ll need to lock down the default PowerShell endpoint. By default, only members of the local Administrators group can connect to this default endpoint, and if you’ve implemented JEA properly, this group shouldn’t need to have very many members anyway.

PAM benefits

When properly implemented, PAM can provide the following security improvements:

• You can configure your environment so that all accounts that the IT Operations team uses are standard user accounts. Privileges are only granted to these accounts after being requested and approved, and they are temporary. If a user account used by a member of the IT Operations team becomes compromised, the attacker gains no additional privileges beyond those assigned to a standard user account because any privileges that the account might hold are only ever assigned on a temporary basis.

• All requests for privileges are logged. In high-security environments, privilege use can be further tracked, with the activities of a user account granted temporary privileges written to a log file.

Once privileges are granted, a user needs to establish a new session by opening a new Windows PowerShell session or by signing out and signing in again to leverage the new group memberships configured for their account.

PAM components

A PAM deployment consists of the following elements:

• Administrative forest. This is an ESAE forest in which you have deployed Microsoft Identity Manager (MIM) 2016. Accounts from this forest are used to perform administrative tasks. Also known as the Bastion forest.

• A production forest. This is the forest that hosts the resources used on a daily basis by the organization.

• Shadow principals. A shadow principal is a copy of an account or group that exists in the production or source forest. Shadow security groups that are used in PAM use a process called SID History mirroring. SID History mirroring allows the shadow security group in the administrative forest to have the security identifier of the security group in the production or source forest. When a user is added to a PAM role, MIM adds the user’s shadow account in the administrative forest to the shadow group in the administrative forest. When a user logs in by using this account, the user’s Kerberos token then includes a security identifier that matches the security identifier of the original group from the production forest. This functionally makes the user a member of the group that the shadow group is mirroring.

• PAM Client. This client includes a collection of Windows PowerShell cmdlets or a custom solution that interacts with the PAM REST API to allow a PAM user to query and interact with the MIM PAM functionality. The PAM client is only required on computers where it is necessary to request access to a PAM role.

• MIM Service. The MIM server manages the privileged account management process, including adding and removing shadow principals from shadow groups when a PAM role is granted and when it expires.

• MIM Portal. The MIM Portal is a SharePoint site. It provides management and configuration functionality. For example, IT Operations users can sign in to this site to request privileges.

• MIM Service Database. The MIM service database can be hosted on SQL Server 2012 or later. This database holds configuration and identity information that the MIM service uses.

• PAM Component Service. This manages the role-expiration process, removing the shadow account from the shadow group in the administrative forest.

• PAM Monitoring Service. This monitors the production forest and duplicates changes to the administrative forest or the MIM service.

• PAM REST API. This can be used to enable a custom client to interact with PAM.

PAM users and groups

You use the New-PAMUser cmdlet, which is available when you install Microsoft Identity Manager, to create a shadow user. When doing this, an existing PAM-created trust relationship between the ESAE forest and the production must exist. You must also specify the source domain and source account name. For example, to create a new shadow user based on the Oksana account in the Adatum.com domain, you would use the following command:

Click here to view code image

New-PAMUser –SourceDomain Adatum.com –SourceAccountName Oksana

You use the New-PAMGroup cmdlet, available when you install Microsoft Identity Manager, to create a shadow group. When creating a shadow group, you need to specify the source group name, the source domain, and a source domain controller in the source domain. For example, to create a new shadow group for the CorpAdmins group in the Adatum.com domain by using the mel-dc1.adatum.com domain controller, issue the following command:

Click here to view code image

New-PAMGroup –SourceGroupName "CorpAdmins" –SourceDomain adatum.com
–SourceDC mel-dc1.adatum.com

PAM roles

A PAM role represents the privileged role to be requested. For example, you might configure a specific PAM role for performing password resets or another for configuring Active Directory Certificate Services. You can configure PAM role settings by viewing the properties of the PAM role in the MIM web interface. A PAM role consists of the following options:

• Display Name. This is the name of the PAM role.

• PAM Privileges. This is a list of security groups to which a user who is granted access to the role is temporarily added. This does not list the privileges actually assigned to this group. For example, if you delegate the Reset User Password privilege to the CorpAdmins group, this dialog box does not indicate that this privilege has been delegated. This dialog box also lists the name of the shadow principal rather than the group in the original domain.

• PAM Role TTL(sec). This is the maximum amount of time that the member can be granted this role. The default is 3,600 seconds (1 hour). You should configure the maximum lifetime for a Kerberos user ticket in line with the Time To Live (TTL) value to ensure that a user’s ticket is updated to reflect the change in group membership after the PAM Role TTL expires.

• MFA Enabled. MIM’s PAM functionality can be integrated with Azure Multifactor Authentication. When you enable this option, requests for a PAM role require two forms of authentication. This second form of authentication can include a text message or a telephone call to a registered number. When a text message is sent, the requesting user must enter the code sent to him or her. When a telephone call is made, the user must enter a PIN that he or she has previously configured.

• Approval Required. PAM roles can be configured so that PAM role membership is only granted if a PAM administrator approves the request. You configure PAM administrators by adding a user to the PAM Admins set. This can be done through the Sets section under Management Policy Rules in the MIM web console.

• Availability Window Enabled. When you configure an availability window for a role, the PAM role can only be used during certain hours. This provides an additional layer of security for a PAM role. For example, you might configure a role that allows modification to sensitive groups to only be used during business hours.

• Description. Use this option to provide a description of the PAM role.

Expression-based audit policies

Traditional object audit policies involve specifying a group and configuring the type of activities that trigger an event to be written to the security log. For example, you can specify that an audit event is written each time a member of the Managers group accesses a file in a specific folder.

Expression-based audit policies enable you to go further. These policies enable you to set conditions for when auditing might occur. For example, you might want to configure auditing so that tracking only occurs for members of the Managers group who have access to sensitive files when they access those files from computers that aren’t part of the Managers_Computers group. This way, you don’t bother tracking access when members of this group access sensitive files from within the office, but you do track all access to those sensitive files when members of this group are accessing them from an unusual location.

You can integrate expression-based audit policies with Dynamic Access Control (DAC) to create targeted audit policies based on user, computer, and resource claims. Instead of just adding claims based on user or device group membership, the claim can be based on document metadata, such as confidentiality settings and site location. You can configure expression-based audit policies at the file or folder level or apply them through Group Policy by using policies in the Global Object Access Auditing node of Advanced Audit Policy Configuration.

File and folder auditing

After you configure object access auditing either through traditional or advanced audit policies, you can configure auditing at the file and folder level. The simplest way to configure auditing is at the folder level because you can configure all folders and subfolders to inherit those auditing settings. If you change the auditing settings at the folder level, you can use the Replace All Child Object Auditing Entries option to apply the new auditing settings to the folder’s child files and folders.

You can configure auditing for a specific file and folder through the Advanced button on the Security tab of the object’s properties. You can configure basic success and failure auditing. You can also configure expression-based auditing so that a specific security group member’s activity is audited only if other conditions, such as membership of other security groups, are also met.

The advantage of using Global Object Access Auditing is that when you configure it, you can use file classification to apply metadata to files and then automatically have auditing enabled for those files. For example, by using file classification and DAC, you can configure a Windows Server 2019 file server so that all files containing the phrase “code secret” are marked as Sensitive. You can then configure Global Object Access Auditing so that all attempts to access files marked as Sensitive are automatically audited. Instead of having an administrator track down all the files that are sensitive and configuring auditing on those files, the process is automatic. All that needs to happen to trigger the audit is that the phrase “code secret” is included in the file.

Using auditpol.exe with auditing

Auditpol.exe is a command-line utility that you can use to configure and manage audit policy settings from an elevated command prompt. You can use auditpol.exe to perform the following tasks:

• View the current audit policy settings with the /Get subcommand

• Set audit policy settings with the /Set subcommand

• Display selectable policy elements with the /List subcommand

• Back up and restore audit policies using the /Backup and /Restore subcommands

• Delete all per-user audit policy settings and reset the system policy settings using the /Clear subcommand

• Remove all per-user audit policy settings and disable all system policy settings using the /Remove subcommand

For example, to enable success and failure auditing for the File System subcategory of Object Access, execute the following command:

Click here to view code image

Auditpol.exe /set /subcategory:"File System" /success:Enable /failure:Enable

To view the current audit policy settings for all audit policies, issue the following command:

Click here to view code image

Auditpol.exe /get /category:*

To view the current audit policy settings for a specific category, such as Object Access, issue the following command:

Click here to view code image

Auditpol.exe /get /category:"Object Access"

Firewall profiles

Firewall profiles allow you to treat traffic differently depending on the network to which the computer is connected. For example, the same server might be connected to the following:

• A remote site through a VPN connection that has the private profile applied

• A perimeter network by a network adapter, where the connection has the public profile applied

• The organization’s internal network through a second adapter that has the domain profile applied

The advantage of separate profiles is that each one allows you to have separate sets of firewall rules applied. You might allow Distributed File System (DFS) traffic on one profile, web traffic on another, and SMTP traffic on a third.

Profiles are independent of each other; the settings that you configure for one profile do not apply to other profiles. You can configure the following properties for each profile:

• Firewall State. You can set this to On (default) or Off.

• Inbound Connections. You can set this to Block (default), Block All, or Allow. The Block All setting means firewall rules that allow connections are ignored.

• Outbound Connections. You can set this to Block or Allow (default).

• Settings. This allows you to configure whether notifications are displayed, whether unicast responses are transmitted to multicast or broadcast traffic, and whether to merge rules when rules apply both locally and through Group Policy.

• Logging. This allows you to specify logging settings.

Firewall logs are written to the %systemroot%system32LogFilesFirewallpfirewall.log file. The default settings do not log dropped packets or successful connections, which means that, unless you change the defaults, nothing is logged. Firewall logging is most useful when you’ve determined that a particular service is unavailable to the network because of the firewall.

You can turn on firewall logging on a per profile basis by clicking the Customize button next to Logging on each profile’s properties page. This displays the Customize Logging Settings dialog box shown in Figure 19-10. You can then enable logging for dropped packets and successful connections. If you are having trouble with a newly installed service on a server, enable the logging of dropped packets to determine the properties of the packets dropped, so that you can create a firewall rule that allows your service to be accessed from the network.

Inbound rules

Inbound rules are based on program, port, or one of 45 predefined categories, such as BranchCache Content Retrieval or Network Policy Server. You can also create custom rules that include a mixture of these, where you specify a program and a port as well as a rule scope. For example, you can use a custom rule to block all incoming traffic on port 80 to a particular application but not block port 80 traffic to other applications on the server. The basic aspects of creating a firewall rule involve:

• Specifying a program or port. When you specify a port, you must choose whether the rule applies to TCP or UDP traffic.

• Specifying what action should be taken. You can allow the connection, in which case all traffic that matches the rule is allowed by the firewall. You can allow the connection if it is authenticated, in which case traffic that meets the IPsec authentication requirements and the connection security rules is allowed, but traffic that is not properly authenticated according to these conditions is dropped.

• Specifying the network profiles in which the rule applies. In general, rules should apply in all profiles, but there might be circumstances for which you want to allow traffic from an interface connected to a domain network but block the same traffic if it comes from an interface connected to a public network.

After you have created the rule, you can then edit the rule’s properties. Editing the rule’s properties allows you to configure more advanced options than are present in the Rule Creation Wizard. By editing a rule’s properties, you can:

• Configure a rule to apply to a service rather than just a program.

• Limit the computers that can make authenticated connections. By default, if you configure the Allow Traffic If The Connection Is Authenticated option, any computer that can authenticate is able to successfully transmit traffic. By editing a firewall’s rules, you can limit traffic to specific computers rather than all authenticated computers. You can do the same with user accounts, limiting successful connections to specific users when authentication has successfully occurred.

• Edit the rule’s scope, which is the local and remote IP address ranges to which the rule applies. You can also do this when you create a custom rule.

• Configure whether the rule applies to specific network interfaces, instead of just network profiles. For example, if your computer has two network adapters, you can configure a rule to apply so that it allows traffic on one adapter but not the other when both adapters have the same profile set.

• Configure whether to allow packets that have passed across a Network Address Translation (NAT) device.

Creating outbound rules

Default settings for Windows Firewall with Advanced Security do not block outbound traffic. In high-security environments, you should consider using outbound rules to block all but authorized outbound traffic.

The process for creating an outbound rule is almost identical to the process for creating an inbound rule. You specify the rule type on the New Outbound Rule Wizard, you specify whether the connection is blocked, allowed, or allowed only if authenticated, and you specify the network profiles in which the rule is active. By editing the properties of the rule after the rule is created, you can configure all the advanced options configurable for inbound rules, such as rule scope, specific network interfaces, and to which computers or users the rule allows outbound connections.

Configuring IPsec

The IPsec Settings tab of Firewall Properties allows you to configure how IPsec is used when applied in connection security rules. On the tab itself, shown in Figure 19-11, you can configure whether you want to customize the IPsec defaults, exempt Internet Control Message Protocol (ICMP) traffic from IPsec, and whether you want to configure IPsec tunnel authorization.

Exempting ICMP traffic can be useful for diagnostic purposes because many administrators use the ping utility to diagnose whether a host has network connectivity. If connection security rules are enabled, the default IPsec settings mean that a successful IPsec negotiation must occur prior to an ICMP response being sent. If the IPsec negotiation is the problem, enabling ICMP response allows you to verify that there is network connectivity and that the problem just lies a bit further up the network stack.

If you click the Customize button next to the IPsec defaults, you can change the Key Exchange, Data Protection, and Authentication Method (see Figure 19-12). The default key exchange uses Diffie-Hellman Group 2 key exchange algorithm with a key lifetime of 480 minutes. You can modify these settings so that they use more secure methods, but this may reduce the ability to interact with some third-party devices.

The data protection settings allow you to configure the algorithms used for data integrity and encryption. Normally, there isn’t much reason to change this; however, if you feel you need the strongest encryption possible to protect your organization’s network traffic, you can use a different algorithm, such as AES-CBC with a 256-bit key length. In general, the stronger the encryption, the greater the resources needed to support that encryption. Although you can make the protection a lot stronger, the benefit of doing so might be only marginal given the value of the data being protected.

The default authentication method used for IPsec connections is Computer (Kerberos V5). This means that a domain controller must be present to verify the identity of each computer before an IPsec session can be established. You can also use Computer (NTLMv2), a computer certificate from this certification authority (CA), or a pre-shared key to authenticate IPsec connections. A pre-shared key is not a recommended method of authentication, but it might be necessary if there is not a certificate services infrastructure and computers aren’t members of a domain.

Connection security rules

Connection security rules are a more intelligent type of firewall rule than a simple port-based rule. An interesting adaption to firewalls has been an increase of traffic through ports traditionally used for common applications. Connection security rules are about trusting incoming connections based on the identity of the remote host rather than the remote host’s network address or the communication port it uses.

Authentication exemptions Authentication exemptions allow you to create very specific holes in connection security rules. These are useful in the event that you want to remotely manage a server, but all the servers that would normally authenticate your connection, such as certificate servers or domain controllers, are unavailable. Authentication exemptions override existing connection security rules.

When you create an authentication exemption, you define the exemption on the basis of the source computer’s IP address. As Figure 19-13 shows, you do this using a single IPv4 or IPv6 address, an IP address range, or a predefined set of computers. For security reasons, you should limit the number of IP addresses for which you create authentication exemptions to one or two specific privileged access workstations.

To create an authentication exemption, perform the following steps:

1. In Windows Firewall With Advanced Security, right-click the Connection Security Rules node and then click New Rule. This opens the New Connection Security Rule Wizard. Select Authentication Exemption.

2. In the Exempt Computers dialog box, click Add. In the IP Address dialog box, enter the IP address, subnet, or IP address range of the computers that you wish to exempt from connection security rules. You can also choose from a list of predefined addresses, including the Default Gateway, DHCP servers, the local subnet, or DNS servers.

3. Select the profile to which you want the rule to apply and specify a rule name.

Isolation rules Isolation rules allow you to limit communication so that a server or computer communicates only with computers that have authenticated with it. Sometimes, these are called domain isolation policies because they limit hosts to only communicating with other servers that are members of the same Active Directory forest. When you configure an isolation rule, it applies to all traffic from all hosts; this is unlike tunnel or server-to-server rules, which apply to traffic to and from specific hosts.

To create an isolation rule, perform the following steps:

1. In Windows Firewall With Advanced Security, right-click the Connection Security Rules node and then click New Rule. This opens the New Connection Security Rule Wizard. Select Isolation and then click Next.

2. On the Requirements page, as shown in Figure 19-14, choose one of the following:

   • Request Authentication For Inbound And Outbound Connections

   • Require Authentication For Inbound Connections And Request Authentication For Outbound Connections

   • Require Authentication For Inbound And Outbound Connections

3. Requiring authentication on both inbound and outbound connections is the strongest form of protection because it means that communication can be performed only with authenticated hosts.

4. Choose the authentication method. The default is to use the authentication method specified on the IPsec Settings tab of Firewall Properties. You can also choose between computer and user leveraging Kerberos version 5, or you can configure advanced authentication options, which include certificate-based authentication. It is also possible, though not recommended, to use a pre-shared key for authentication, which is useful when you need to communicate with computers running third-party operating systems.

5. The final step in setting up a connection security rule is to configure the profiles in which the rule applies. Unless there is a good reason to do otherwise, you should apply connection security rules in all profiles.

Server-to-server rules Server-to-server rules are used to authenticate communication between two groups of computers. This can be a rule authenticating and encrypting a single computer-to-computer connection, such as between a web server and a database server or between computers on two separate subnets. Server-to-server rules differ from isolation rules; isolation rules apply to communication from all hosts, whereas server-to-server rules apply to specific hosts.

To create a server-to-server rule, perform the following steps:

1. In Windows Firewall With Advanced Security, right-click the Connection Security Rules node and then click New Rule. This opens the New Connection Security Rule Wizard. Select the Server-To-Server rule.

2. In the Endpoints dialog page, enter the IP addresses of the computers that are at one end of the connection and the IP addresses of the computers that are at the other end of the connection. Figure 19-15 shows a rule defining one endpoint as the subnet 192.168.15.0/24, and the other endpoint as subnet 192.168.16.0/24.

   

3. On the Requirements page, specify how you want authentication to occur. If you want only this computer to communicate on the profile using encrypted and authenticated connections, select Require Authentication For Inbound And Outbound Connections.

4. Specify the authentication method. The default is to use a computer certificate issued by a designated CA. You can also specify computer-based Kerberos, NTLMv2, or a pre-shared key.

5. Specify the firewall profiles in which this connection security rule applies and add a name for the rule.

Tunnel rules Tunnel rules allow client computers to communicate with computers on a secure network behind a remote gateway. For example, if you have a single server located at a branch office that you want to connect to an internal network at another office, using a tunnel rule, you specify the location of a host that functions as a gateway to that secure network. This allows you to create an IPsec tunnel through which secure communication can occur.

To create a tunnel rule, perform the following steps:

1. In Windows Firewall With Advanced Security, right-click the Connection Security Rules node and then click New Rule. This opens the New Connection Security Rule Wizard. Select Tunnel Rule.

2. On the Tunnel Type page, as shown in Figure 19-16, determine the type of tunnel that you want to create. To create the type of rule outlined above, select Client-To-Gateway.

   

3. Choose whether you wish to require authentication for inbound and outbound connections.

4. Specify the address of the computer that functions as the gateway to the secure network.

5. Specify the authentication method. The default is to use a computer certificate issued by a designated CA. You can also specify computer-based Kerberos, NTLMv2, or a pre-shared key.

6. Specify the firewall profiles in which this connection security rule applies and add a name for the rule.

Host Guardian Service

The Host Guardian Service (HGS) is a Windows Server 2019 role that manages attestation and the Key Protection Service (KPS). The KPS stores and is responsible for securely releasing keys to shielded VMs. One of the keys that the KPS stores is the transport key. The transport key is used to encrypt a shielded VM’s virtual TPM. Microsoft recommends that you deploy the HGS role on a physically secure physical server running the Server Core operating system.

Validating a Hyper-V host involves verifying both its identity and configuration. Once the attestation service verifies both its identity and configuration, the KPS provides the transport key to that host that is required to unlock and run shielded VMs on that host.

Configuring a HGS server involves the deployment of a dedicated single-domain AD DS forest. An HGS cluster comprises at least three nodes, and each HGS cluster node is a domain controller for the root domain of this dedicated AD DS forest. Deploying an HGS cluster is different from a traditional domain controller deployment, and you don’t go through the traditional AD DS promotion process. Instead, you take a standalone server, install the HGS role on that server, and then run the Initialize-HgsServer PowerShell cmdlet.

Running the Initialize-HgsServer PowerShell cmdlet triggers the process of configuring the server as a domain controller for the newly created single-domain AD DS forest. The trusted Hyper-V hosts need to either be a member of the HGS forest or a member of a domain that has a one-way trust relationship with the forest. This second configuration must be even more secure because a compromised virtualization host won’t be able to make any modifications to the HGS forest because the trust relationship goes only in the opposite direction.

TPM and admin-trusted attestation

Trusted attestation allows a shielded VM to verify that it is running on a virtualization host that participates in a guarded fabric. There are two methods that you can use to provide trusted attestation. The method that you provide depends on the hardware that you have available. Table 19-4 lists the different trusted attestation types.

Encryption-supported VMs

An encryption-supported VM is a VM that can run in a semi-protected manner on a guarded fabric but doesn’t have the stringent security requirements of a shielded VM. A virtualization administrator has a greater level of access to an encryption-supported VM. This makes the deployment less secure than a shielded VM. Encryption-supported VMs may be more appropriate for organizations where the VM administrator would normally have access to the VMs anyway, but for compliance reasons VMs need to be run in a manner in which the contents of virtual hard disks are encrypted.

Table 19-5 outlines how encryption-supported VMs differ from shielded VMs.

Shielding data file

The shielding data file (also called the provisioning data file, or PDK file) is a special encrypted file that stores the following secrets:

• Administrator credentials.

• Answer file (unattend.xml).

• Security policy that determines whether VMs created using this shielded data file will be fully shielded VMs or encryption-supported VMs.

• An RDP certificate. This allows secure RDP communication with the VM.

• A volume signature catalog. This contains a list of trusted and signed template disk signatures from which a VM can be created. A shielded template disk is a template virtual hard disk that has a digital signature. This ensures that the template hard disk from which a new VM is deployed is trustworthy. During provisioning, the signature of the disk is computed and checked against a list of trusted and shielded template disk signatures stored in the catalog. If the signatures match, deployment continues. If the signatures do not match—indicating that the shielded template disk has been modified—the deployment fails.

• A Key Protector. This specifies which guarded fabrics a shielded VM generated from this shielding data file is authorized to run on.

Tenant keys protect this file, and the tenant uploads the shielding data file to the secure fabric. Because tenant keys protect the file, the virtualization administrator doesn’t have access to the contents of the shielding data file. This means that the virtualization administrators do not have access to the local Administrator password used with virtual machines deployed on the fabrics that they manage.

The shielding data file ensures that any VMs are explicitly created with the parameters specified by the tenant. The virtualization administrator can’t swap in their own template hard disks, answer files, or administrator passwords. Should a template hard disk be swapped out or modified by the virtualization administrator, it won’t match the cryptographic signature of any authorized template hard disk listed in the shielding data file.