Understand guidelines for Active Directory Domain Services site design and planning for Azure NetApp Files

Proper Active Directory Domain Services (AD DS) design and planning are key to solution architectures that use Azure NetApp Files volumes. Azure NetApp Files features such as SMB volumes, dual-protocol volumes, and NFSv4.1 Kerberos volumes are designed to be used with AD DS.

This article provides recommendations to help you develop an AD DS deployment strategy for Azure NetApp Files. Before reading this article, you need to have a good understanding about how AD DS works on a functional level.

Identify AD DS requirements for Azure NetApp Files

Before you deploy Azure NetApp Files volumes, you must identify the AD DS integration requirements for Azure NetApp Files to ensure that Azure NetApp Files is well connected to AD DS. Incorrect or incomplete AD DS integration with Azure NetApp Files might cause client access interruptions or outages for SMB, dual-protocol, or Kerberos NFSv4.1 volumes.

Network requirements

Azure NetApp Files SMB, dual-protocol, and Kerberos NFSv4.1 volumes require reliable and low-latency network connectivity (< 10ms RTT) to AD DS domain controllers. Poor network connectivity or high network latency between Azure NetApp Files and AD DS domain controllers can cause client access interruptions or client timeouts.

Ensure that you meet the following requirements about network topology and configurations:

  • Ensure that a supported network topology for Azure NetApp Files is used.
  • Ensure that AD DS domain controllers have network connectivity from the Azure NetApp Files delegated subnet hosting the Azure NetApp Files volumes.
    • Peered virtual network topologies with AD DS domain controllers must have peering configured correctly to support Azure NetApp Files to AD DS domain controller network connectivity.
  • Network Security Groups (NSGs) and AD DS domain controller firewalls must have appropriately configured rules to support Azure NetApp Files connectivity to AD DS and DNS.
  • Ensure that the latency is less than 10ms RTT between Azure NetApp Files and AD DS domain controllers.

The required network ports are as follows:

Service Port Protocol
AD Web Services 9839 TCP
DNS* 53 TCP
DNS* 53 UDP
ICMPv4 N/A Echo Reply
Kerberos 464 TCP
Kerberos 464 UDP
Kerberos 88 TCP
Kerberos 88 UDP
LDAP 389 TCP
LDAP 389 UDP
LDAP 3268 TCP
NetBIOS name 138 UDP
SAM/LSA 445 TCP
SAM/LSA 445 UDP
w32time 123 UDP

*DNS running on AD DS domain controller

DNS requirements

Azure NetApp Files SMB, dual-protocol, and Kerberos NFSv4.1 volumes require reliable access to Domain Name System (DNS) services and up-to-date DNS records. Poor network connectivity between Azure NetApp Files and DNS servers can cause client access interruptions or client timeouts. Incomplete or incorrect DNS records for AD DS or Azure NetApp Files can cause client access interruptions or client timeouts.

Azure NetApp Files supports the use of Active Directory integrated DNS or standalone DNS servers.

Ensure that you meet the following requirements about the DNS configurations:

  • If you're using standalone DNS servers:
    • Ensure that DNS servers have network connectivity to the Azure NetApp Files delegated subnet hosting the Azure NetApp Files volumes.
    • Ensure that network ports UDP 53 and TCP 53 are not blocked by firewalls or NSGs.
  • Ensure that the SRV records registered by the AD DS Net Logon service have been created on the DNS servers.
  • Ensure that the PTR records for the SRV records registered by the AD DS Net Logon service have been created on the DNS servers.
  • Azure NetApp Files supports standard and secure dynamic DNS updates. If you require secure dynamic DNS updates, ensure that secure updates are configured on the DNS servers.
  • If dynamic DNS updates are not used, you need to manually create A record and PTR records for Azure NetApp Files SMB volumes.
  • For complex or large AD DS topologies, DNS Policies or DNS subnet prioritization may be required to support LDAP enabled NFS volumes.

Time source requirements

Azure NetApp Files uses time.windows.com as the time source. Ensure that the domain controllers used by Azure NetApp Files are configured to use time.windows.com or another accurate, stable root (stratum 1) time source. If there is more than a five-minute skew between Azure NetApp Files and the customer client or AS DS domain controllers, authentication will fail, and access to Azure NetApp Files volumes might also fail.

Decide which AD DS to use with Azure NetApp Files

Azure NetApp Files supports both Active Directory Domain Services (AD DS) and Azure Active Directory Domain Services (AAD DS) for AD connections. Before you create an AD connection, you need to decide whether to use AD DS or AAD DS.

