Chapter 2. 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.

Skills covered in this chapter:

Configure service authentication and account policies

Maintain Active Directory

Configure Active Directory in a complex enterprise environment

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.

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 AUTHORITYSYSTEM), the local service (NT AUTHORITYLOCAL SERVICE), or the network service (NT AUTHORITYNETWORK 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:

Click here to view code image

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:

Click here to view code image

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:

Click here to view code image

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 ADATUMLON-IIS-GMSA.

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

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:

Click here to view code image

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

For example:

Click here to view code image

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.

Click here to view code image

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

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:

Click here to view code image

$computer = Get-ADComputer -Identity WEBSVR1

Set-ADComputer LON-SVR2 -PrincipalsAllowedToDelegateToAccount $computer

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 SERVICELON-SVR2$.

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

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.

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.

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.

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.

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.

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.

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

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:

Click here to view code image

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"

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.

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.

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.

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.

6. Click OK.

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.

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.

You can deploy read only domain controllers (RODCs) to branch offices or other locations where physical server security cannot be guaranteed. Because the RODC maintains a read-only copy of AD DS, it is important that you know how to configure and manage replication to the RODC, and how to manage a password replication policy to RODCs in your branch offices.

Most AD DS database operations are performed online; that is, the AD DS service is running and is accessible on the network. However, some operations, such as database maintenance, must be performed offline. Often, this means that you must restart the domain controller in directory services restore mode (DSRM). While the server is in DSRM, it cannot service client sign in requests, nor perform any other AD DS tasks. In order to enable your network to continue operating correctly, you must have additional domain controllers that can continue to provide directory-related services.

In Windows Server 2016, for some database-related tasks, you can also stop the AD DS service rather than restarting the domain controller in DSRM.

Using restartable AD DS to perform maintenance tasks can help you complete maintenance tasks more quickly, thereby reducing the downtime of your domain controller.

To compact your AD DS, use the following procedure:

1. On your domain controller, in Server Manager, click Tools, and then click Services to open the Services console.

2. Stop the Active Directory Domain Services service, as shown in Figure 2-17.

3. You are prompted to stop related services, such as DNS Server, Kerberos Key Distribution Center, Intersite Messaging, and DFS Replication. Click Yes to stop these services.

4. Open an elevated command prompt.

5. Run the NtdsUtil.exe command.

6. Run the following commands, shown in Figure 2-18:

Activate instance NTDS

Files

Compact to C:

Integrity

7. Complete the database maintenance by running the following commands at the elevated command prompt:

Quit

Quit

Copy C: tds.dit C:WindowsNTDS tds.dit

Del C:WindowsNTDS*.log

Exit

8. In the Services console, start the Active Directory Domain Services. Related services are also started.

You can perform metadata cleanup by using Active Directory Users and Computers and Active Directory Sites and Services. You can also use the NtdsUtil.exe command line tool.

1. On a domain controller, in Server Manager, click Tools, and then click Active Directory Users And Computers.

2. Navigate to the Domain Controllers folder, right-click the domain controller that you previously removed from the domain, and then click Delete. Click Yes to confirm the operation.

3. In the Deleting Domain Controller dialog box, shown in Figure 2-19, select the Delete This Domain Controller anyway check box, and then click Delete.

4. If the domain controller is a global catalog server, click Yes to confirm deletion.

5. If the domain controller that you removed holds one or more operations master roles, you must move the roles to an online domain controller. Click OK to move the roles to the suggested domain controller. You cannot use a different domain controller from the one suggested by the deletion process. If you want to use a different domain controller to host the operations master roles, move them after you complete the metadata cleanup process. You can read more about transferring operations master roles in Skill 1.1: Install and configure domain controllers, in the Transfer and seize operations master roles section.

6. In Server Manager, click Tools, and then click Active Directory Sites And Services.

7. Navigate to the site object that contains your removed domain controller. Expand the Servers folder, and locate the server that you removed.

8. Select the NTDS Settings. Right-click the NTDS Settings node, and then click Delete, as shown in Figure 2-20.

9. In the Active Directory Domain Services dialog box, click Yes to confirm deletion.

10. In the Deleting Domain Controller dialog box, select the Delete This Domain Controller Anyway check box, and then click Delete.

11. If the domain controller is a global catalog server, in the Delete Domain Controller dialog box, click Yes.

12. If the domain controller that you removed holds one or more operations master roles, you must move the roles to an online domain controller. Click OK to move the roles to the suggested domain controller. You cannot use a different domain controller from the one suggested by the deletion process. If you want to use a different domain controller to host the operations master roles, move them after you complete the metadata cleanup process.

13. Finally, in the navigation console, right-click the domain controller that was forcibly removed, and then click Delete. Click Yes to confirm the operation.

1. Run the NtdsUtil.exe command.

2. Run the following commands in order, as shown in Figure 2-21:

Metadata cleanup

Connections

Connect to server <server-name> (where <server-name> is an online domain controller)

Quit

Select Operation Target

List domains

Select Domain X (where X is the domain that contains the domain controller you forcibly removed)

List sites

Select Site Y (where Y is the site that contains the domain controller you forcibly removed)

List servers in site

Select Server Z (where Z is the offline domain controller you want to remove)

Quit

Remove selected server

In the Server Remove Confirmation Dialog window, click Yes to complete the process.

Quit

After you have enabled the Active Directory Recycle Bin, you see a Deleted Objects container in the Active Directory Administrative Center. When you delete AD DS objects, they are stored in the Deleted Objects folder, shown in Figure 2-23.

By default, deleted objects are recoverable for 180 days after their deletion. However, you can reconfigure this value by changing the tombstoneLifetime and msDS-DeletedObjectLifetime values using Windows PowerShell. For example, to change the recoverable period to 30 days in the Adatum.com domain, run the following two commands:

Click here to view code image

Set-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configur
ation,DC=Adatum,DC=com" –Partition "CN=Configuration,DC=Adatum,DC=com" –Replace:@
{"tombstoneLifetime" = 30}

Set-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configurati
on,DC=Adatum,DC=com" –Partition "CN=Configuration,DC=Adatum,DC=com" –Replace:@{"msDS-
DeletedObjectLifetime" = 30}

1. Open an elevated command prompt on a domain controller.

2. Run NtdsUtil.exe and then run the following commands, in this order, to complete the process:

Activate instance NTDS

Snapshot

Create

List all

Quit

After you create a snapshot, you can examine it by using NtdsUtil.exe to mount the snapshot. Once you have mounted it, you can use Active Directory Users and Computers to view the snapshot. To mount a snapshot, use the following procedure:

1. Open an elevated command prompt on a domain controller.

2. Run NtdsUtil.exe and then run the following commands, in this order, to complete the process:

Activate instance NTDS

Snapshot

List all

Mount <GUID>

(where <GUID> is the unique identity of the snapshot you want to mount)

Quit

Quit

3. At the elevated command prompt, run the following command:

dsamain -dbpath c:$snap_datetime_volumec$windows tds tds.dit -ldapport 50000

Leave the dsamain.exe command running and complete the next procedure to view a snapshot:

1. From Server Manager, open Active Directory Users And Computers.

2. Right-click the root node, and then click Change Domain Controller.

3. In the Change Directory Server dialog box, click <Type A Directory Server Name[:port] here>.

4. Type the name of the domain controller followed by the port number you specified earlier. For example, type LON-DC1:50000, and then press Enter, and then click OK.

You can now view the mounted snapshot. When you have finished examining the snapshot, use the NtdsUtil.exe command to unmount the snapshot:

1. In NtdsUtil.exe, run the following commands:

Activate instance NTDS

Snapshot

Unmount <GUID>

Quit

Quit

To provide protection against data loss or corruption of AD DS, you should consider implementing a backup and recovery solution. You can use the Windows Server Backup feature to provide this solution.

Windows Server Backup consists of a command line tool, Wbadmin.exe, and a graphical console, which you can use to backup, and if necessary, restore AD DS.

To install the Windows Server Backup feature, you can use Server Manager, as shown in Figure 2-24.

Windows Server Backup enables you to perform the following types of backup:

Bare Metal Recovery In the event of total server failure, perhaps following the loss of a physical hard disk, you can use a bare metal recovery backup to completely recover a server to the point when the backup was performed.

System State The system state consists of the server’s configuration, including the roles and features installed. This includes the AD DS database and SYSVOL content.

Selected Volumes Allows you to perform a backup of specific folders, or even files.

After installing the Windows Server Backup feature, you can use Windows Server Backup to back up AD DS using the following procedure.

1. On your domain controller, click Start, point to Windows Accessories, and then click Windows Server Backup.

2. In Windows Server Backup, in the navigation pane, right-click Local Backup, and then click Backup Once.

3. In the Backup Once Wizard, on the Backup Options page, click Different Options, and click Next.

4. On the Select Backup Configuration page, click Custom, and then click Next.

5. On the Select Items For Backup page, click Add Items.

6. In the Select Items dialog box, select the System State check box, as shown in Figure 2-25, and then click OK.

7. On the Select Items For Backup page, shown in Figure 2-26, click Next.

8. On the Specify Destination Type page, select the destination. Choose between Local drives and Remote Shared folder. Click Next.

9. If you selected a remote folder, on the Specify Remote Folder page, in the Location box, type the UNC name to the shared folder that you want to use as a backup target, as shown in Figure 2-27.

10. In the Access Control section, click either Do Not Inherit or Inherit. This setting controls who has access to the target backup files. If you want to limit access to the user that performs the backup, click Do Not Inherit, and then click Next. Otherwise, to enable the backup to be accessible by everyone with permissions on the remote folder, click Inherit, and then click Next.

11. On the Confirmation page, click Backup.

However, you might decide that you would prefer to restore the AD DS on a domain controller rather than replace the server unit; perhaps because it contains other apps, services, or data that you cannot easily replace. Or perhaps because you just need to recover a few deleted objects. In this situation, you can perform an AD DS restore operation.

When you restore AD DS, it is important to consider the nature of the database; it is a multimaster database, which means that even while one domain controller is offline, changes can still take place on other instances of the database on other domain controllers. If you simply restore the AD DS database to a point in time when you last performed a backup, then that point in time is overwritten by AD DS replication from other domain controllers when the restore operation is completed. This might be desirable; after all, if there have been changes since the last backup, typically, you would want to include them.

However, if you are attempting to restore only a part of your AD DS, you don’t want to overwrite it with replicated changes. For example, rather than dealing with a failed domain controller, you attempt to recover objects that were accidentally deleted. If you performed a backup operation, and later inadvertently deleted an AD DS object, that deletion would be replicated after your restore operation.

To help mitigate this issue, you can perform either nonauthoritative restore or authoritative restore operations. Using an authoritative restore means that the restored data is not overwritten by replicated changes.

To perform a nonauthoritative AD DS restore operation, start your domain controller in DSRM. Then, open the Windows Server Backup console and use the Restore Wizard to restore the System State data from a previous backup. This is a straightforward procedure. Then start your domain controller normally. Changes made since the last backup are now replicated to the domain controller.

To perform an authoritative AD DS restore operation, start the domain controller in DSRM, restore the System State, and then open an elevated command prompt. At the command prompt, run the NtdsUtil.exe command. Then run the following commands:

Authoritative restore

Restore object <object DN>

The object’s DN will look something like this: CN=Adam ,OU=Sales,DC=adatum,DC=com. Restart your domain controller normally. If you want to mark an entire OU as authoritative, at the NtdsUtil.exe prompt, run the following commands:

Authoritative restore

Restore subtree <object DN>

The object(s) marked as authoritative are not overwritten, and are replicated from the restored domain controller throughout your forest.

Deploying RODCs is covered in Chapter 1: Install and configure Active Directory Domain Services, Skill 1.1: Install and configure domain controllers, in the Install and configure an RODC section.

However, to improve usability, you can define that specific user and computer accounts can be cached on the RODC, enabling local authentication to occur. You do this by defining an RODC password replication policy. Generally, you would only add the users and computers that are in the same local site as the RODC to the replication policy.

To configure a replication policy for an RODC, you use two Domain Local security groups:

Allowed RODC Password Replication Group Add user or computers to this group to enable their passwords to be cached on the RODC.

Denied RODC Password Replication Group Add user or computers to this group to prevent their passwords to be cached on the RODC.

These groups are automatically created when you deploy an RODC and enable you to configure the password replication policy on all RODCs. But if you have multiple branch offices, and therefore multiple RODCs, it is more secure to configure a separate group for each RODC for allowed password replication. In this instance, remove the Allowed RODC Password Replication Group, and add a group that you manually created, and then add the required members for that branch. Use the following procedure to complete this task:

1. In Active Directory Users and Computers, create a global security group that contains users and computers that have permissions.

2. Locate the Domain Controllers OU.

3. Right-click your RODC, and click Properties.

4. In the Properties dialog box, on the Password Replication Policy tab, shown in Figure 2-28, remove the Allowed RODC Password Replication Group.

5. Click Add, and as shown in Figure 2-29, click Allow Passwords For The Account To Replicate To This RODC for the account you are adding to the password replication policy, and then click OK.

6. In the Select Users, Computers, Service Accounts, or Groups dialog box, enter the group name whose members’ passwords are to be replicated to this RODC, and then click OK twice.

7. Add the required users and computers to the group you just added.

You can complete a similar procedure to modify the server specific deny replication policy. Remove the Denied RODC Password Replication Group from the Password Replication Policy, and add your own group with members whose passwords won’t be replicated to the target RODC.

You can use the Advanced view on the Password Replication Policy tab to view which user or computer passwords are replicated to the RODC. You can also determine the effective policy for a selected user or computer. Use the following procedure:

1. In Active Directory Users and Computers, in the Domain Controllers OU, right-click your RODC, and click Properties.

2. On the Password Replication Policy tab, click Advanced.

3. In the Advanced Password Replication Policy dialog box, on the Policy Usage tab, shown in Figure 2-30, in the Display Users And Computers That Meet The Following Criteria list, click:

Accounts Whose Passwords Are Stored On This Read-Only Domain Controller Enables you to see which users and computers have had their passwords cached on the RODC.

Accounts That Have Been Authenticated To This Read-Only Domain Controller Enables you to see which users and computers have signed in using the RODC.

4. Use the Prepopulate Passwords button to retrieve passwords for listed users. This can help reduce sign in time for configured users.

5. On the Resultant Policy tab, add users or computers to determine what the resultant password policy is for the selected objects. This is useful when you have multiple Allow or Deny groups configured on the Password Replication Policy tab.

Schema A forest-level partition that rarely changes and holds the forest schema.

Configuration A forest-level partition that also changes rarely and contains the configuration data for the forest.

Domain A domain-wide partition that changes frequently, and a writeable copy of the partition is stored on all domain controllers.

Changes in the schema and configuration partitions are infrequent. Consequently, the significant bulk of AD DS replication traffic is domain partition changes, such as the creation of new objects (users, groups, computers) and the update of their attributes (properties such as passwords, group memberships, and so on). As an AD DS administrator, one of your roles is to monitor and manage the replication topology and traffic.

AD DS replication is the process of synchronizing the various copies of the AD DS database throughout your forest. This replication has the following characteristics:

Multimaster With the exception of certain specific elements, AD DS is a multimaster database. In essence, this means all copies are writable and can be updated. This offers the advantage of removing single points of failure, and can also improve performance.

Pull-based Domain controllers pull changes from their replication partners rather than push changes.

Fine-grained To avoid replication conflicts, replication is based on attributes of objects and not whole objects. This reduces the chances of a conflict that might otherwise occur if the same object is changed on two domain controllers at about the same time.

Site-aware Because most changes occur in the domain partition, all domain controllers within a domain request these changes. To help manage slower network links between locations, you can configure AD DS sites, and then configure how AD DS replication is handled between sites. This is known as intersite replication.

Automatically generated topology Windows Server generates the AD DS replication topology automatically, creating a resilient and efficient infrastructure. In many circumstances, you might not need to manually reconfigure the topology.

When discussing AD DS replication, it is helpful to keep in mind that there are two types of replication:

Intrasite This occurs between domain controllers in the same AD DS site. Windows Server manages AD DS replication on the assumption that high-speed persistent networks connect domain controllers within a site. Intrasite replication usually requires little manual intervention because Windows Server efficiently manages it automatically. However, you must devise and implement a suitable AD DS site infrastructure and place domain controllers in the appropriate site.

Intersite This occurs between domain controllers in different AD DS sites. Windows Server manages replication on the assumption that domain controllers might not be connected by persistent high-speed networks. You have more manual control over the replication process, including the interval and schedule.

A component called the knowledge consistency checker (KCC) generates an optimized topology for replication by creating these connection objects automatically. This topology contains sufficient connection objects to create a maximum of three hops between any two domain controllers, thereby reducing delays in the propagation of replication data.

If you deploy an additional domain controller in a site, or conversely, remove one, the knowledge consistency checker regenerates the replication topology to account for the change.

Figure 2-31 shows the connection objects in the Default-First-Site-Name site in the Adatum.com domain.

Although you can manually create persistent connection objects within a site if you want, this is not usually necessary and not recommended; this is because the knowledge consistency checker does not evaluate manually created connection objects. It is more likely that you might need to create and configure connection objects to manage intersite replication. This is discussed in Skill 2.3: Configure Active Directory in a complex enterprise environment, in the Configure AD DS sites and subnets section.

You can view and manage AD DS replication by using the Active Directory Sites and Services tool, as shown in Figure 2-31. For example, you can force replication over a connection object between two domain controllers by using the following procedure:

1. In Active Directory Sites and Services, navigate to the server object that you want to update.

2. Under the server object, click the NTDS Settings node, and in the details pane, right-click the <automatically generated> object.

3. Click Replicate Now on the context menu. This pulls changes from the designated replication partner.

You can also use Repadmin.exe and the DcDiag.exe command-line tools:

Repadmin Use this tool to check the status of replication on your domain controllers or to reconfigure the replication topology:

Display the replication partners for a domain controller by using repadmin /showrepl DC_LIST, as shown in Figure 2-32. Replace DC_LIST with the names of your domain controller(s). You can use an asterisk as a wildcard.

Display connection objects for a domain controller by using repadmin /showconn DC_LIST.

Display metadata about an object by using repadmin /showobjmeta DC_LIST Object. Replace object with the AD DS distinguished name or GUID of your object.

Launch the knowledge consistency checker by using repadmin /kcc.

Force replication between partners by using repadmin /replicate Destination_DC_LIST Source_DC_Name Naming_Context.

Synchronize a domain controller with all replication partners by using repadmin /syncall DC/A /e.

DcDiag Use Dcdiag.exe to perform tests against your AD DS replication topology, as shown in Figure 2-33. You can also use several parameters to run specific tests, including: FrsEvent, DFSREvent, Intersite, KccEvent, Replications, Topology, and VerifyReplicas.

Use with the following parameters to perform.

You can also use a number of Windows PowerShell cmdlets, as shown in 2, to monitor and manage replication in Windows Server 2016.

The knowledge consistency checker automatically creates connection objects for RODCs. But if you are experiencing problems, use the Repadmin.exe command-line tool to force the knowledge consistency checker to regenerate the topology. Use the following high-level procedure:

1. Add the site with the RODC to a site link and ensure that the selected site link also contains a site with a writable domain controller.

2. Force replication of the configuration partition to the RODC by using Repadmin.exe.

3. Regenerate the replication topology by using repadmin /kcc on the RODC.

In Windows Server 2008 and newer, you use DFS Replication (DFSR) to manage SYSVOL replication, replacing the FRS replication infrastructure. DFSR provides for a more efficient and reliable means to replicate SYSVOL.

If you upgraded your domain controllers from Windows Server 2003, it is possible that they might still be using FRS to replicate SYSVOL. You can check this by using the Dfsrmig.exe command-line tool as follows:

1. Open an elevated command prompt.

2. Run the Dfsrmig.exe /GetGlobalState command.

If the returned message is Current DFSR global status: ‘Eliminated’, your SYSVOL replication is already using DFSR. If you receive the message DFSR migration has not yet initialized, then you should migrate to DFSR. During the migration, the configuration moves through four phases, or states:

State 0 This is the start state. FRS is being used to replicate SYSVOL.

State 1 The prepared state. FRS continues to replicate SYSVOL, however, the local DFSR service creates a replicated copy of SYSVOL.

State 2 The redirected state. DFSR begins to replicate SYSVOL, and FRS maintains only a local replica of SYSVOL.

State 3 The eliminated state. FRS is no longer used, and DFSR provides all SYSVOL replication.

Use the following procedure to migrate SYSVOL replication to DFSR:

1. At the command prompt, run dfsrmig /setglobalstate 1. Then run the Dfsrmig.exe /GetMigrationState command to verify all domain controllers have reached the prepared state.

2. At the command prompt, run dfsrmig /setglobalstate 2. Then run the Dfsrmig.exe /GetMigrationState command to verify all domain controllers have reached the redirected state.

3. At the command prompt, run dfsrmig /setglobalstate 3. Then run the Dfsrmig.exe /GetMigrationState command to verify all domain controllers have reached the eliminated state.

4. On each domain controller, open the Services console and verify that the File Replication Service is disabled.

As your network grows and spans multiple locations, it is necessary to configure AD DS sites to help optimize network services, including AD DS replication. Before you create sites, it is also necessary to create subnet objects that map to the physical Internet Protocol (IP) subnets in your network.

Forest A collection of domains sharing a common schema and bound by automatically generated two-way trust relationships. Generally, using a single forest is desirable for most organizations because it simplifies administration. However, reasons to consider using multiple forests include the requirement to:

Provide for complete administrative separation between disparate parts of your organization.

Support different object types and attributes in the AD DS schema in different parts of your organization.

Domain A logical administrative containing users, groups, computers, and other objects. Parent-child and trust relationships define your domain structure. A domain does not provide for administrative separation because all domains in a forest have the same forest administrator: the Enterprise Admins universal security group.

Tree A collection of AD DS domains that share a common root domain and have a contiguous namespace. Reasons for using multiple trees include the requirement to support multiple logical namespaces within your organization, perhaps as a result of mergers or acquisitions.

Essentially, the process for deploying an additional forest is identical to creating the first forest. This procedure is discussed in the “Install a new forest” section in Chapter 1, “Install and configure Active Directory Domain Services.”.

After you have deployed the new forest, you can configure any required trust relationships between the forests to support your administrative and business needs.

You have two choices when adding a new domain:

Child Domain Creates a subdomain of the specified parent domain. In other words, the new domain is created in the existing domain tree.

Tree Domain Creates a new tree in the same forest. This option is useful when you want to create multiple DNS domain names in your AD DS forest infrastructure to support your organizational needs, but do not need, or want, to separate administrative function as is possible with a separate forest.

These procedures are covered in Chapter 1: Install and configure Active Directory Domain Services, Skill 1.1: Install and configure domain controllers, in the Add A New Domain Controller In A New Domain section. After you have deployed the new domain, you do not need to configure any additional trusts.

Forest Functional Level Determines which forest-level features are available. Also defines the minimum domain functional level for domains in your forest. Select from:

Windows Server 2008

Windows Server 2008 R2

Windows Server 2012

Windows Server 2012 R2

Windows Server 2016

Domain Functional Level Determines the domain-level features available in your domain. Select from:

Windows Server 2008

Windows Server 2008 R2

Windows Server 2012

Windows Server 2012 R2

Windows Server 2016

You can raise the forest functional level by using the following procedure:

1. In the Active Directory Domains And Trusts console, in the navigation pane, right-click the Active Directory Domains And Trusts node, and then click Raise Forest Functional Level.

2. In the Raise Forest Functional Level dialog box, the current forest functional level is displayed, as shown in Figure 2-34.

3. In the Select An Available Forest Functional Level list, click the desired level, and then click Raise.

To raise a domain’s domain functional level, use the following procedure:

1. In the Active Directory Domains And Trusts console, in the navigation pane, locate and right-click the appropriate AD DS domain, and then click Raise Domain Functional level.

2. In the Raise Domain Functional Level dialog box, the current domain functional level is displayed.

3. In the Select An Available Domain Functional Level list, click the appropriate level, and then click Raise.

The UPN suffix is generally the domain name where you are adding the account. However, you can define additional UPN suffixes by using the Active Directory Domains and Trusts console. To do this, use the following procedure:

1. From Server Manager, open the Active Directory Domains And Trusts console.

2. In the console, right-click the Active Directory Domains And Trusts node in the navigation pane, and then click Properties.

3. In the Active Directory Domains And Trusts [Server name] dialog box, on the UPN Suffixes tab, shown in Figure 2-36, in the Alternative UPN suffixes box, type a new suffix, and then click Add.

4. After you have added all the suffixes you require, click OK.

Next, you must modify the user accounts that you want to use the new suffix. You can do this using the following procedure:

1. Open Active Directory Users And Computers and locate the accounts that you want to modify.

2. Right-click the accounts, and then click Properties.

3. In the Properties For Multiple Items dialog box, shown in Figure 2-37, on the Account tab, select the UPN suffix check box.

4. In the UPN suffix list, click the new suffix, and then click OK.

You can also use Windows PowerShell to reconfigure the UPN suffix for multiple accounts by using the get-ADUser and Set-ADUser cmdlets. For example, to change the UPN suffix for all users in the Sales OU in the Adatum.com domain to Sales.Contoso.com, use the following procedure:

1. Open Windows PowerShell on a domain controller.

2. Run the following script:

Click here to view code image

$new_suffix = "Sales.Contoso.com"

$users = Get-ADUser -Filter {UserPrincipalName -like '*'} -SearchBase
"OU=Sales,DC=Adatum,DC=Com"

foreach ($user in $users) {

    $userName = $user.UserPrincipalName.Split('@')[0]

    $UPN = $userName + "@" + $new_suffix

        Write-Host $user.Name $user.UserPrincipalName $UPN

    $user | Set-ADUser -UserPrincipalName $UPN }

In Windows Server 2016, domains in the same forest are configured automatically with two-way transitive trusts so that, in principle, a user in any domain in the forest has the potential to access a resource anywhere else in the forest. By default, in a multi-domain forest, the following trust types exist:

Parent/child Two-way transitive trust between a parent domain and its child domain.

Tree-root Two-way transitive trust between a new AD DS domain tree and the existing AD DS forest root domain.

But you can also create trusts manually to satisfy certain technical or administrative requirements. These are:

Forest A transitive one-way or two-way trust, depending on configuration, between two AD DS forests. Enables users in one forest (or both forests) to enable resources in the other.

External A non-transitive one-way or two-way trust, depending on configuration, between your AD DS forest and another AD DS domain, such as an older Windows NT 4.0 domain. Enables users in your forest to access resources in the other domain, and users in the remote forest to access your resources.

Realm A transitive or non-transitive, one-way or two-way trust, depending on configuration, that enables authentication between your Windows Server AD DS forest and a Kerberos v5 realm based on a non-Windows directory service.

Shortcut A non-transitive one-way or two-way trust, depending on configuration, between domains in your AD DS forest that can help improve authentication performance. Use shortcut trusts for domains within the same forest but in different AD DS domain trees.

To create trust relationships, you use the Active Directory Domains and Trusts tool. It is important to note that to configure any of these trusts, it must be possible for the two parties in the trust to be able to resolve one another’s names; this requires DNS configuration. For example, to configure a forest trust, each domain controller that you use to configure the trust must be able to resolve the SRV records for the remote forest.

1. Configure DNS so that domain controllers in each forest can resolve one another’s names and SRV records. Create a DNS stub zone (or configure conditional forwarding) for the remote DNS zone.

2. Open the Active Directory Domains And Trusts console on a domain controller in the first AD DS forest.

3. Right-click the forest root domain in the navigation pane, and then click Properties.

4. In the Domain Properties dialog box, click the Trusts tab, shown in Figure 2-38, and then click New Trust.

5. In the New Trust Wizard, click Next, and then, on the Trust Name page, in the Name box, type the FQDN of the remote forest, as shown in Figure 2-39, and then click Next.

6. On the Trust Type page, shown in Figure 2-40, click Forest trust, and then click Next.

7. On the Direction Of Trust page, shown in Figure 2-41, select the appropriate direction. Choose between Two-Way, One-Way Incoming, and One-Way Outgoing. For example, click Two-Way, and then click Next.

8. On the Sides Of Trust page, shown in Figure 2-42, click Both This Domain And The Specified Domain, and then click Next.

9. On the User Name And Password page, enter the credentials required to configure the trust in the remote forest, and then click Next.

10. On the Outgoing Trust Authentication Level-Local Forest page, select between the two available options, and then click Next.

Forest-Wide Authentication Windows Server automatically authenticates users from the remote forest for all resources in the local forest. Select this option if both forests are managed by the same organization.

Selective Authentication Windows Server does not automatically authenticate users from the remote forest for resources in the local forest. This is the appropriate option if your two forests are managed by separate organizations. For more details, see the section below: SID filtering and trust authentication scope.

11. On the Outgoing Trust Authentication Level-Specified Forest page, select between the two available options, and then click Next:

Forest-Wide Authentication Windows Server automatically authenticates users from the local forest for all resources in the remote forest. Select if both forests are managed by the same organization.

Selective Authentication Windows Server does not automatically authenticate users from the local forest for resources in the remote forest. Select if your two forests are managed by separate organizations. For more details, see the section below: SID filtering, and trust authentication scope.

12. Click Next twice, and then on the Confirm Outgoing Trust page, click Yes, confirm the outgoing trust. This enables you to verify that the trust is working. Click Next.

13. On the Confirm Incoming Trust page, click Yes, confirm the incoming trust. This enables you to verify that the trust is working. Click Next.

14. Click Finish, and then, in the Domain Properties dialog box, shown in Figure 2-43, click OK.

After you configure the trust, you can then assign access to resources. A common way to achieve this is to select remote users and groups through the trust by using the Locations option when browsing users and groups, as shown in Figure 2-44.

1. Configure DNS so that domain controllers in each forest can resolve one another’s names and SRV records.

2. In the Active Directory Domains And Trusts console on a domain controller in the first AD DS forest, right-click the forest root domain in the navigation pane, and then click Properties.

3. In the Domain Properties dialog box, click the Trusts tab, and then click New Trust.

4. In the New Trust Wizard, click Next, and then, on the Trust Name page, in the Name box, type the FQDN of the remote forest, and then click Next.

5. On the Trust Type page, click External Trust, and then click Next.

6. On the Direction Of Trust page, select the appropriate direction. Choose between Two-way, One-Way Incoming, and One-Way outgoing. For example, click Two-Way, and then click Next.

7. On the Side Of Trust page, click Both This Domain And The Specified Domain, and then click Next.

8. On the User Name And Password page, enter the credentials required to configure the trust in the remote forest, and then click Next.

9. On the Outgoing Trust Authentication Level-Local Domain page, choose between Domain-Wide Authentication and Selective Authentication, and then click Next. For more details, see the section below: SID filtering and trust authentication scope.

10. On the Outgoing Trust Authentication Level-Specified Domain page, choose between Domain-Wide Authentication and Selective Authentication and then click Next. For more details, see the section: SID filtering and trust authentication scope.

11. On the Trust Selections Complete page, click Next.

12. On the Trust Creation Complete page, click Next.

13. On the Confirm Outgoing Trust page, click Yes, and confirm the outgoing trust. This enables you to verify that the trust is working. Click Next.

14. In the Active Directory Domain Services dialog box, shown in Figure 2-45, acknowledge the message about SID filtering, and click OK. For more details, see the section: SID filtering and trust authentication scope.

15. In the Domain Properties dialog box, click OK.

1. Configure DNS so that domain controllers in each security authority can resolve one another’s names.

2. In Active Directory Domains And Trusts, in the navigation pane, right-click the domain node for the domain with which you want to establish a shortcut trust, and then click Properties.

3. In the Domain Properties dialog box, on the Trusts tab, click New Trust, and then click Next.

4. On the Trust Name page, type the FQDN of the domain, and then click Next.

5. On the Trust Type page, click Realm trust, as shown in Figure 2-46, and then click Next.

6. Complete the wizard using the guidance provided for forest or external trusts.

1. In Active Directory Domains And Trusts, in the navigation pane, right-click the domain node for the domain with which you want to establish a shortcut trust, and then click Properties.

2. In the Domain Properties dialog box, on the Trusts tab, click New Trust, and then click Next.

3. On the Trust Name page, type the FQDN of the domain, and then click Next.

4. On the Trust Type page, click Shortcut trust, and then click Next.

5. Complete the wizard using the guidance provided for forest or external trusts.

SID Filtering After you set up a forest of external trust, you are warned that SID filtering has been enabled. SID filtering controls the way that SIDs are used during authentication to resources in a trusting domain. If a user belongs to groups, the SIDs of those groups are presented to resource-holding servers through the trust when the user attempts authentication.

If a user that belongs to the Domain Admins group signs in at a trusted domain, that user’s SID history contains an entry for a group, Domain Admins, which also exists in your resource-holding domain. This gives the remote user potentially more access than is desirable. SID filtering helps prevent this by instructing the resource-holding domain to filter out SIDs from the account-holding domain that is not the primary SIDs of security principals.

Authentication Scope When you create a forest or external trust, you are prompted to configure the scope of authentication. This occurs on the Outgoing Trust Authentication Level pages of the New Trust Wizard for both the local, and remote forests or domains, depending on whether it is a forest or external trust you are configuring. You choose between forest-wide (or domain-wide) authentication, and selective authentication.

Choosing forest-wide (or domain-wide) effectively means that all users from the remote forest (or domain) are considered to be Authenticated Users. This limits your administrative control – or simplifies it, depending upon your viewpoint.

However, if you choose Selective authentication, although all users in the remote forest (or domain) are considered to be trusted, you must explicitly grant them permissions to authenticate against server resources in your local forest (or domain). This provides for more control, but can be time-consuming to configure.

If the remote forest (or domain) is a part of your organization, it is usually acceptable to choose forest-wide (or domain-wide) authentication during the setup of the trust. If, however, the remote forest (or domain) is part of a different organization, choose selective authentication when prompted.

To further simplify administration, all child name suffixes are also routed. Thus, users with the suffix Sales.Contoso.com, which is a subordinate of Contoso.com, have a suffix that is a child of Contoso.com.

If, for any reason, you want to disable name suffix routing through a forest trust, you can do so by using the Active Directory Domains and Trusts console by selecting the appropriate domain in the navigation pane. Then, use the following procedure:

1. In the Active Directory Domains And Trusts console, in the navigation pane, right-click the appropriate domain, and then click Properties.

2. In the Domain Properties dialog box, on the Trusts tab, under either Domains Trusted By This Domain (Outgoing Trusts) or Domains That Trust This Domain (Incoming Trusts), click the appropriate forest trust, and then click Properties.

3. Click the Name Suffix Routing tab, and under Name Suffixes In The <domain name> Forest, perform one of the following:

Click the suffix that you want to enable, and then click Enable.

Click the suffix that you want to disable, and then click Disable.

4. Click OK twice.

Information about where a computer is can be used by that computer to locate services that are adjacent rather than distant. For example, using a local domain controller to attempt to sign in rather than one that is physically remote can speed up sign in times.

Replication Management You can exert more control over intersite replication than is possible with intrasite replication.

Group Policy Application You can create Group Policy Objects (GPOs) and link them to site objects. This applies the policy settings to users and computers that are at a specific location.

Service Location You can use information stored in a computer’s service location (SRV) resource record to determine which site it is in.

When you deploy AD DS, a default site called Default-First-Site-Name is created. All domain controllers are configured as part of this site until you create additional sites and move your domain controllers into those sites.

To create an AD DS site, use the following procedure:

1. In Server Manager, click Tools, and then click Active Directory Sites And Services.

2. In Active Directory Sites And Services, in the navigation pane, click Sites.

3. Right-click Sites, and then click New Subnet.

4. In the New Object – Site dialog box, shown in Figure 2-47, in the Name box, type the name for your site. For example, type London.

5. In the Link Name list, click the appropriate site link object. It is likely that at this stage, only the DEFAULTIPSITELINK object exists. This is the default connection object created to support the AD DS intersite replication topology. You can create and configure your own site links later. For now, click DEFAULTIPSITELINK, and click OK.

6. In the Active Directory Domain Services pop-up dialog box, click OK to acknowledge the message about next steps.

7. Create your additional sites. Initially, use the DEFAULTIPSITELINK object for the selected link object for each site.

You can also use the Windows PowerShell New-ADReplicationSite cmdlet. For example, to create a new site called London, use the following command:

New-ADReplicationSite -Name "London"

To create an AD DS subnet, use the following procedure:

1. In Server Manager, click Tools, and then click Active Directory Sites And Services.

2. In Active Directory Sites And Services, in the navigation pane, expand Sites, and then click Subnets.

3. Right-click Subnets, and then click New Subnet.

4. In the New Object – Subnet dialog box, shown in Figure 2-48, in the Prefix box, type the prefix for your IP subnet. For example, type 172.16.0.0/16.

5. In the Select A Site Object For This Prefix, select the appropriate site. For example, click London, and then click OK.

6. Create any additional subnets for your organization, and map each to the appropriate site. Remember that a site can contain multiple subnets, but a subnet can only be associated with a single site.

You can also use the Windows PowerShell New-ADReplicationSubnet cmdlet. For example, to create a subnet called 172.16.0.0/16, use the following command:

Click here to view code image

New-ADReplicationSubnet -Name "172.16.0.0/16"

To create the same subnet, but link it to a site called London, use the following command:

Click here to view code image

New-ADReplicationSubnet -Name "172.16.0.0/16" -Site London

To create a site link, use the following procedure:

1. In Active Directory Sites And Services, in the navigation pane, expand Sites, expand Inter-Site Transports, and then click IP.

2. Right-click IP, and then click New Site Link.

3. In the New Object – Site Link dialog box, shown in Figure 2-49, in the Name box, type a meaningful descriptive name of what the site link connects. For example, type London <> Wincanton.

4. In the Sites Not In This Site Link list, click the sites (at least two) that are interconnected by this site link, and then click Add>>.

5. Click OK.

You can also use the Windows PowerShell New-ADReplicationSiteLink cmdlet. For example, to create a new site link between the sites London and NewYork, use the following command:

Click here to view code image

New-ADReplicationSiteLink -Name "London-NewYork" -SitesIncluded London,NewYork

Next, you must configure the site link:

1. In the details pane, right-click the site link, and then click Properties.

2. In the Site Link Properties dialog box, shown in Figure 2-50, configure the following properties, and then click OK.

Cost This is an arbitrary number that should represent a preference as to whether the link should be used if there are multiple paths available. For instance, if there are two possible paths between two sites in your infrastructure, but one has a higher end-to-end cost, the lower cost path is used, unless it’s unavailable. The default value is 100.

Replicate Every This is the replication interval and defaults to 180 minutes. Reduce this to help to ensure any changes are propagated more quickly throughout the domain controllers in your organization. 15 minutes is the lowest configurable value.

Schedule The schedule is the replication availability window. During the configured time, replication can occur at the specified ‘Replicate every’ interval. If you want to prevent replication from occurring during working hours, for example, you can use the Schedule to configure that.

After you have created all the required site links, and moved all the domain controllers into the correct sites, if you no longer need the DEFAULTIPSITELINK, you can delete it.

Site link bridges enable you to create transitive links between sites when site links cannot provide the required behavior. There are two situations in which site link bridges might be required:

Your IP network is not fully routed You can enable site link bridges to enable transitive links where your IP network is not capable of doing this automatically.

You want more control over the replication flow You can control how the replication of AD DS flows through your sites by disabling the Bridge All Site Links option, and then creating site link bridges. Replication traffic flows transitively through sites linked by site link bridges, but does not route beyond the site link bridge.

To move a domain controller between sites after deployment, use the following procedure:

1. In Active Directory Sites And Services, in the navigation pane, expand the Default-First-Site-Name object.

2. Expand the Servers folder, and then click the server that you want to move.

3. Right-click the server, and then click Move.

4. In the Move Server dialog box, shown in Figure 2-51, click the site to which you want to move the domain controller, and then click OK.

You can also use the Windows PowerShell Move-ADDirectoryServer cmdlet to move domain controllers between sites.

You do not need to move servers or client computers. These devices determine their own site placement by using their IP configuration to determine their subnet. From AD DS, they then determine their site.

After you have completed the process of creating and configuring your subnets, sites, and site links, and after you have moved your domain controllers to the appropriate sites, as shown in Figure 2-52, it is then a good idea to run a knowledge consistency check to rebuild the replication topology. You can do this from Active Directory Sites and Services by locating the NTDS Settings object under the server object in a given site. Right-click the NTDS Settings object, point to All Tasks, and then click Check Replication Topology.

A typical SRV record consists of a number of elements:

Service Name And Port Identifies the service and the associated Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) port. For example, common SRV records include Lightweight Directory Access Protocol (LDAP) over TCP port 389, Kerberos over port 88, the Kerberos V5 authentication protocol (KPASSWD) on port 464, and the global catalog service on port 3268.

