Manage and maintain AD DS

After you have deployed and configured your domain controllers, you must configure service accounts, account policies, and other security settings. You also must be prepared to maintain the Active Directory Domain Services (AD DS) server role to ensure availability of this critical identity service. This maintenance might involve performing backup and recovery procedures, and maintaining the AD DS database.

If you are deploying AD DS in a large enterprise organization, you must also configure more advanced aspects of AD DS, including how to establish and configure a multi-forest AD DS infrastructure. For organizations with multiple locations, you also need to know how to create subnets and sites, and to configure and manage both intrasite and intersite AD DS replication.

Skill 2.1: Configure service authentication and account policies

Many apps and services that you install on Windows Server run in the security context of a user account, known as a service account. Like all user accounts, it is important that these service accounts are not compromised. Windows Server 2016 provides Managed Service Accounts (MSAs) and Group Managed Service Accounts (gMSAs) to help you more easily manage service accounts.

Account policies enable you to control fundamental security features, such as password complexity, length, expiration, and lockout. You can use these features to help secure your network, and the apps and services that run within it.

Create and configure MSAs and gMSAs

In earlier versions of Windows Server, it was common to create standard user accounts for the purposes of running apps or services. For example, you might create a user account called Email and configure the email program you installed to run in the context of the Email user account.

Using standard user accounts in this way does raise some considerations, including:

• Account password management The password for these standard user accounts must be periodically changed to help maintain security of your apps and services. Failure to change the account password results in failure of your apps or service.

• Service Principal Names Service Principal Names (SPNs) are unique identifiers for a specific service instance and are used to associate a service instance with a service account. If you use a standard user account with SPNs, it could result in additional administrative effort and cause possible authentication issues that might result in app failure.

One possible workaround is to use the local system (NT AUTHORITY\SYSTEM), the local service (NT AUTHORITY\LOCAL SERVICE), or the network service (NT AUTHORITY\NETWORK SERVICE) accounts to configure your app. However, these three accounts might not provide sufficient security, nor have sufficient privilege for many situations.

Windows Server 2016 provides both MSAs and gMSAs to help you mitigate these issues:

• MSAs Unlike standard user accounts, MSAs inherit some of their structure from computer objects, including the way that password changes are handled. This provides the following benefits:

  • Automatic password management

  • Simplified SPN management

  Exam Tip

  MSAs are stored in the Managed Service Accounts container in your AD DS domain. To view these accounts, in Active Directory Users and Computers, enable the Advanced Features view.

• gMSAs Enable you to extend the function of MSAs to multiple servers in your AD DS domain. This is useful where you are using load balancing. To use gMSAs, your AD DS environment must meet the following requirements:

• Client computers must run at least Windows 8

• You must create a key distribution services (KDS) root key for your domain

• At least one domain controller must be running Windows Server 2012 or later

When you create a gMSA, you must define the collection of computers that can retrieve password information from AD DS. This can be a list of computer objects, or an AD DS group that contains the desired computer objects.

In Windows Server 2016, you use the same Windows PowerShell cmdlets to create and manage gMSAs as you do MSAs. This means that in Windows Server 2016, all MSAs are managed as gMSAs. To create gMSAs, start by creating the KDS root key. On a domain controller, use the following Windows PowerShell cmdlet to complete this task:

Add-KdsRootKey –EffectiveImmediately

After creating the KDS root key, use the Active Directory Module for Windows PowerShell new-ADServiceAccount cmdlet from any domain controller to create your gMSAs. For example:

New-ADServiceAccount –Name LON-IIS-GMSA –DNSHostname LON-DC1.Adatum.com –
PrincipalsAllowedToRetrieveManagedPassword LON-DC1$, LON-DC2$, LON-IIS$

Use the PrincipalsAllowedToRetrieveManagedPassword parameter to define which computers, or groups, can access the gMSA password properties.