For more information, see Compare self-managed Active Directory Domain Services, Azure Active Directory, and managed Azure Active Directory Domain Services.

Active Directory Domain Services considerations

You should use Active Directory Domain Services (AD DS) in the following scenarios:

  • You have AD DS users hosted in an on-premises AD DS domain that need access to Azure NetApp Files resources.
  • You have applications hosted partially on-premises and partially in Azure that need access to Azure NetApp Files resources.
  • You don’t need AAD DS integration with an Azure AD tenant in your subscription, or AAD DS is incompatible with your technical requirements.

Note

Azure NetApp Files doesn't support the use of AD DS Read-only Domain Controllers (RODC).

If you choose to use AD DS with Azure NetApp Files, follow the guidance in Extend AD DS into Azure Architecture Guide and ensure that you meet the Azure NetApp Files network and DNS requirements for AD DS.

Azure Active Directory Domain Services considerations

Azure Active Directory Domain Services (AAD DS) is a managed AD DS domain that is synchronized with your Azure AD tenant. The main benefits to using Azure AD DS are as follows:

  • AAD DS is a standalone domain. As such, there is no need to set up network connectivity between on-premises and Azure.
  • Provides simplified deployment and management experience.

You should use AAD DS in the following scenarios:

  • There’s no need to extend AD DS from on-premises into Azure to provide access to Azure NetApp Files resources.
  • Your security policies do not allow the extension of on-premises AD DS into Azure.
  • You don’t have strong knowledge of AD DS. AAD DS can improve the likelihood of good outcomes with Azure NetApp Files.

If you choose to use AAD DS with Azure NetApp Files, see Azure AD DS documentation for architecture, deployment, and management guidance. Ensure that you also meet the Azure NetApp Files Network and DNS requirements.

Design AD DS site topology for use with Azure NetApp Files

A proper design for the AD DS site topology is critical for any solution architecture that involves Azure NetApp Files SMB, dual-protocol, or NFSv4.1 Kerberos volumes.

Incorrect AD DS site topology or configuration can result in the following behaviors:

An AD DS site topology for Azure NetApp Files is a logical representation of the Azure NetApp Files network. Designing an AD DS site topology for Azure NetApp Files involves planning for domain controller placement, designing sites, DNS infrastructure, and network subnets to ensure good connectivity among the Azure NetApp Files service, Azure NetApp Files storage clients, and AD DS domain controllers.

How Azure NetApp Files uses AD DS site information

Azure NetApp Files uses the AD Site Name configured in the Active Directory connections to discover which domain controllers are present to support authentication, domain join, LDAP queries, and Kerberos ticket operations.

AD DS domain controller discovery

Azure NetApp Files initiates domain controller discovery every four hours. Azure NetApp Files queries the site-specific service (SRV) resource record to determine which domain controllers are in the AD DS site specified in the AD Site Name field of the Azure NetApp Files AD connection. The associated services hosted on the domain controllers (such as Kerberos, LDAP, Net Logon, and LSA) server discovery checks the status of the services hosted on the domain controllers and selects the optimal domain controller for authentication requests.

Note

If you make changes to the domain controllers in the AD DS site that is used by Azure NetApp Files, wait at least four hours between deploying new AD DS domain controllers and retiring existing AD DS domain controllers. This wait time enables Azure NetApp Files to discover the new AD DS domain controllers.

Ensure that stale DNS records associated with the retired AD DS domain controller are removed from DNS. Doing so ensures that Azure NetApp Files will not attempt to communicate with the retired domain controller.

AD DS LDAP server discovery

A separate discovery process for AD DS LDAP servers occurs when LDAP is enabled for an Azure NetApp Files NFS volume. When the LDAP client is created on Azure NetApp Files, Azure NetApp Files queries the AD DS domain service (SRV) resource record for a list of all AD DS LDAP servers in the domain and not the AD DS LDAP servers assigned to the AD DS site specified in the AD connection.

Important

If Azure NetApp Files cannot reach a discovered AD DS LDAP server during the creation of the Azure NetApp Files LDAP client, the creation of the LDAP enabled volume will fail. In large or complex AD DS topologies, you might need to implement DNS Policies or DNS subnet prioritization to ensure that the AD DS LDAP servers assigned to the AD DS site specified in the AD connection are returned. Contact your Microsoft CSA for guidance on how to best configure your DNS to support LDAP-enabled NFS volumes.

Consequences of incorrect or incomplete AD Site Name configuration

