Configure and manage forest and domain trusts
Select, Establish, and Validate Trust Relationships
A trust relationship connects two domains or forests so that users in one can be authenticated and access resources in the other. The direction of the trust controls who can access what. A two-way trust allows users in both connected domains to access each other’s resources. A one-way trust is directional: a one-way outgoing trust lets users in your local on-premises domain access resources in the remote domain, while a one-way incoming trust lets remote users access local resources. Choosing the correct direction is the first step in securing cross-domain authentication.
To establish a trust, the domains must first be able to find each other by configuring DNS. This often means setting up Conditional Forwarders so that each domain’s DNS servers know how to resolve the other domain’s namespace. Once DNS is ready, you can create the trust using the Active Directory Domains and Trusts console on an on-premises domain controller or the Microsoft Entra admin center in Azure. PowerShell commands and Azure AD Connect also help establish and manage trusts in a hybrid environment, linking your on-premises Active Directory with Azure Active Directory.
After a trust is created, you must validate that it works correctly. The Active Directory Domains and Trusts console lets you check the trust’s status in the domain properties. For command-line validation, the nltest tool is useful. Running nltest /trusted_domains from a domain controller lists all trusted domains and shows whether the trust is active. Regularly checking event logs and using diagnostic tools helps ensure the trust remains healthy and secure, confirming that authentication paths function as intended for reliable resource access.
Optimize AD DS Site Topology and Replication
Active Directory Domain Services (AD DS) depends on a well-designed site topology to work properly. When the topology is configured incorrectly, problems occur: volumes may fail to create, authentication becomes slow, and users might be blocked from accessing resources they need. The site topology defines how domain controllers (DCs) are placed, how IP subnets connect to sites, and how replication flows between locations.
A solid AD DS site topology starts with planning where domain controllers sit in your network. You map IP subnets to site objects so that traffic stays efficient and does not cross unnecessary network boundaries. The goal is to place DCs where they can respond quickly to authentication requests, LDAP queries, and Kerberos ticket operations. DNS infrastructure must support these DCs because every authentication request first queries DNS to find an available domain controller.
Reliable connectivity between Azure NetApp Files, domain controllers, and storage clients is essential. Assign multiple DCs to each AD DS site so that if one fails, others can take over. Subnets within a site should have less than 10 milliseconds of latency between them. Avoid blocking communication between Azure NetApp Files and DCs with user-defined routes or firewall rules, because blocked ports break the connection that allows authentication and file access to work.
Azure NetApp Files depends on DNS to find domain controllers. Every four hours, it queries DNS SRV records to verify which DCs are available. If DNS records are stale or missing, the service cannot locate controllers and authentication fails. You must keep DNS records updated by removing entries for decommissioned DCs and adding records for new ones. For reverse lookups, which support LDAP and Kerberos functions, create a reverse lookup zone so that PTR records can be resolved properly.
Two main tools help manage AD DS site topology. Active Directory Sites and Services lets you map IP subnets to sites and configure site link costs and replication schedules to control how traffic flows between locations. Azure AD Connect Health monitors replication health and DC performance, sending alerts when problems arise. Using both tools together ensures consistent authentication performance and helps catch replication issues before they affect users.
Manage Intersite Replication Topology and Scheduling
Intersite Replication ensures that Active Directory Domain Services (AD DS) maintains consistent directory data across multiple locations. In a hybrid environment, this replication connects on-premises networks and Azure-hosted virtual machines. Efficient replication management helps distribute directory changes in a timely manner while preventing unnecessary network congestion. Administrators must carefully design this topology to balance data consistency with network performance.
To begin configuring replication, administrators first define the physical locations as sites within the directory. These sites are connected by site links, which represent the logical network paths that replication traffic travels between different locations. To allow replication to flow across multiple hops, you can configure site link bridges to connect individual site links together. Additionally, setting appropriate replication intervals allows administrators to control how frequently domain controllers check for updates.
Optimizing directory replication requires matching the replication traffic to the available network bandwidth and performance. Administrators configure the site link cost to assign a relative value to each network path, prompting AD DS to favor cheaper, high-speed connections over slower ones. If network performance is poor, adjusting the replication intervals helps prevent replication traffic from overwhelming the network during peak hours. In complex networks, implementing link bridges further improves overall routing by allowing replication to bypass failed connection paths.
Maintaining a healthy directory environment requires continuous monitoring and swift remediation of replication failures. Administrators use the repadmin command-line tool and inspect AD DS event logs to verify that domain controllers are communicating correctly. This monitoring helps detect high latency before it causes major data discrepancies between sites. It also allows administrators to quickly address serious issues like a USN rollback, which halts replication due to database sequence mismatches, or lingering objects that remain on isolated domain controllers after being deleted elsewhere.
Setting up a robust hybrid replication structure involves a series of foundational steps: configure DNS by adding forwarders to resolve managed domain names across on-premises and cloud environments; configure trust relationships between different domains to enable seamless resource access across security boundaries; and design the AD DS site topology by planning domain controller placement and ensuring reliable connectivity, aiming to keep latency below a 10ms round-trip time (RTT).