Attempting to join a Windows desktop to a Active Directory Domain Services (AD DS) fails with: “The following error occurred attempting to join the domain contoso.local”: The specified network name is no longer available.

One of the projects I’ve been working on was a small Azure Virtual Desktop deployment for resources outside of Canada to securely access a VDI in Azure’s Canada Central region. To provide a “block all traffic and only allow whitelisted domain” solution, I opted to use the new Azure Firewall Basic SKU with Application Rules. Given there wasn’t any ingress traffic originating from the internet for published applications and connectivity to the AVDs were going to be through Microsoft’s managed gateway, I decided to place the Azure Firewall in the same VNet as the virtual desktops and servers. This doesn’t conform to the usual hub and spoke topology and the main reason for this is to avoid VNet to VNet peering costs between the subnets. What I have elected for the security network design was to send all traffic between the subnets within the same VNet through the firewall for visibility and logging so the default of traffic free flowing within the same VNet is not allowed. The following is a diagram of the topology:

The traffic originating from the AVD subnet containing the virtual desktops to the server subnet containing the AD DS servers are protected by the firewall. After placing the required route in the UDR associated to the AVD subnet and configuring the required firewall ports from client to server in the Network rules of the firewall policy:

• UDP Port 88 for Kerberos authentication.
• UDP and TCP Port 135 for the client to domain controller operations and domain controllers to domain controller operations.
• TCP Port 139 and UDP 138 are used for File Replication Service between domain controllers.
• UDP Port 389 for LDAP to handle regular queries from client computers to domain controllers.
• TCP and UDP Port 445 for File Replication Service.
• TCP and UDP Port 464 for Kerberos Password Change.
• TCP Port 3268 and 3269 for Global Catalog from client to domain controller.
• TCP and UDP Port 53 for DNS from domain controller to domain controller and client to the domain controller.

… then proceeding to deploy the desktops with AVD, it would fail to join the desktop to the domain with the error message:

VM has reported a failure when processing extension ‘joindomain’. Error message: “Exception(s) occurred while joining Domain contoso.local

Trying to manually join the desktops to the domain will display the following message:

“The following error occurred attempting to join the domain contoso.local”: The specified network name is no longer available.

Parsing through the logs of the Azure Firewall did not reveal any Deny activity but I did notice that there wasn’t any return traffic captured. It was then that I found I had forgotten to associate the UDR that would force traffic from the server subnet to the VDI subnet through the firewall.

This meant that any traffic originating from the VDI subnet would be sent through the firewall:

… while any traffic originating from the server subnet to the VDI subnet would just be sent through subnet to subnet within the same VNet. I’m not completely sure why this would be a problem given return traffic should have returned through the firewall and only new traffic from the domain controllers would not.

In any case, I went ahead and updated the server subnet to use the UDR that would route the traffic through the firewall and the domain join operation succeeded. Firewall logs would also began displaying the domain communication traffic to the AVD subnet.

This probably would have been resolved when I completed the configuration but I hope this blog post would help anyone who may encounter a similar issue.