This post is part of a series, for the series contents see:
Microsoft publish some prerequisites for Azure AD Connect but most of them sort themselves out, the one’s I’ve gone through for this lab are detailed below.
I’d already built an aadconnect-vm (see the Azure IaaS Lab series) but as it wasn’t part of the domain yet it wasn’t that much use to me.
Adding IaaS VMs to a domain always brings up a minor DNS conundrum:
IaaS VMs get their DNS settings via DHCP from the VNET and to join a domain the VM must be able to use DNS to contact the domain controller.
You could just login to the VM and manually change the DNS servers via the NIC settings – it would work for a while but after a reboot or a change Azure side you’d soon find that the config would revert and you’d lose your settings. So what you need to do is add the IP of your DC to the list of VNET DNS servers. It’s simple enough to do with PowerShell and there’s a nice blog post about it here. Rather than reinvent the wheel I’ve modified and reused siddsachar’s code as follows:
#Login to Azure and resource manager Login-AzureRmAccount #Set out base variables $RGName = "internal-rg" $VnetName = "internal-vnet" $DNSIP = "188.8.131.52" #Get our internal vnet $vnet = Get-AzureRmVirtualNetwork ` -ResourceGroupName $RGName ` -Name $VnetName $vnet.DhcpOptions.DnsServers = $DNSIP #Set and save the config Set-AzureRmVirtualNetwork -VirtualNetwork $vnet
With DNS ready to go I needed to reboot aadconnect-vm before it picked up the new settings and then I was able to add it to my domain with any issues.
I did bump into an interesting issue though with the DNS settings. At first I added a list of DNS servers that included Google’s boxes on 184.108.40.206 and 220.127.116.11 (using the iteration method from siddsachar’s post) but with those added my aadconnect-vm seemed to struggle to find the SRV record for my domain. Once I removed the Google boxes then everything worked fine but that does leave aadconnect-vm with not recourse to public DNS. The solution to that is to simply add the Google boxes into the DNS config on ad-vm. When I say that I’m talking about the actual DNS role config rather than the network settings for the reasons mentioned above.
Azure AD Connect is essentially connecting two ends of a pipe: Azure AD and an On-premise AD. So, in order to do that you need accounts with permissions on each side, specifically:
- An Azure AD account with the Global Administrator role.
- And an on-premise AD account that is a member of of the Enterprise Administrators group.
In prep I went ahead a created an Enterprise Admin account called “irankon” on-premise and up in Azure I created a Global Admin cloud identity called email@example.com:
I did this through the GUI which is a bit of a pain as it creates a temporary password for you that you then have to reset by logging in as that account, but not a major problem:
Directory Health with IdFix
Microsoft recommend that prior to synchronising a directory you should use their IdFix tool to check it’s health, the logic being that problems are much harder to fix after the initial synch than they are before.
The tool is a pretty lightweight install (get it here) and you don’t have to run it on a DC. I ran it on aadconnect-vm and the results came back good:
No errors which can’t be bad!
AD Recycle Bin
Microsoft’s guidance also recommends enabling the AD Recycle Bin on the on-premise domain. It doesn’t really say why this is recommended but if I were to hazard a guess, I would say it probably relates to the writeback feature. With that enabled you could conceivably delete a load of users from the Azure directory and those changes would be reflected down to your on-premise setup. If you did that by accident then the Recycle Bin would give you lifeline to get those accounts back.
Anyway, enabling it easy enough, I just ran the following on ad-vm:
Enable-ADOptionalFeature ` –Identity ‘CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=irankon,DC=tk’ ` –Scope ForestOrConfigurationSet ` –Target ‘irankon.tk’