I have set up a simple domain in my Azure subscription by creating a domain controller in an Azure VM, with all of the associated DNS setup and following documented best practices. This is a cloud-only domain on a cloud-only vnet; there is no on-premises connectivity. I have provisioned and joined a handful of VMs to the domain. Now, when I provision new VMs, they have trouble joining the domain (often failing to join at all) and DNS lookups from these machines often times out, especially to internet addresses. How can I fix this?
Details
I have set up a domain controller on an Azure VM following the practices and steps in "Install a new Active Directory forest on an Azure virtual network" and "Guidelines for Deploying Windows Server Active Directory on Azure Virtual Machines", with the exception that I did not put the AD database on a separate data disk. In addition, I have added 168.63.129.16 as a second DNS address (the first address is the internal vnet address of the DC, which I have made static using Set-AzureStaticVNetIP) in the Virtual Network settings so that the machines on the domain can reach the internet.
I use the PowerShell cmdlets to provision new machines and have them automatically joined to the domain using the -WindowsDomain switch and associated parameters of Add-AzureProvisioningConfig when creating the VMs. I have provisioned the DC in one cloud service, and all other machines in another cloud service. All are on the same vnet subnet, and all of this is in one affinity group. I have provisioned and joined about 15 machines, about ten of which are still running (others deleted).
Usually provisioning a new VM takes about 11-12 minutes. Now I'm seeing that it takes upwards of 30-35, and upon completion, the machine failed to join the domain. DNS lookups across the board are slow and often time out (especially for internet addresses), and on these new machines that were not able to join the domain, often fail completely. Pinging the DC from these machines fails, while on machines that successfully joined the domain earlier, it succeeds.
I am not sure if the number of machines on the domain/vnet/cloud service/subscription are the cause of this problem, but I didn't see this problem until I had been using the domain for a while and spun up a number of machines.
One of the more common causes could be your AD DNS is returning an IP that cannot be resolved internally to join the domain. When you do an nslookup on yourdomain.local, does it respond with only IPs that can resolve on the internal, private network?
Related
How can we allow application workloads to manage their own DNS entries when their VMs also need to be joined to an AADDS domain (without violating the principal of least privilege)?
Background
We have the following network configuration:
A Hub VNET containing an Azure AD Domain Services (AADDS) managed domain called mydomain.co.uk. This VNET will also host a VNET Gateway, a Bastion instance and a couple of management VMs.
Multiple "environment" VNETs, all peered to the Hub, to run application workloads. These workloads all currently running on on domain-joined VMs & VMSSs that are behind both an Standard Load Balancer (for internal traffic), and an Application Gateway (for public traffic). The IP addresses of those load balancers and App Gateways need to be resolvable via DNS.
Requirements
We would like all applications to be resolvable using the same TLD domain - both internally and externally (e.g. myapp.env1.mydomain.co.uk should work internally and externally).
The Hub is created by a single pipeline running a terraform configuration that is maintained by the Platform team. The platform Team should not need to be involved when provisioning environments.
Each environment is created by its own pipeline, running terraform configurations that are maintained by the various Product Teams. The Product Teams should be able to spin up & destroy environments without any input from the Platform Team.
Problem
Public DNS resolution was easy to setup. We simply granted each environmental pipeline permission to register records in an Azure public DNS zone. The problem arose when we tried to solve internal DNS Resolution.
We tried creating a Private DNS zone for `mydomain.co.uk and linking it to the environmental VNETs. Unfortunately, the VMs in those VNETs then fail to join to the domain due to the lack of domain SRV records (these are created by default in AADDS). So it seems that AADDS requires that any VNETs containing VMs that want to join to the domain use its IP addresses for DNS resolution. This means any apps running on those VMs must send their DNS query to AADDS, not to an Azure Private DNS Zone.
We thought about giving the environment pipelines permission to create records in the AADDS DNS zone. Unfortunately, the Microsoft docs say that only users that are members of the "AAD DC Administrators" group can add/remove DNS records. This is far too much power to give to the environmental pipelines (it would allow them to delete other workloads' VMs from the domain for example).
We then tried linking the Private DNS zone to the Hub VNET, in the hope that we could configure AADDS to forward any DNS requests that it can't resolve to Azure DNS. Unfortunately, AADDS does not forward any DNS requests for mydomain.co.uk onto Azure DNS - presumably because it believes it is authoritative for that zone.
Is there another mechanism that we haven't thought of yet?
• Since, you want the app workloads running on VMs in the spoke virtual network to search or forward the DNS requests from the Azure private DNS zone to the AADDS, you can surely leverage the functionality of conditional forwarder in this regard. Thus, to use this functionality, you would need to configure a VM as a ‘Domain Controller’ for this managed domain and associate it in a subnet that is reachable to all the domain joined resources in the hub and spoke virtual network model.
To join a VM to a managed domain and configure it as a ‘Domain Controller’ for serving the full features of ADDS and DNS, kindly refer to the below link for more details: -
https://learn.microsoft.com/en-us/azure/active-directory-domain-services/manage-dns#before-you-begin
Also, to configure the conditional forwarder in AADDS joined VM configured as a DC, ensure to install DNS Server tools, and use the DNS console to manage the records in AADDS as well as follow the steps below to configure a conditional forwarder in the AADDS VM: -
a) Login to a VM and open the ‘Administrative Tools’ --> ‘DNS’ --> DNS Management Console opens --> Connect to DNS Server dialog
b) Select Conditional Forwarders, then right select and choose New Conditional Forwarder --> enter the other DNS domain such as for example, ‘contoso.com’, then enter the IP addresses of the DNS servers for that namespace as shown below: -
c) Check the box for Store this conditional forwarder in Active Directory, and replicate it as follows, then select the option for ‘All DNS servers in this domain’, as shown in the following example: -
‘Conditional forwarder should be stored in the domain, not in the forest’
d) Name resolution of the resources in other namespaces from VMs connected to the managed domain should now resolve correctly. Queries for the DNS domain configured in the conditional forwarder are passed to the relevant DNS servers (Azure private DNS zone) and from there, the Azure VMs mapped or registered in there will be forwarded the DNS requests accordingly.
Thus, in this way, if you configure AADDS to forward any DNS requests to the Azure private DNS zone with the help of conditional forwarder, you would be able to forward the DNS requests for ‘mydomain.co.uk’ to the Azure private DNS zone for further resolution.
https://learn.microsoft.com/en-us/azure/active-directory-domain-services/manage-dns#create-conditional-forwarders
A comment on the above answer (thanks #Kartik), led me to the ultimate answer... which is that I'm trying to do something that is not recommended by Microsoft :-(
Apparently, I shouldn't be using the same name for both my AADDS managed domain and my application workloads:
https://learn.microsoft.com/en-us/azure/active-directory-domain-services/tutorial-create-instance#create-a-managed-domain
If you create a custom domain name, take care with existing DNS namespaces. It's recommended to use a domain name separate from any existing Azure or on-premises DNS name space.
For example, if you have an existing DNS name space of contoso.com, create a managed domain with the custom domain name of aaddscontoso.com. If you need to use secure LDAP, you must register and own this custom domain name to generate the required certificates.
It seems I am going to have to:
Choose another name for my managed domain (e.g. aadds.mydomain.co.uk)
Set all VNETs to use it for DNS resolution.
Setup a DNS forwarder to an Azure Private DNS zone containing the records for my workloads (mydomain.co.uk).
On Azure, I have a two-VM set (both classic), whereby my web application resides on one VM, my database on another. Both map to the same DNS and belong to the same Resource Group, but both are acting as standalone cloud services at the moment. Let me explain: currently the web application communicates with the database over the public DNS. However, I need them to be on the same lan, so I can de-risk security and improve latency.
I know for a fact that they're not part of a virtual network because when I try to affix a static private IP to my database VM, I'm shown the following prompt in the portal:
This virtual machine can't be configured with a static private IP
address because it's not deployed in a virtual network.
How should I proceed to fix this misconfiguration and what should my next concrete step be? The website is live, and I don't want to risk service interruption. Ideally, both VMs should be in the same virtual network, and should communicate with eachother via a static internal IP. Please forgive my ignorance. Any help would be greatly appreciated.
I guess i'll be the bearer of bad news. You have to delete both VMs while keeping the VHDs in the storage account, then recreate the VMs (reattaching the disks) in the Virtual Network.
Since these are Classic VMs you can use the old Portal when re-creating them. You'll find the VHDs under "My Disks" in the VM creation workflow.
Alternatively, just restrict the inbound access with an ACL on the database Endpoint. Allow the VIP of the first VM and deny everything else. This is good enough for almost any scenario, since if your Web Server gets compromised it's game over. It makes no difference how they exfiltrate stuff off your database (over a VNET or over VIP).
Here's the relevant documentation page for setting up Endpoint ACLs:
https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-classic-setup-endpoints/
I have created an Azure virtual network with a specific address space - 10.0.0.0/8. I created a subnet beneath it, 10.10.0.0/16, and added several machines to this subnet, including a PDC and a BDC, which are also acting as DNS servers.
Unfortunately, that is not exactly what I meant to do, I meant to create the address space as 10.10.0.0/16, with the intent of connecting it to some other virtual networks using S2S VPN gateways. The other virtual networks are set up using address spaces configured as: 10.x.0.0/16
To rectify the situation, based on what I could find here and on MSDN, I created a new virtual network in the same region with the correct address space (10.10.0.0/16), then deleted the VMs in the old virtual network (but left the VHDs) and recreated the VMs in the new virtual network using the old VHDs.
This seems to be working as expected. Now I am down to the domain controllers and one other machine. Will there be any issues with following the same process to move a domain controller? I realize the system GUID will be different, but was not sure if this impacts anything relative to AD and the DNS servers.
TIA for you help.
Looks like no impacts from the AD perspectives. From a DNS perspective, Azure assigned IP addresses to the machines in the order that they were restarted, so to avoid confusing DNS, I restarted the VMs in order of increasing IP address.
Needed to make sure SQL Server data volumes were attached before starting the machine, otherwise the database would show as being in a pending recovery state.
Also, apps that depend on MAC address (such as some license servers) did require new license files, as the MAC address changed.
Is it possible to use an Azure virtual machine that's setup as a domain controller to manage virtual machines hosted on other Azure subscriptions?
Personally I have never tried this before, but do not immediately see an issue with it.
I assume your Domain Controller is deployed using Microsoft's guidelines including assigning a static IP address?
With the ability to connect one VNet to another VNet (See: https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-configure-vnet-to-vnet-connection/) you can create the required network connectivity.
What you probably need to do is use your own DNS server for name resolution (See: https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-name-resolution-for-vms-and-role-instances/) in all connected VNets. I would recommend running DNS on your Domain Controller.
One thing to consider however is the generated traffic for authentication and name resolution. Do know that Azure is charging for traffic traversing from one Azure region to another.
Hope this helps you moving forward.
in this scenario is it required to create DNS server per subscription or one DNS server is enough for multiple subscription.
I have 2 VM's on Windows Azure, connected with a virtual network, including the "DNS" component linked to the virtual network.
The first machine is an AD controller (with DNS), and the DNS from the virtual network (in Azure) is pointed to this machine (10.0.0.4).
The 2 vm's can talk to each other, and the second VM is also domain joined with the AD controller on the first machine.
The problem is, on both VM's, I cannot access/browse to anything related to microsoft.com (like visualstudio.com, etc). All other sites (even bing.com) work without any problem.
What could be the reason. Do I need to change some DNS settings on my first VM so that microsoft.com is "excluded" or something. As I suppose that this is "internal" microsoft traffic?
Thanks!
Solved! You need to add the Google DNS to the list of DNS servers in the management portal, and link it to your Virtual Network.
To do so, add one or both of Google's DNS IP addresses (8.8.8.8 or 8.8.4.4) to the list of DNS servers associated with an Azure virtual network. In the Azure management portal, go to 'Virtual Networks > [Your virtual network] > DNS Servers', then add the addresses to the list and click Save.