When you have created your new gMSA, you must associate it with the server computers on which it is to be used. To do this, use the Active Directory Module for Windows PowerShell Add-ADComputerServiceAccount cmdlet to complete this task. For example:

Add-ADComputerServiceAccount –identity LON-DC1 –ServiceAccount LON-IIS-GMSA

Next, you must install the gMSA on the servers where it is to be used. Use the Install-ADServiceAccount cmdlet. For example:

Install-ADServiceAccount -Identity LON-IIS-GMSA

Finally, configure the required service or app to use the configured gMSA. Use the following procedure to complete the task:

1. On the target server(s), in Server Manager, click Tools, and then click Services.

2. Locate the appropriate service, double-click it, and then on the Log On tab, shown in Figure 2-1, click This Account, and then type the name of your account. For example, type ADATUM\LON-IIS-GMSA.

   

   FIGURE 2-1 Configuring a service account

3. Clear the Password, and Confirm Password check boxes, and click OK.

Manage SPNs

SPNs are similar in concept to Domain Name System (DNS) alias records (CNAMEs), but rather than being a pointer for a computer record in a DNS zone, SPNs point to domain accounts. SPNs are used by Kerberos, the authentication protocol in Windows Server 2016 AD DS domain controllers. They associate a service with a service logon account, enabling a client computer app to request that the service authenticate an account, even if the client app does not know the account name. Before Kerberos can use SPNs, services must register their SPNs in AD DS.

SPNs consist of several elements, and must be unique within your AD DS forest. These elements are:

• Service class Identifies the class of a service. For example, www for a web server. There are several well-known service classes.

• Host The computer name on which the service runs. Usually this is a fully qualified domain name (FQDN), such as LON-SVR2.Adatum.com.

• Port Optionally used to identify the port number used by a service. Enables you to differentiate between multiple instances of the same services installed on a specific computer. For example, a secure website uses TCP port 443.

• Service name An optional element that is based on the DNS name of the domain, or of a service locator (SRV) or Mail Exchanger (MX) record within the domain. This element identifies services that are domain-wide.

This creates an SPN comprising these elements:

<service class>/<host>:<port>/<service name>

For example:

WebService/LON-SVR2.Adatum.com:443

Generally, there is little management of SPNs required. But occasionally, you might be required to force registration. You can use the Setspn.exe command-line tool to register SPNs.

For example, to register an SPN for IIS on LON-SVR2 in the Adatum.com domain using the LON-IIS-GMSA group MSA, use the following command, as shown in Figure 2-2.

setspn -A WebService/lon-svr2.adatum.com:433 lon-iis-gmsa

Configure Kerberos Constrained Delegation

In some situations, app or services might make connections to remote apps or services installed on other server computers. In essence, these connections are being made on behalf of client computers connecting to the originating app or service.

Typically, this scenario occurs when a front-end service communicates with a back-end service on behalf of users on client computers using the back-end app. To support this scenario, it is necessary to use authentication delegation; this is the process where the authenticating authority (in Windows Server 2016, this is a domain controller) allows a service to act on behalf of another service. The problem is that in earlier versions of Windows Server, there is no way to prevent the delegation from extending to a third, or even fourth service. Kerberos constrained delegation in Windows Server 2016 prevents this.

To configure constrained delegation to allow a front-end app access to a back-end service on the behalf of users, you must use one of the following cmdlets for the security principal that runs your front-end service:

• Get-ADUser

• Get-ADComputer

• Get-ADServiceAccount

Next, pass that security principal object as the argument using the PrincipalsAllowedToDelegateToAccount parameter with one of the following Windows PowerShell cmdlets:

• Set-ADUser

• Set-ADComputer

• Set-ADServiceAccount

For example:

$computer = Get-ADComputer -Identity WEBSVR1

Set-ADComputer LON-SVR2 -PrincipalsAllowedToDelegateToAccount $computer

Configure virtual accounts