Protocol Indicates whether TCP or UDP is used. A service can use both, but is required to register separate SRV records that indicate this.

Hostname Provides the name of the host offering the service. Client computers must then use host records in DNS to determine the IP address being used by the specified host.

Options SRV records are also assigned preference, weight, and priority values. These are used when there are multiple records that point to the same service or server and you want to control which servers are used first. For example, an AD DS domain controller registers its Kerberos authentication service DNS resource records with a priority value of 0 and a weight of 100, as shown in Figure 2-53. You can change these initial values to determine which host offering the Kerberos authentication service is used by clients. DNS clients attempt to use the server with the lowest priority value. If multiple servers have the same priority value, clients use the server in proportion to their weight values.

SRV records are stored in DNS in a hierarchy that includes not only the protocol information, but also the site information; this enables computers to locate services based on the AD DS site in which the service is offered. Figure 2-XY shows the DNS structure of the registered SRV records.

Generally, you do not need to manually register or maintain SRV records. Assuming that your DNS servers are configured with DNS zones that support dynamic updates, when you add domain controllers, or move them to different sites, they update their DNS records automatically.

Add the subnet to a site If there are only a few computers at a branch office that do not merit a domain controller, to ensure client computers can locate domain services, add the subnet at that location to an adjacent site.

Deploy an RODC If there are sufficient computers to merit a local domain controller, deploy an RODC.

