Deploy and manage domain controllers on-premises
Role Placement and Installation
Deploying on-premises domain controllers starts with analyzing your forest and domain topology. This analysis determines where to place domain controllers so clients in different locations can authenticate quickly. The Active Directory Domain Services (AD DS) role can be installed using Server Manager or PowerShell, giving administrators flexibility based on their automation preferences. Both tools support the full process, including promoting a server to a domain controller and specifying which domain or forest it will join.
DNS Integration and Replication
Every domain controller needs reliable name resolution, and DNS is tightly integrated with Active Directory. By configuring integrated DNS zones, the domain controller stores DNS zone data directly in the directory database. This means zone information replicates automatically alongside other AD DS data, reducing overhead and improving fault tolerance. Replication scopes control how directory changes flow between domain controllers. Administrators must configure these scopes carefully, because they determine which domain controllers receive updates from which others and how quickly changes propagate across a large site topology.
Security and Best Practices
Applying security baselines to domain controllers protects the directory service from attackers who might try to compromise authentication or directory data. These baselines include settings for account policies, audit policies, and restrictions on who can log on to domain controllers directly. Site-aware best practices focus on designing Active Directory sites to match the physical network topology. This involves creating site links, assigning costs to those links, and placing domain controllers close to the users and resources they serve. When a domain controller is placed in the same site as its clients, authentication traffic stays on the local network and does not cross slower wide-area links, which improves performance and availability.
Deploy and manage domain controllers in Azure
Provisioning Domain Controller VMs in Azure
The first step in deploying domain controllers in Azure is to provision virtual machines that will run Active Directory Domain Services. You must choose the right VM size and storage to handle the directory workload, and place each VM in the correct virtual network and subnet so it can communicate with other domain controllers and with on-premises resources. Proper network configuration is critical because domain controllers need to replicate data between each other and answer authentication requests from users and computers both in Azure and on your local network. Without that setup, the domain controllers cannot synchronize directory data or authenticate users effectively.
Configuring High Availability and Replication
High availability ensures that directory services stay online even if a single Azure datacenter has a problem. You achieve this by using availability sets or availability zones to distribute domain controllers across different physical locations within an Azure region. When one location fails, the others keep running and users can still log in. Replication keeps directory data consistent across all domain controllers; you configure this through Active Directory Sites and Services to define links and schedules that control how quickly changes spread. The relationship between these two concepts is important: high availability protects against hardware failures, while replication ensures that whichever domain controller handles a request has the most up-to-date information.
Implementing Security Measures
Securing domain controllers in Azure involves controlling who can access them and what traffic they allow. Role-based access control (RBAC) limits management permissions to specific users or groups, so only authorized administrators can change domain controller settings or deploy new VMs. Network security groups (NSGs) filter inbound and outbound traffic based on rules you define, blocking unauthorized connections while allowing legitimate authentication and replication traffic. Finally, you should set up Azure Backup to protect Active Directory data, creating policies that regularly save directory information so you can restore it if data loss occurs. These three layers work together: RBAC controls who manages the environment, NSGs control what traffic enters or leaves, and backups control whether you can recover from disasters.
Steps for Deployment
Deploying AD DS in Azure follows a specific order. First, you provision the domain controller VMs by selecting the appropriate size, attaching storage, and configuring network settings. Second, you install AD DS on each VM and promote it to a domain controller using either the installation wizard or PowerShell scripts. Third, you configure replication by setting up proper replication links and schedules so all domain controllers stay synchronized. Fourth, you apply security controls by implementing RBAC, configuring NSGs, and setting up Azure Backup for recovery. This sequence matters because each step builds on the previous one: you cannot configure replication until domain controllers exist, and you cannot secure what has not been deployed.
Deploy read-only domain controllers
Evaluate Forest and Domain Prerequisites
Before deploying a Read-Only Domain Controller (RODC) , you must verify that the existing Active Directory environment meets key requirements. The forest functional level must be Windows Server 2003 or higher, and the domain functional level must support RODC functionality. A writeable domain controller running Windows Server 2016 or later must be available to replicate data to the RODC. Active Directory data flows in a one‑way direction from this writeable domain controller to the RODC, establishing a clear security boundary.
Configure Read-Only Domain Controllers
To protect the environment, administrators configure several specialized policies on the RODC to limit data exposure. A password replication policy determines which user and computer credentials can be cached locally on the RODC. By default, the RODC does not store passwords, so authentication requests must travel back to a writeable domain controller unless the account is explicitly permitted by this policy. Administrators can also configure a filtered attribute set to prevent sensitive database fields from replicating to the RODC, ensuring that even if the physical server is compromised, high‑value data remains safe. To manage the physical server locally, a delegated administrative model allows local IT staff to log in and perform maintenance tasks without granting them administrative permissions over the wider domain.
Ensure Security in Untrusted Locations
Deploying domain controllers in branch offices or remote physical sites introduces significant security risks due to the lack of physical control. To mitigate these risks, the RODC acts as a hardened outpost by strictly controlling what data crosses the network boundary into the untrusted site. Administrators use the password replication policy to cache credentials only for the specific users who physically work at that location. This approach ensures that a compromised RODC in a remote office does not expose the passwords of corporate executives or domain administrators. By combining restricted replication scopes with delegated administrative permissions, organizations can safely extend identity services to remote locations while protecting the core hybrid identity infrastructure.
Manage and troubleshoot flexible single master operation roles
FSMO Role Functions
Flexible Single Master Operation (FSMO) roles are specialized tasks that only one domain controller in Active Directory can perform at a time. There are five FSMO roles, and each controls a specific function. The Schema Master manages all changes to the Active Directory schema, which defines the types of objects and their attributes. The Domain Naming Master handles adding or removing domains from the forest. The RID Master allocates pools of relative identifiers (RIDs) to each domain controller so they can create new security principals. The PDC Emulator acts as the authoritative time source for the domain and processes password changes and account lockouts first. The Infrastructure Master updates cross-domain object references, such as when a user in one domain is added to a group in another domain. In a hybrid topology that spans on-premises and cloud environments, placing these roles on the right domain controllers is critical for performance and reliability.
StudyCerts
StudyCerts