You cannot create, delete, or manage the passwords for virtual accounts. They exist automatically and are a representation of the local computer account when used to access apps or resources.

To configure a service to use a virtual account, use the following procedure:

1. In Server Manager, click Tools, and then click Services.

2. Locate the appropriate service, double-click it, and then on the Log On tab, shown in Figure 2-3, click This Account, and then type the name of your account. For example, type NT SERVICE\LON-SVR2$.

   

   FIGURE 2-3 Configuring a virtual account for a service

3. Clear the Password and Confirm Password check boxes, and click OK.

Configure account policies

Account policies enable you to configure password-related settings, including the password policy, account lockout settings, and Kerberos policy settings. These settings are accessible through the Default Domain Policy in the Group Policy Management Editor.

To view and configure these settings, use the following procedure:

1. In Server Manager, click Tools, and then click Group Policy Management.

2. In Group Policy Management, expand your forest, expand the Domains folder, and expand the domain you want to configure.

3. Click the Group Policy Objects folder, and then, in the Details pane, as shown in Figure 2-4, right-click the Default Domain Policy, and then click Edit.

   

   FIGURE 2-4 Viewing available default Group Policy Objects

4. In the Group Policy Management Editor, under the Default Domain Policy node, expand Computer Configuration, expand Policies, expand Windows Settings, expand Security Settings, and then click Account Policies, as shown in Figure 2-5.

   

   FIGURE 2-5 Editing Account Policies in the Default Domain Policy

Configure domain and local user password policy settings

Password policies enable you to define settings that control how your domain users’ passwords are managed. To configure domain password policy settings, in the Group Policy Management Editor, under the Account Policies folder, in the Password Policy folder, shown in Figure 2-6, you can configure the following password settings:

• Enforce Password History Prevents users from reusing passwords. The default value is 24.

• Maximum Password Age Ensures that users change their passwords within the defined period. Default is 42 days.

• Minimum Password Age Prevents users from changing their passwords until this period has expired. Helps prevent users from cycling through a range of passwords back to their favorite password by changing their password 24 times very rapidly. The default is one day.

• Minimum Password Length Ensures passwords are not too short. Longer passwords are more difficult to guess, especially if complex passwords are also enforced. Default is seven characters.

• Password Must Meet Complexity Requirements Helps to ensure that passwords are more difficult to guess. Enabled by default. When enabled, passwords must meet several complexity requirements:

  • Cannot contain user’s name or their account user name

  • Must contain at least six characters

  • Must contain characters from at least three of the following four groups:

  • Uppercase letters [A–Z]

  • Lowercase letters [a–z]

  • Numerals [0–9]

  • Special, non-alphanumeric characters, such as !@#)(*&^%

• Store Passwords Using Reversible Encryption Provides support for older apps that require knowledge of a user’s password. In many cases, storing passwords using reversible encryption is the same as storing clear text passwords and should be avoided unless absolutely necessary. This is disabled by default.

For computers in a workgroup, you can configure a local account policy. To configure local password policies, on the target computer, in Server Manager, click Tools, and then click Local Security Policy. Expand Account Policies, and, as shown in Figure 2-7, click Password Policy. You can also configure a local account lockout policy.

Configure account lockout policy settings

Account lockout settings define what happens when a user enters an incorrect password. If a user’s account is locked, they cannot sign in until their account is unlocked. In the Account Lockout Policy folder, shown in Figure 2-8, you can configure the following lockout settings:

• Account Lockout Duration Defines the lockout duration in minutes. After an account is locked, when this period has expired, the account is automatically unlocked. An administrator can unlock the account manually at any time. To always use manual unlocking, configure the lockout duration to 0. By default, this setting is not enabled.

• Account Lockout Threshold Determines how many incorrect sign in attempts a user can make before their account is locked. By default, a value of 0 is assigned; this effectively disables account lockout.