Rely on automatic site coverage A domain controller from an adjacent site also registers its SRV records for the smaller site enabling client computers to locate that domain controller.

SPNs enable client computers to locate services.

You can use PSOs to create account policies for specific users or groups of users.

The NtdsUtil.exe command-line tool enables you to perform many AD DS database administration tasks, including offline defragmentation.

Metadata cleanup in the process of cleaning up the AD DS database following the forced removal of a domain controller.

Enabling the Active Directory Recycle Bin can make recovering AD DS objects much simpler in many circumstances but is not a replacement for backup.

RODCs are ideal for deployment to less physically secure locations, such as branch offices.

You can configure multiple UPN suffixes in your AD DS forest to support specific naming conventions without needing to change the domain name(s) or reconfigure DNS settings.

Trust relationships enable a security principal in one domain, such as a user or computer, to potentially gain access to a resource in another domain.

Forest-wide authentication is recommended when you implement a forest trust between two AD DS forests, both of which are managed by your organization.

In simple networked environments, you can use the default intersite configuration objects: Default-First-Site-Name and DEFAULTIPSITELINK.

SRV resource records enable computers to locate domain-wide services, or services available in their local site.

You work in support at A. Datum. As a consultant for A. Datum, answer the following questions about managing advanced AD DS environments for the A. Datum organization:

