There are many reasons to integrate your on-premises domain with your Azure Active Directory (AAD) domain. You might want self-service password resets, you might want two-factor authorization, you may want a single identity to manage for each of your users. No matter what the reason you want to integrate the two, doing so is pretty simple to start, but a little harder to get just right. That’s why I’ve been invited to join several clients on their integration efforts, even though I’m not an Active Directory expert.
In this first article, I’ll walk you through the easiest way to get started integrating your environment. I’ll leave some of the more advanced things for later articles.
Before you get started you’re going to need to have your Azure account, with an AAD instance stood up and running. You’ll also need a local domain up and running. You also need to make sure you’ve added and verified the domain name you are using for your local domain.
In my case, I’ve added toyboxcreations.net and shannonlowder.com as custom domain names for my AAD instance. Notice I’ve only taken the steps to verify my ownership of toyboxcreations. As I have things set right now, I could not integrate a local domain for shannonlowder.com.
Verifying your ownership is pretty easy, Azure will give you a TXT record they want you to add to your DNS records. After a period of one to 48 hours, they’ll query the DNS entries for your domain, and if they find the record they gave you, it proves you own the domain.
In a production integration, you’ll want a separate Windows Server with the GUI installed. I’ve found you also can’t convert a server running Windows core to a GUI version and then install Azure AD Connect, it has to be a GUI-first installation.
If you’re not familiar with Windows Server Core vs a GUI version, imagine if you will installing Windows on a machine, but only getting a command-line interface like a dos prompt or PowerShell prompt. The up-side is you’re not wasting resources drawing a UI when someone needs to make administrative changes. The down-side is if you need to install any software that doesn’t support command-line install and running.. then you’re out of luck. This was Microsoft’s first attempt at moving towards a Linux server style approach.
With all of the above complete, you’re ready for a simple install. In later articles, I’ll add a few more requirements for the Windows server where we’ll install Azure AD Connect.
Go ahead and download Azure AD Connect, and let’s get started.
Install with Express Settings
In all my projects integrating AD with AAD, they’ve always begun with an express setup. The reason for that is express supports a single-forest topology (the way most AD instances are set up), and password hash synchronization.
What that means is rather than synching actual passwords between your on-premise instance and AAD, only a one-way hash is synched between then two. The password sync process runs every 2 minutes, so there is a pretty small window to hit in order for your users to change their password on one side, and not get to use that new password on the other.
Read then agree to the license terms and privacy notice. You always read those completely, right?
On the next screen, click “Use express settings” to continue.
Enter the username and password for an account in your AAD instance that is in the AAD DC Administrators group. This is usually a separate, administrative use only account, not an account someone is going to log in with on a regular basis.
Then enter a user that has Enterprise Admin rights. Again, this account is usually an administrative account, and not one used by a user to log in regularly.
Finally, click Install to finalize your Azure AD Connect service. Once complete, you can verify everything was successful going into the Azure portal and look at your list of users under your AAD instance.
This is the most straight-forward install there is. There’s a pretty good possibility that you’ll see an error, or warning along the way. Even if you didn’t get an error, you may find that one of the features you wanted to use after integration isn’t working as you’d expect. I’m going to start covering those extended features in my next article, including the sync error where you find new users being created in your AAD instance that you never requested. Ones that look like <username>email@example.com. In the meantime, if you have any specific questions, please hit me up on twitter @shannonlowder! If you’d like to see this integration work as a session at SQLSaturday, please let me know, and I’ll start submitting it as a session!