• Reset Account Lockout Counter After Determines how many minutes must pass before the account lockout threshold is reset. Used in conjunction with the account lockout threshold value, you can effectively configure a system sensitivity to incorrect passwords. For example, configuring a value of 5 in conjunction with an account lockout threshold of 2 means that any two incorrect passwords in a five-minute period locks the account. Changing this value to 30 makes the system more sensitive because the account is locked out after two incorrect sign in attempts in a 30-minute period. By default, this setting is not enabled.

To manually unlock an account, open the user account properties in Active Directory Users and Computers. On the Account tab, shown in Figure 2-9, select the Unlock Account check box, and then click OK.

Configure Kerberos policy settings

Kerberos provides the authentication architecture for Windows Server 2016. When users sign in, they receive a Kerberos ticket granting ticket from a domain controller. When a user attempts to connect to a server, they receive a service ticket. The Kerberos policy settings enable you to control aspects of ticket handling and renewal.

In the Kerberos Policy folder, shown in Figure 2-10, you can configure the following Kerberos settings:

• Enforce User Logon Restrictions Forces domain controllers to perform additional validation on a user’s rights policy, helping to add security. The default is Enabled.

• Maximum Lifetime For Service Ticket Defines the maximum age of a user’s service ticket. Must be at least 10 minutes and not greater than the maximum lifetime of a user ticket. The default is 600 minutes.

• Maximum Lifetime For User Ticket Determines the maximum age of a user’s ticket granting ticket. The default is 10 hours.

• Maximum Lifetime For User Ticket Renewal Determines for how long a user can renew their ticket granting ticket. The default is 7 days.

• Maximum Tolerance For Computer Clock Synchronization Determines the sensitivity to a disparity between the client computer’s time and that of the domain controller. The default is five minutes.

Configure and apply Password Settings Objects

You can only configure Account Policies for your domain; you cannot configure a separate policy for organizational units (OUs) within your domain. In early versions of Windows Server, the need to configure a different account policy for business groups or geographical locations often meant having to configure multiple domains within the AD DS forest.

However, in Windows Server 2016 you can implement multiple account policies by using Password Settings Objects (PSOs). Using PSOs you can implement and configure account policies that impact users and groups rather than just containers, which means you have more targeted administrative control.

In addition to PSOs, Windows Server 2016 creates a container called Password Settings Container; this stores the PSOs that you create and apply in your domain.

To implement PSOs, you must create the PSO and then link it to the appropriate user or group object. For example, to configure a more stringent password policy for administrator accounts, use the following high-level procedure:

1. Create a Secure Admins global security group.

2. Add the required user accounts to the group.

3. Create a PSO and link it to the Secure Admins group.

If you link multiple PSOs to a single object, the following precedence rules apply:

• If there are no PSOs linked to a user, Windows Server AD DS applies the Default Domain Policy Account Policy settings.

• If you link a PSO directly to a user object, that PSO takes precedence over any PSOs linked to groups of which the user is a member.

• If you link PSOs to groups, AD DS compares the PSOs for all global security groups of which the user object is a member.

Although the settings in a PSO are identical to the password policies that you apply in the Default Domain Policy, you do not use the Group Policy Management Editor to configure or apply them. Instead, you use Windows PowerShell or the Active Directory Administrative Center console.

Creating PSOs with Windows PowerShell

To create and apply PSOs using Windows PowerShell, use the following two cmdlets:

