Deploying and Managing Active Directory DS Domain Controllers
Windows Active Directory Domain Services (AD DS) is a leading identity management solution for organizations of all sizes. At the core of Windows AD DS is the domain controller. The domain controller provides login services, group policies, domain naming services (DNS), and other identity management services for users and computers in a domain along with other enterprise management services.
In this course, we start by reviewing the Windows AD DS environment including forests and domains. Then we review considerations for deploying domain controllers in a virtualized environment, on-premises, and in Azure. Next, we look at use cases for deploying read-only domain controllers at locations where physical security cannot be guaranteed. Lastly, we examine flexible single master operations roles and how to locate and move them to support troubleshooting efforts.
- Deploy and manage domain controllers on-premises
- Deploy and manage domain controllers in Azure
- Deploy read-only domain controllers (RODCs)
- View, manage, and troubleshoot flexible single master operations (FSMO) roles
- System administrators with responsibilities for managing hybrid identities
- Subject matter experts in configuring and managing Active Directory workload on-premises and in Azure
- Anyone preparing for the Azure AZ-800 Administering Windows Server Hybrid Core Infrastructure exam
- A basic understanding of deploying and managing Microsoft Windows servers
- Windows Server installation media and an environment to run Windows Server (trial available at https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-2022)
Welcome to the section where we'll learn about the logical organization of Windows Active Directory Domain Services or Windows AD as I'll refer to it for the rest of this course. Windows AD was designed to provide an enterprise identity solution for organizations of all sizes. Taking time at the beginning to understand the components that make up Windows AD allows us to create a deployment that fits an organization's needs today and scales with it into the future.
Let's start with Windows AD Domain. A domain is a hierarchical structure that stores information about objects on the network such as user accounts, devices like computers and servers, group membership, and other security resources. A Windows Domain also secures the environment by providing secure authentication at login and provides access control for devices on the network such as printers, file shares, and email. These objects are stored in a data store called the directory.
At the top of the directory is a namespace or AD domain name, contoso.com for this example. The domain name gives us a top level name for accessing resources in the directory. When a data store is created, it's important to identify the type of data that it can store. These are referred to as classes of objects. In Windows AD, a schema defines the classes of objects and attributes stored in the directory. Schemes are versioned and can be extended. For example, if we add on-premises exchange email to our domain, the scheme is extended to store email attributes. Let's talk about a Windows AD Forest next. A Forest is a collection of one or more domains. The first domain created in a forest is called the forest root or a parent domain. Domains in a forest act as partitions in the directory.
For example, we may have a contoso.com forest root as well as a dev.contosso.com and production or prod.contoso.com domain. All three domains are in their own partition of the directory in one forest. All domains in a forest are linked with a two-way transitive trust relationship. Transitive means if dev.contoso.com and prod.contoso.com trust contoso.com, dev.contoso.com and prod.contoso.com also trust each other. There's a global catalog that contains information about objects in the directory. The global catalog allows searching the entire directory for an object despite what directory partition we may be searching from.
All domains in a forest share a domain schema, site and replication information, and global catalog. Windows AD can manage the identity needs of a small single domain organization or a global multi-domain forest. Understanding the logical structure of the forest will help when planning a directory structure. Some organizations may require multiple forests. This could be due to mergers and acquisitions that combine multiple independent organizations or a design that separates different business units into their own forest. In these instances, we can create a trust relationship between two or more forests. The trust relationship establishes connectivity between the forests to share security information between them.
With trust relationships, a user in the contoso.com forest can access resources in the woodgrove.com forest without having to log into a second domain. There can be a one-way transitive trust relationship where one domain, the trusting domain contoso.com in this example trust the second trusted domain woodgrove.com. Because contoso.com trust woodgrove.com, Wood Grove users can access resources in the Contoso domain, but this is a one-way trust. Users in the contoso.com domain cannot access resources in woodgrove.com. We can also enable a two-way transitive trust. In this case, the trust and access works in both directions.
With a forest trust, the trust relationship is established at the forest root and is transitive, meaning that the trust relationship extends to all domains in the forest. A domain stores objects such as users, groups and computers. Those objects are organized with an Organization Unit or OU. An OU is a container for objects in a Windows AD domain. OUs can be nested creating a hierarchy of containers in a domain. An OU can also be an administrative boundary providing granular control over management of AD objects.
The last item in this section is Domain Naming Services or DNS. DNS allows us to look up host IP addresses based on the name of the host. You may have noticed that the domain names used in the examples look like the domain names used for accessing resources on the Internet. That is no coincidence, Windows AD uses the same DNS service used by online services to locate resources in Windows AD. There's even an option to integrate DNS into Active Directory domain services. With this option, domain names are located in the same AD data store and replicated with that data store across the domain. Windows AD DNS also supports secure dynamic updates, allowing domain-joined computers to update DNS with their IP address automatically. Thank you for joining me in this brief overview of domains forest, and core services to Windows AD.
Travis Roberts is a Cloud Infrastructure Architect at a Minneapolis consulting firm, a Microsoft MVP, MCT, and author. Travis has 20 years of IT experience in the legal, pharmaceutical, and marketing industries and has worked with IT hardware manufacturers and managed service providers. In addition, Travis has held numerous technical certifications throughout his career from Microsoft, VMware, Citrix, and Cisco.