Manage and maintain AD DS
- 5/4/2017
Many apps and services that you install on Windows Server run in the security context of a user account, known as a service account. In Skill 2.1 from Exam Ref 70-742 Identity with Windows Server 2016, learn how account policies enable you to control fundamental security features and how these features help secure your network—and the apps and services that run within it.
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
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:
On the target server(s), in Server Manager, click Tools, and then click Services.
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
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.
FIGURE 2-2 Adding an SPN
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:
In Server Manager, click Tools, and then click Services.
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
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:
In Server Manager, click Tools, and then click Group Policy Management.
In Group Policy Management, expand your forest, expand the Domains folder, and expand the domain you want to configure.
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
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.
FIGURE 2-6 Editing the domain password policy
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.
FIGURE 2-7 Editing the local password 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.
FIGURE 2-8 Editing the account lockout policy
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.
FIGURE 2-9 Unlocking an account
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.
FIGURE 2-10 Editing the Kerberos policy
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:
Create a Secure Admins global security group.
Add the required user accounts to the group.
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"
FIGURE 2-11 Creating and applying a PSO with Windows PowerShell
Creating PSOs with the Active Directory Administrative Center
To create and link PSOs using the Active Directory Administrative Center console, use the following procedure:
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
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
In the Tasks pane, click New, and then click Password Settings.
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
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
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:
In Active Directory Users and Computers, locate and right-click the appropriate OU, and then click Delegate Control.
In the Delegation Of Control Wizard, on the Welcome page, click Next.
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.
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.