• New-ADFineGrainedPasswordPolicy Creates the PSO and assigns the properties that you define by using cmdlet parameters, shown in Table 2-1.

  Table 2-1 PSO settings

  Setting	Format of Setting	Explanation
  Password Policy Settings
  Name	String	Defines the name of your PSO.
  ComplexityEnabled	True or False	Determines whether complex passwords are enforced.
  MinPasswordLength	Integer	Defines the minimum length of passwords.
  MaxPasswordAge	Time: dd.hh:mm:ss	Determines the maximum number of days before users must change their passwords.
  MinPasswordAge	Time: dd.hh:mm:ss	Determines the minimum amount of time that must elapse before users can change their passwords.
  PasswordHistoryCount	Integer	Specifies the number of password changes that must occur before passwords can be reused.
  ReversibleEncryptionEnabled	True or False	Defines whether reversible encryption is allowed.
  Account Lockout Settings
  LockoutThreshold	Integer	Specifies the number of incorrect password sign in attempts before an account is locked.
  LockoutObservationWindow	Time: hh:mm:ss	Determines how many minutes must pass before the account lockout threshold is reset.
  LockoutDuration	Time: hh:mm:ss	Specifies for how long the account is locked before being unlocked automatically.
  PSO Specific Settings
  Precedence	Integer	Determines how multiple PSOs linked to the same object apply.
  PSOApplied	List of distinguished names	Determines to which users or global security groups the PSO should apply.
  ProtectedFromAccidentalDeletion	True or False	Specifies whether the PSO must be protected against inadvertent deletion.

• Add-FineGrainedPasswordPolicySubject Links the PSO to the user or group that you define by using the cmdlet parameters.

For example, as shown in Figure 2-11, the following commands create and link a new PSO named Admins to the Secure Admins global security group:

New-ADFineGrainedPasswordPolicy Admins -ComplexityEnabled:$true
-LockoutDuration:"00:45:00" -LockoutObservationWindow:"00:45:00" -LockoutThreshold:"0"
-MaxPasswordAge:"24.00:00:00" -MinPasswordAge:"2.00:00:00" -MinPasswordLength:"8"
-PasswordHistoryCount:"30" -Precedence:"1" -ReversibleEncryptionEnabled:$false -Protecte
dFromAccidentalDeletion:$true

Add-ADFineGrainedPasswordPolicySubject Admins -Subjects "Secure Admins"

Creating PSOs with the Active Directory Administrative Center

To create and link PSOs using the Active Directory Administrative Center console, use the following procedure:

1. In Active Directory Administrative Center, click Manage, click Add Navigation Nodes, in the Add Navigation Node dialog box, select the appropriate target domain, click the >> button, and then click OK, as shown in Figure 2-12.

   

   FIGURE 2-12 Adding a navigation node

2. In the navigation pane, expand your domain, click the System container, and then click Password Settings Container, as shown in Figure 2-13. Press Enter.

   

   FIGURE 2-13 Selecting the Password Settings Container

3. In the Tasks pane, click New, and then click Password Settings.

4. In the Create Password Settings: dialog box, configure the required settings for the new PSO, as shown in Figure 2-14.

   

   FIGURE 2-14 Creating a new PSO

5. Under the Directly Applies To heading, click Add, and in the Select Users Or Groups dialog box, type the name of the appropriate user or group, as shown in Figure 2-15, and then click OK.

   

   FIGURE 2-15 Selecting the group to which the PSO is linked

6. Click OK.

Delegate password settings management

To delegate the management of password settings, you can use the following Delegate Control Wizard in Active Directory Users and Computers, as described in the following procedure:

1. In Active Directory Users and Computers, locate and right-click the appropriate OU, and then click Delegate Control.

2. In the Delegation Of Control Wizard, on the Welcome page, click Next.

3. On the Users Or Groups page, click Add, and locate the user or group to which you want to delegate password settings management. Click OK, and then click Next.

4. On the Tasks To Delegate page, shown in Figure 2-16, in the Delegate The Following Common Tasks list, select the Reset User Passwords And Force Password Change At Next Logon check box, and then click Next. Click Finish when prompted.

   

   FIGURE 2-16 Delegating password settings management

Delegation of administrative functions is covered in detail in Chapter 1: Install and configure Active Directory Domain Services, Skill 1.3: Create and manage Active Directory groups and OUs, in the Delegate management of Active Directory with groups and OUs section.