1. You are planning a new AD DS deployment. The business consists of two separate divisions, each with their own IT departments and management structures. What high-level AD DS structure does this suggest and why?

2. A fellow administrator has deployed an app that runs on servers and connects to a SQL Server database at the backend. Clients connect to the app to retrieve customer data. After 42 days, you experience a problem with users being unable to access their data. What might be going on here? What could you do to resolve the issue?

3. Your AD DS forest consists of two trees, one for Adatum.com, and one for Contoso.com. Contoso.com consists of multiple child domains: Europe.Contoso.com, Americas.Contoso.com, and Pacific.Contoso.com. Each of these has child domains according to business group. For example, Sales.Europe.Contoso.com. Users in the Sales.Pacific.Contoso.com domain need to access resources in the Adatum.com, but they are finding access is slow. You have eliminated physical network performance issues, so what else might be going on, and what could you do to mitigate the problem?

1. This scenario initially suggests using multiple forests. This is because a separate AD DS forest, each with its own separate management team, could represent each division. However, it is important to ask questions of the management team and look at how the IT departments work. It might not be necessary for the AD DS deployment to use multiple forests. Creating a single forest, perhaps with multiple trees to support naming might be appropriate. In other words, the fact that the organization has separate IT departments in two divisions doesn’t necessarily mean you have to configure your AD DS infrastructure to perpetuate that.

2. The 42-day interval hints at the problem. Users, by default, are required to change their passwords every 42 days. Perhaps when your colleague installed the app, he or she used a standard user account to run the service that connects to the SQL Server? If this is the case, you must use a gMSA to configure the service that connects to the SQL Server. This makes managing passwords for service accounts much easier.

3. It is possible that poor access times are a result of the way trusts work. The access from the Sales.Europe.Contoso.com domain to resources in Adatum.com must transit up the Contoso.com tree. By configuring a shortcut trust between Adatum.com and Sales.Europe.Contoso.com, you might improve performance.