 Hello, Windows Server hybrid administrators. Welcome to this Microsoft Learn Training Module, Manage Advanced Features of Active Directory Domain Services. This module provides an introduction to how to manage Active Directory Trust relationships, ADDS replication, selective authentication, and custom ADDS partitions. In addition to learning about these technical topics, this module is part of a playlist that also functions as preparation for objective domain one, deploy and manage ADDS in on-premises and cloud environments of the first Windows Server Hybrid Administrator Associate Exam AZ 800. Other modules in the playlist on this channel deal with other Windows Server and hybrid IT pro topics. This module is adapted from a module that you can take on Microsoft Learn. The module itself provides more detail, references, demos, and knowledge checks to test your understanding. You can follow along with the contents of this module on Microsoft Learn at the address shown on the screen or listed in the video description. The Windows Server Hybrid Administrator Associate Certification is Microsoft's successor to the Windows Server MCSE. Certification has always been important for Windows Server administrators, and the Windows Server Hybrid Administrator Associate brings many of the skills required to obtain the MCSE into the 2020s. To earn the new certification, you need to pass two exams, AZ 800 and AZ 801. Being successful on the exams requires that you not only understand how to do common administrative tasks such as manage active directory storage, networking, security disaster recovery, monitoring, and virtualization on-premises. Just like you would have had to for the last few years of Windows Server, but also know how you can integrate and extend Windows Server with relevant services available in Azure. After completing this module, you'll be able to identify the purpose, types, and the process of creating trust relationships. Describe the purpose and the process of implementing ESAE forests. Monitor and troubleshoot ADDS replication using RepAdmin and DCDiag, and identify the purpose and the process of creating custom ADDS partitions. An ADDS forest represents a security boundary, providing secure authentication and authorization for its users, computers, and applications. Sometimes it might be necessary to extend this boundary to include other ADDS domains and forests. This, for example, might result from mergers and acquisitions between organizations or from consolidation initiatives. ADDS trusts enable access to resources in a multiple domain and multiple forest ADDS environment. In a single domain forest, all users and resources such as file shares, printers, or applications share the same domain, so access management is straightforward and readily available. When you have multiple domains or forests, you need trust to provide users in one domain with secure access to resources in another domain. In a multiple domain ADDS forest, by default, domains form a tree-like structure with a two-way transitive trust relationship between directly adjacent domains. Trust transitivity implies that a path of trust exists between all the ADDS domains in the same forest. Additionally, you can create other types of trusts. Active Directory supports the following trust types. External trust, a non-transitive one-way or two-way trust relationship, enables resource access with an individual ADDS domain in another forest. Realm trust can be transitive or non-transitive one-way or two-way trust, allows you to establish an authentication path between a Windows Server ADDS domain and a Kerberos version 5 protocol realm that implements by using a Directory service other than ADDS. Forest trust, a transitive one-way or two-way trust. Allow two forests to share resources. Shortcut trust, a non-transitive one-way or two-way trust. Use this to reduce the time taken to authenticate between two not directly adjacent domains in the same multiple domain ADDS forest. Forest trust relationships provide most flexibility from the authentication standpoint. They are also easier to establish, maintain, and administer than separate trust relationships between external domain level trusts and individual domains across the two forests. If the ADDS environment contains multiple forests, it is possible to set up one-way or two-way trust relationships between any pair of forests. With a one-way forest trust, you can grant users in the trusted forest access to resources in the trusting forest. With a two-way forest trust, it becomes possible to grant users on each side of the trust access to resources in the other forest. When creating a trust, you specify the root domain of each forest. However, because forest trusts are transitive for all domains in each forest, you effectively establish a trust between each pair of domains across both forests. However, unlike trust between multiple domains in the same forest, forest trusts are not transitive across multiple forests. Forest trusts can only be created between two forests and can't be implicitly extended to a third forest. This means that if you create a forest trust between forest one and forest two, and you create a forest trust between forest two and forest three, forest one doesn't implicitly trust forest three. Forest trusts are particularly useful in scenarios that involve cross-organization collaboration, mergers and acquisitions, or within a single organization that has more than one forest in which to isolate active directory data and services. Forest trusts are also useful for application service providers for collaborative business extra nets and for organizations that want a solution for administrative autonomy. Before you can implement a forest trust, you need to ensure that DNS name resolution exists between the forests. To implement such name resolution, you can use several different DNS resolution techniques, such as secondary zones, stub zones, or conditional forwarding. By default, when you establish a forest or domain trust, you can enable a domain quarantine, also known as SCID filtering. When a user authenticates in a trusted domain, the user presents an authorization request that includes the SID attributes of all groups to which the user belongs. Additionally, the user's authorization request includes the SID history attribute of the user and the user's groups, SID. Filtering blocks the use of SIDs present in SID history that don't originate from the trusted domain. This prevents a potential exploit that involves tempering with the SID history attribute to gain unauthorized access to resources in the trusted domain. When you create a forest trust, you can manage the scope of authentication of trusted security principles. There are two modes of authentication for an external or forest trust, forest-wide authentication and selective authentication. Choosing the forest-wide authentication enables all users in the trusted forest to authenticate for services and access on all computers in the trusting forest. Therefore, it is possible for resource administrators in the trusting forest to grant users from the trusted forest permissions to resources in the local forest. Additionally, all users from a trusted forest are considered authenticated users in the trusting forest. Effectively, any resource that grants permissions to authenticated users becomes accessible by users in the trusted forest. If you choose selective authentication, users in the trusted forest are not considered authenticated users in the trusting forest. Instead, you have to explicitly designate computers that they will be able to authenticate to by granting them the allowed to authenticate permission on those computers. For example, imagine that you have a forest trust with a partner organization's forest. You want to ensure that only users from the partner organization's marketing group can access shared folders on a specific file server. To do so, you can configure selective authentication for the trust relationship and then grant the trusted users the right to authenticate only to that one file server. When using selective authentication, in addition to the right to authenticate, users from the trusted forest still need file system and folder level permissions on the shared folders to access their content. As IT environments expand beyond the boundaries of internal networks, the role of identity as a security perimeter becomes increasingly important. One way to enhance its security capabilities is to implement the Enhanced Security Administrative Environment, ESAE forest model. ESAE forest represent an architectural approach in which a dedicated administrative active directory forest hosts privileged accounts, privileged groups, and privileged access workstations. This ESAE forest is configured with a one-way trust relationship with a production forest. A one-way trust relationship means that accounts from the ESAE forest can be used in the production forest. However, accounts in the production forest can't be used in the ESAE forest. A production forest is a forest in which administrators perform an organization's day-to-day activities. The production forest is then configured so that administrative tasks in the production forest can be performed only by using accounts that the ESAE forest hosts. ESAE forest have the following benefits. Lockdown accounts, standard non-privileged user accounts in the ESAE forest can be configured as highly privileged in the production forest. For example, a standard user account in the ESAE forest is a member of the Domain Admins Group in a domain in the production forest. It is possible to lock down the standard user account hosted in the ESAE forest so that it can't sign into hosts in the ESAE forest and can only be used to sign into hosts in the production forest. This design is more secure if an account is compromised while it is used in the production forest because the malicious hacker can't use that account to perform administrative tasks in the ESAE forest. Selective authentication, ESAE. Forest design allows organizations to leverage the trust relationships selective authentication feature. For example, sign-ins from the ESAE forest will be restricted to specific hosts in the production forest. This is another method that helps limit credential exposure. For example, you can limit credential exposure when you configure selective authentication so that privileged accounts in the production forest can only be used on privileged access workstations or jump servers. Simple way to improve security, ESAE forest design provides substantive improvement in the security of existing production forests without requiring complete rebuilding of the production environment. The ESAE forest approach has a small software footprint and affects only IT operations team users. In this design, standard user accounts remain hosted in the production forest. Only privileged administrative accounts are hosted in the ESAE forest. Because they're hosted in a separate forest, privileged administrative accounts can be subject to more stringent security requirements than standard user accounts in the production forest. Microsoft's recommendation to use this architectural pattern has been replaced by the modern privileged access strategy and rapid modernization plan, RAMP, guidance as the default recommended approach for securing privileged users. Both these strategies employ Azure AD and may not be suitable for organizations that are not adopting a hybrid posture. While not a mainstream recommendation, the ESAE architectural pattern is valid in a limited set of scenarios. In these exception cases, the organization must accept the increased technical complexity and operational costs of the solution. The organization must have a sophisticated security program to measure risk, monitor risk, and apply consistent operational rigor to the usage and maintenance of the ESAE implementation. Example scenarios include isolated on-premises environments where cloud services are unavailable, such as offline research laboratories, critical infrastructure or utilities, disconnected operational technology environments such as supervisory control and data acquisition, escada, industrial control systems, and public sector customers that are fully reliant on on-premises technology. Highly regulated environments, industry, or government regulation may specifically require an administrative forest configuration. High-level security assurance is mandated. Organizations with low risk tolerance that are willing to accept the increased complexity and operational cost of the solution. While Microsoft no longer recommends an isolated hardened forest model for most scenarios at most organizations, Microsoft still operates a similar architecture internally and associated support processes and personnel because of the extreme security requirements for providing trusted cloud services to organizations around the globe. Make of that what you will. The Clean Source Principle specifies that all security dependencies are as trustworthy as the item being secured. In the context of ESAE forests, the Clean Source Principle involves ensuring that all of the security accounts and workstations that are used are trustworthy. The Clean Source Principle is an important aspect of security because if a malicious hacker can control a security dependency, the hacker also can control the item being secured. One reason for using the ESAE forest design approach is that it helps secure the privileged accounts that manage the production environment. When securing the ESAE forest, ensure that ESAE domain controllers are running on a secure virtualization fabric and that security technologies such as device guard, credential guard and bitlocker are in use. The Clean Source Principle also applies to installation media. If installation media is infected, then all software and operating systems that are deployed from that installation media are untrustworthy and at risk for control by the hacker. Software obtained from vendors through physical media needs to be validated. Software downloaded from the internet should be checked against vendor provided file hashes to ensure that it hasn't been tampered with by unauthorized third parties. You should consider several factors when implementing an ESAE forest. An ESAE forest should have the following properties. Limit the function of the ESAE forest to hosting accounts of administrative users for the production forest. To keep the hacker surface minimized, don't deploy applications or additional resources in the ESAE forest. The ESAE forest should be a single domain active directory forest. There's no need for multiple domains in an ESAE forest. The ESAE forest hosts only a few accounts to which strict security policies must be applied. Only use one-way trusts. You should only configure a one-way trust where the production forest trusts the ESAE forest. This means that accounts from the ESAE forest can be used in the production forest. However, accounts from the production forest can't be used in the ESAE forest. Accounts used for administrative tasks in the production forest should be standard user accounts in the ESAE forest. If an account is compromised in the production forest, it can't be used to elevate privileges in the ESAE forest. The ESAE forest servers need to be configured in the following ways. Installation media should be validated. Servers should run the most recent version of the Windows server operating system. Servers should be updated automatically with security updates. Security compliance manager baselines should be used as the starting point for server configuration. Servers should be configured with secure boot, bitlocker volume encryption, credential guard, and device guard. Servers should be configured to block USB storage, and servers should be on isolated networks, ensure inbound and outbound internet connections are blocked. Performance and operational issues are common in real-world environments. To analyze, evaluate, and remediate such issues affecting ADDS domain controller is a fundamental skill of any IT professional responsible for ensuring stability and availability of an ADDS environment. Insufficient system resources can lead to poor domain controller system performance. The four key system resources are the central processing unit, CPU, disk subsystem, memory, and network. Identifying and remediating bottlenecks involves close examination of system logs and performance counters to determine which resource is currently constrained. After augmenting that resource, performance will improve, but it might reach a plateau if it hits a new bottleneck in another system resource. You can use several tools in Windows Server for various types of monitoring. Most of these tools are available by default as Windows Server components, and you can use them for real-time and historical monitoring of ADDS and other services. The most commonly used tools are task manager, resource monitor, event viewer, and performance monitor. With performance monitor, you can review current performance statistics or historical data gathered by using data collector sets. There are many counters that you can review and analyze to address your specific requirements, including processor, memory, disk, and network-specific counters. On a domain controller, you also should monitor NT directory service, NTDS, object counters, other counters to consider security system-wide statistics, Kerberos authentications per sec. This countertracks the number of Kerberos authentications per second, security system-wide statistics, NTLM authentications. This countertracks the number of Windows network LAN manager, NTLM authentications processed per second. If you use System Center Operations Manager in your environment, you also have the option to deploy the Active Directory Domain Services Management Pack for Operations Manager to monitor and analyze operations of your domain controllers. This management pack contains many alerts, views, tasks, and reports for a variety of ADDS functions. In any ADDS domain environment containing multiple domain controllers, it is essential to monitor ADDS replication. And in case of any issues, troubleshoot and resolve them, performance monitor allows you to capture and analyze directory replication agent, DRA counters, including a NTDS DRA inbound bytes total per sec. This counter depicts the total number of bytes replicated into the ADDS database, NTDS DRA inbound object. This counter depicts the number of Active Directory objects received from neighbors through inbound replication, NTDS DRA outbound bytes. Total per sec, this counter depicts the total number of bytes replicated out, NTDS DRA pending replication, synchronizations. This is the number of directory synchronizations that are in this server's queue waiting for processing. Two additional tools are particularly useful for reporting and analyzing replication. The replication diagnostics tool, Repadmin.exe, and the domain controller diagnostics tool, dcdag.exe. You'll learn about these tools next. Repadmin.exe is a command line tool that enables you to report the status of replication on each domain controller. The information that Repadmin.exe produces can help you spot a potential replication problem in the forest. You can review levels of detail down to the replication metadata for specific objects and attributes, enabling you to identify where and when a problematic change was made to ADDS. You can even use Repadmin.exe to manage the replication topology and force replication between domain controllers. Repadmin.exe supports several commands that perform specific tasks. You can learn about each command by running Repadmin slash question mark from the command prompt or PowerShell. Most commands take a dc underscore list parameter, which is simply a network label, DNS, net bios name, or IP address of a domain controller. Some of the replication monitoring tasks that you can perform by using Repadmin.exe include displaying the replication partners for a domain controller. To display the replication connections of a domain controller, enter Repadmin slash show REPL dc underscore list. By default, Repadmin lists intersite connections only. Add the slash Repsto argument also to list intersite connections. To display connection objects for a domain controller, enter Repadmin slash chocon dc underscore list. You can learn much about replication by examining an object on two different domain controllers to find out which attributes have or haven't replicated. Enter Repadmin slash show abgmeta dc underscore list object, where dc underscore list indicates the domain controller or controllers to query. You can use an asterisk to indicate all domain controllers. The object represents the grid D of an object, which is its unique identifier. DCDI Ag performs several tests and reports on the overall health of replication and operational status for ADDS. Run by itself, DCDI Ag performs summary tests and then reports the results. At the other extreme, DCDI Ag slash C runs a comprehensive list of tests. You can redirect the output to files of various types, including XML. You also can specify one or more tests to perform by using the slash test, test name parameter. Tests that relate directly to replication include DFS Revent reports any operation errors in the distributed file system, DFS. Intocite checks for failures that would prevent or delay intracite replication. KCC event identifies errors in the knowledge consistency checker, replications. Checks for timely replication between domain controllers. Topology checks that the replication topology is connected fully for all domain controllers. Verify replicas verifies that all application directory partitions are instantiated fully on all domain controllers that host replicas. Active Directory Domain Services Management Pack for Operations Manager includes replication monitoring functionality that collects ADDS replication alerts, along with performance data representing replication latency and the volume of both inbound and outbound replication traffic. The management pack offers replication topology dashboards that display site links, connection objects, and broken connection objects. It also allows you to generate reports on replication connection objects, replication site links, replication bandwidth, and replication latency. Windows Server supports Windows PowerShell commandlets that facilitate monitoring ADDS replication and reviewing its configuration. The following list describes some of them. GetAD replication connection provides a specific ADDS replication connection or a set of ADDS replication connection objects based on a specified filter. GetAD replication failure provides a description of an ADDS replication failure. GetAD replication partner metadata provides replication metadata for a set of one or more replication partners. GetAD replication site provides a specific ADDS replication site or a set of replication site objects based on a specified filter. GetAD replication site link provides a specific Active Directory site link or a set of sight links based on a specified filter. GetAddReplicationSightLinkBridge provides a specific active directory sight link bridge or a set of sight link bridge objects based on a specified filter. GetAddReplicationSubnet provides an active directory subnet or a set of active directory subnets based on a specified filter. A partition or naming context is a portion of the ADDS database. Although the database is one file named ntds.dit, different partitions contain different data. Each partition is a unit of replication. And each partition has its own replication topology. The default partitions include configuration partition. The configuration partition is created automatically when you create the first domain controller in a forest. The configuration partition contains information about the forest-wide ADDS structure, including which domains and sites exist and which domain controllers exist in each domain. This partition replicates to all domain controllers in the forest, schema partition. The schema partition contains definitions of all the objects and attributes that you can create in the data store and the rules for creating and manipulating them. Schema information replicates to all domain controllers in the forest. Domain partition, when you create a new domain, ADDS automatically creates an instance of the domain partition. That partition is subsequently automatically replicated to every new domain controller in the same domain. The domain partition contains information about all domain-specific objects, including users, groups, computers, organizational units, OUS, and domain-related system settings, application partition. The application partition stores non-domain application related information that tends to be updated at a higher frequency or have a customizable lifetime, such as a DNS partition when active directory-integrated DNS is enabled. You typically have the flexibility to designate the scope of replication of application partitions by designating which domain controllers in a forest will host its copies. By default, when you configure a domain controller to host active directory-integrated DNS zones, two separate application partitions, domain DNS zones, and forest DNS zones are created. The domain DNS zones partition contains domain-specific DNS records, and its replication scope consists of other ADDS domain controllers that host the DNS server role. Earlier on in the Windows server lifecycle, custom applications might store their data in the ADDS database. Some of them rely on schema extensions for this purpose. However, there are also others which require creating custom ADDS partitions. This approach is less common today, and application data is often stored somewhere more exciting like an SQL database or if we're being honest in a flat CSV file on some random file server. You can create and manage ADDS partitions by using the ntdsutil.exe command line tool. ntdsutil.exe also allows you to perform several other ADDS related management tasks, such as ntds database maintenance, including creating snapshots, relocating database, files, and offline defragmentation, cleaning up domain controller metadata following its unrecoverable failure, resetting the password used to sign into the directory services restore mode. In this module, we covered the following topics. Identify the purpose, types, and the process of creating trust relationships. Describe the purpose and the process of implementing ESA forests. Monitor and troubleshoot ADDS replication using Repadmin and DCDAG, and identify the purpose and the process of creating custom ADDS partitions. If you want to learn more, you can take this module on Microsoft Learn or read the official AZ800 exam prep guide from Microsoft Press. Links available at aka.ms.az-800 study guide. We publish new content regularly on this channel on topics related to Windows Server, Hybrid Cloud, and Azure Infrastructure, and the certifications related to these topics. Look forward to seeing you in future videos.