**DISCLOSURE: While I am contracted to Microsoft Corporation, I am not an employee. The articles that I write are not meant to represent the company, nor are they meant to represent me as an employee or spokesman for the company. As has always been the case, all articles on this website represent me and nobody else.
**NOTE: All of the command line entries in this article are performed in PowerShell. To differentiate between the PowerShell cmdlets and Command Line Interpreter commands, the PowerShell cmdlets are in blue, and the Commands are in black.
Like many of you, I have been using Active Directory Domain Services (AD DS) for a very long time. So when Microsoft comes along and says ‘Hey, we have a new cloud identity service called Azure Active Directory (AAD), I was excited to try it… until I realized that it was more of a new product than an evolution of my trusty ADDS.
Guess what? It’s time to get over it. Yes, it is new. Yes, it is different. No, we do not have to throw out twenty years of Active Directory and start anew. We can, instead, connect our existing Active Directory with out Azure AD, which is the first step into the future… with Single Sign-On (SSO) and unified identities, and without us having to give each use two accounts (one for their local computer, and one for their cloud resources).
So let’s set up Azure AD Connect, the tool that will bridge AD DS and AAD.
Before you start downloading anything, you should set up a new server for your Connect box. I know organizations that add the functionality to an existing server; in an era of virtual servers and virtual licensing models, I try not to do that. I want my Azure AD Connect to sit on a clean server, and not be beholden to other services.
The server I have set up for it is a Windows Server 2019 box with the Desktop Experience. I know, Server Core rocks. I don’t think it is an option for us here. I gave it 3gb of RAM which should be plenty. It has to be domain-joined, obviously.
Once you have your system set up, download the Azure AD Connect bits from here.
Navigate to your downloads folder and execute the file AzureADConnect.msi. You will be asked to confirm in a User Account Control (UAC) pop-up.
Once it is installed, an icon will appear on your desktop, but it will run automatically. In the Welcome to Azure AD Connect screen, click the box I agree to the license terms and privacy notice and click Continue.
In the Express Settings window you can either move ahead, or click Customize. Let’s go that route.
In my environment, I already have an existing SQL server, so I am going to use that. However the other options I will use the defaults. So my list will look like this before I click Install:
(Note that if you are using an external SQL Server you do have to specify an existing service account)
It will take a couple of minutes, but the next screen will determine your users sign-in methods. The options are:
- Password Hash Synchronization (allows your users to sign in to the cloud and on-premises resources using the same password);
- Pass-through authentication (enables AAD to authenticate to users from the AD DS on-premises infrastructure);
- Federation with AD FS (allows you to federate sign-in with AD Federated Services. So, when logged into the corp network, users can access cloud resources without re-entering their passwords. This option requires an AD FS infrastructure to be in place.);
- Federation with PingFederate (similar to the previous option, but using a different infrastructure); or
- Do not configure (self-explanatory)
On the same screen, you can also select the checkbox to Enable single sign-on.
When you are finished on that page, click Next.
On the following screen (Connect to Azure AD) you have to enter the credentials of a user with the Global Administrator role. Do so, then click Next. It will connect to your AAD and confirm the credentials are sufficient.
On the next screen, you will select your directory type (almost certainly Active Directory), and the name of your forest. Click the Add Directory button. The following screen will pop up:
I am going to take this opportunity to create a new account; you cannot use an account with either Domain or Enterprise Admin rights. Click OK to return to the previous screen, where it will have added your Active Directory. Click Next.
On the next page, the Azure AD sign-in configuration screen will check to see if there is a matching Azure AD domain. Assuming there is, you can select the on-premises attribute to use as the Azure AD username. The default is userPrincipalName, but you can select from a long list. Click Next.
On the next screen we can select which OUs and which domains to sync. My demo environment is small so I am doing it all, but you can select what to sync granularly. Click Next.
On the next screen (Uniquely identifying your users) you can select how users should be identified in your on-premises directory. Configure this as you will, then click Next.
On the Filter users and devices screen we can select which users and devices to sync. This is good for pilot programs where you only want to synchronize a small handful of users and devices. Click Next.
On the Optional features screen, we can select a few different options. Note that the Exchange options (as well as others) are greyed out. This is because the Azure AD Connect has checked the AD Schema and has determined that I do not have Exchange Server installed. I will, however, select the Password writeback option. This ensures that password changes made from the cloud will be written back to the on-premises AD. Click Next.
On the Enable single sign-on page, you have to enter credentials for an domain administrator. Once you do, your domain will be listed with a green check mark. Click Next.
The next screen verifies that everything is ready to go. You have the option to enable Staging Mode, which will not export your date to AD for Azure AD. Otherwise, when you click Install, the process starts!
Depending on a number of factors, this process can take some time. When it is done, your Azure AD Connect will be installed, and your on-premises and cloud directories will be (and will continue to be) synchronized.
Once it is done, you will see a couple of recommendations. Pay heed to them! With that said, you can now log into the Azure AD to see that your on-premises user accounts have been created.
On this list, several users are listed as Directory synced, and were copied from the on-premises AD. For the conflict (mgarvis) the account was synchronized, but there was an account in AAD with that name and e-mail address already, so a new account with a new e-mail alias was created. These conflicts will have to be addressed manually, but they should be the exception rather than the rule.
Test it out… log on to your cloud resources with one of the synchronized accounts. It should work just fine!