Incorrect or incomplete AD DS site topology or configuration can result in volume creation failures, problems with client queries, authentication failures, and failures to modify Azure NetApp Files AD connections.

The AD Site Name field is required to create an Azure NetApp Files AD connection. The AD DS site defined must exist and be properly configured.

Azure NetApp Files uses the AD DS Site to discover the domain controllers and subnets assigned to the AD DS Site defined in the AD Site Name. All domain controllers assigned to the AD DS Site must have good network connectivity from the Azure virtual network interfaces used by ANF and be reachable. AD DS domain controller VMs assigned to the AD DS Site that are used by Azure NetApp Files must be excluded from cost management policies that shut down VMs.

You must update the AD DS Site configuration whenever new domain controllers are deployed into a subnet assigned to the AD DS site that is used by the Azure NetApp Files AD Connection. Ensure that the DNS SRV records for the site reflect any changes to the domain controllers assigned to the AD DS Site used by Azure NetApp Files.

Note

Azure NetApp Files doesn't support the use of AD DS Read-only Domain Controllers (RODC). To prevent Azure NetApp Files from using an RODC, do not configure the AD Site Name filed of the AD connections with an RODC.

Sample AD DS site topology configuration for Azure NetApp Files

An AD DS site topology is a logical representation of the network where Azure NetApp Files is deployed. In this section, the sample configuration scenario for AD DS site topology intends to show a basic AD DS site design for Azure NetApp Files. It is not the only way to design network or AD site topology for Azure NetApp Files.

Important

For scenarios that involve complex AD DS or complex network topologies, you should have a Microsoft Azure CSA review the Azure NetApp Files networking and AD Site design.

The following diagram shows a sample network topology: sample-network-topology.png Diagram illustrating network topology.

In the sample network topology, an on-premises AD DS domain (anf.local) is extended into an Azure virtual network. The on-premises network is connected to the Azure virtual network using an Azure ExpressRoute circuit.

The Azure virtual network has four subnets: Gateway Subnet, Azure Bastion Subnet, AD DS Subnet, and an Azure NetApp Files Delegated Subnet. Redundant AD DS domain controllers joined to the anf.local domain is deployed into the AD DS subnet. The AD DS subnet is assigned the IP address range 10.0.0.0/24.

Azure NetApp Files can only use one AD DS site to determine which domain controllers will be used for authentication, LDAP queries, and Kerberos. In the sample scenario, two subnet objects are created and assigned to a site called ANF using the Active Directory Sites and Services utility. One subnet object is mapped to the AD DS subnet, 10.0.0.0/24, and the other subnet object is mapped to the ANF delegated subnet, 10.0.2.0/24.

In the Active Directory Sites and Services tool, verify that the AD DS domain controllers deployed into the AD DS subnet are assigned to the ANF site:

Screenshot of the Active Directory Sites and Services window with a red box drawing attention to the ANF > Servers directory.

To create the subnet object that maps to the AD DS subnet in the Azure virtual network, right-click the Subnets container in the Active Directory Sites and Services utility and select New Subnet....   In the New Object - Subnet dialog, the 10.0.0.0/24 IP address range for the AD DS Subnet is entered in the Prefix field. Select ANF as the site object for the subnet. Select OK to create the subnet object and assign it to the ANF site.

Screenshot of the New Object – Subnet menu.

To verify that the new subnet object is assigned to the correct site, right-click the 10.0.0.0/24 subnet object and select Properties. The Site field should show the ANF site object:

Screenshot of the properties menu with a red box surrounding the site field that reads 'ANF'.

To create the subnet object that maps to the Azure NetApp Files delegated subnet in the Azure virtual network, right-click the Subnets container in the Active Directory Sites and Services utility and select New Subnet....

Cross-region replication considerations

Azure NetApp Files cross-region replication enables you to replicate Azure NetApp Files volumes from one region to another region to support business continuance and disaster recovery (BC/DR) requirements.

Azure NetApp Files SMB, dual-protocol, and NFSv4.1 Kerberos volumes support cross-region replication. Replication of these volumes requires the following:

  • A NetApp account created in both the source and destination regions.
  • An Azure NetApp Files Active Directory connection in the NetApp account created in the source and destination regions.
  • AD DS domain controllers are deployed and running in the destination region.
  • Proper Azure NetApp Files network, DNS, and AD DS site design must be deployed in the destination region to enable good network communication of Azure NetApp Files with the AD DS domain controllers in the destination region.
  • The Active Directory connection in the destination region must be configured to use the DNS and AD Site resources in the destination region.

Next steps