Connect Windows Active Directory with Azure AD

Many organizations running in today’s enterprises are not simply migrating 100% of all user/group object data into the cloud. They’re still wanting to maintain some presence of Active Directory Domain Services (i.e. AD DS on-prem) so they can still support authentication to other on-prem based applications and services. This means you need to synchronize identities between Azure AD and AD DS. Azure AD Connect is the Microsoft solution that will get you there.

Azure AD Connect supports many topologies, including a single Active Directory, multiple Active Directories, and even multiple Office 365 tenants.

In this guide, we’re not going to cover every option for installation of Azure AD Connect, as there’s a variety of ways to configure it.

Prepare the environment for Azure AD Connect

Before we are able to set up the Azure AD connect, there are three major prerequisites that we need to setup:

  • You need an Azure AD tenant. You get one with an Azure free trial.
  • Setup your on-premises Active Directory Domain Controller VM in Cloudraya, the one which will connect with the Azure AD
  • Have on-premises Active Directory schemas

For the complete Prerequisites, check out Official Azure AD Connect: Prerequisites from Microsoft Documentation

Setup a Windows VM in Cloudraya

First, we need to create a Windows VM in Cloudraya. Navigate to your Cloudraya Admin Panel and Add New VM. Make sure the VM is having this following specification so it can meet the minimum specification for Azure AD Connect:

  • 2 CPU Core
  • 20 GB of Storage
  • 2 GB of RAM

With these specifications, the best VM package to pick is small-c2

Also, don’t forget to set the Cloudraya Security Profile to allow RDP Port (default port: 3389)

After the VM has been created successfully, continue to access the VM via RDP

Setup the on-premises Active Directory and Active Directory Domain Controller

Before we are able to connect our own Active Directory with Azure AD, we need to install an Active Directory Domain Controller role, which will also act as Azure AD Connector.

Open Server Manager and click on Manage -> Add Roles and Features. On the Select Server Roles tab, check the Active Directory Domain Services button

Continue the configuration until the role has been installed successfully.

The next step is promoting the VM as an Active Directory Domain Controller, the full steps of this process can be found on the another article (How to setup Active Directory Domain Service with Cloud Raya) on the Knowledge Base.

One thing you need to make sure is when configuring the domain name, for the sake of simplicity, you need to use Valid FQDN (Fully-Qualified Domain Name) and Valid TLD such as .com, .net, .org and so on and not the local ones such as .local, .staging and so on.

After the VM has been promoted as a Domain Controller, your on-premises Active Directory is now ready to be connected with the Azure AD. The next step is to prepare the Azure AD environment.

Setup Azure AD Environment

First, you need to have an Azure Account, as stated in the beginning of this article, you can get this account with free trial provided by Microsoft.

If you already have a working Azure account, open the Azure Portal and navigate to the Azure Active Directory dashboard by searching it on the portal.

To be able to connect to Azure AD with your on-premises active directory credentials, you need to add the matching domain on the Azure AD, this is the reason why you need to use the Valid FQDN and Valid TLD on your on-premises AD. to do this, navigate to Custom Domain Blade and click on Add Custom Domain

You also need the domain to be verified, after you add the custom domain name, Azure will ask you to add a new TXT DNS record on your domain. Thus, add the record on your Domain Name DNS management tool.

When the domain has been validated, your custom domain will be shown as Verified on the Custom Domain Name dashboard.

Install and Configure Azure AD Connect

Now the on-premises AD and Azure AD end has been configured, the next thing to do is to configure the Azure AD connect.

First thing to do is to download Azure AD Connect application. The easiest way to download the app is by navigating to the Azure Active Directory dashboard, then click on the Azure AD Connect blade. You will see a link that leads to Azure AD Connect download page

After the download has been completed, we can continue with the Azure AD Connect setup and configuration. Open the downloaded file and install.
After the installation, there will be new application on your desktop named “Azure AD Connect”, open the application.

When we get into the installation method options of Azure AD Connect, we really have two options:

  • Express Settings
  • Custom Installation

You may want to pick Express settings if your on-premises AD is using single-forest topology and are using Password Hash Synchronization for the authentication option. Otherwise, you may click on the Custom Installation. In this guide, we will pick a Customize option

After you click on the Customize button, installation wizard does a quick check to ensure no other synchronization services are running and you can then specify any existing SQL Servers, service accounts, or synchronization groups.

After you specify the required components and/or custom installation location, the wizard will continue with the authentication method selection.

There are three ways of authentication method that can be used to sign in:

  • Password Hash Synchronization
  • Pass-through authentication
  • Federated authentication (using ADFS or Third-party applications)

Password hash synchronization (PHS) – Password Hash Sync enables users to use the same username and password that they use on-premises without having to deploy any additional infrastructure besides Azure AD Connect.

Pass-through authentication (PTA) – This option is similar to password hash sync but provides a simple password validation using on-premises software agents for organizations with strong security and compliance policies.

Federated authentication – When you choose this authentication method Azure AD will hand off the authentication process to a separate trusted authentication system, such as AD FS or a third-party federation system, to validate the user’s sign-in.

For simplicity sake, you can use PHS for the rest of this installation

We are now ready to connect to Azure AD, we need an account with Global Administrator account. Furthermore, if you’re going to use Federation with ADFS, you don’t want to use an account on the same domain you plan to enable for federation. A good way around this is to create that global admin account on the domain to facilitate this.

If you are entering a correct account, we can continue to integrate the on-premises forest first. Due to this, you need an Enterprise Admin account on the On-premises forest.

Now as you can see above, you can create a new account or use an existing account. If you opt to create a new account, you’ll be asked to provide the enterprise admin credentials to allow the wizard to provision a new account in Active Directory Directory Services with the appropriate permissions.

If you specify an existing account, specify the FQDN or NETBIOS name of the account (i.e.\administrator or CONTOSO\Administrator) to proceed. One thing to note about using an existing account is that it only needs default read permissions. However, some scenarios may require additional permissions. For those details, you can read the Azure AD Connect Accounts and Permissions for more information.

This next phase is about verification of the domains we’ve just connected. This is important because the UserPrincipalName (or UPN) attribute in Active Directory is the attribute that users will use when they sign-in to services like Azure AD and Office 365. Therefore, the domain (or UPN-suffix) should be verified before we synchronize any objects into Azure AD.

If you’re using Pass Through Authentication, you need to have at least one verified domain in order to proceed through the remaining steps in the installation wizard. This is the reason why we need to do the Custom Domain Verification on the beginning of this guide

By default, Synchronize everything from the On-premises AD is the behavior when we get to the next phase of the wizard. When we get into Domain and Organizational Unit (OU) filtering, we can specify what we DO NOT want to synchronize to Azure AD.

This step is pretty straight forward but if you have concerns about which domains and or OUs you are not wanting to synchronize, it’s not a bad idea to review the domain-based filtering and OU-based filtering articles on Microsoft’s doc library before you make any changes.

The next step helps define how we should identify users in Active Directory and how we want them represented in Azure AD. In some cases, you may have a user with multiple representations across multiple domains (i.e. an enterprise admin). You may also have the same thing for B2B, guest accounts, or mail enabled contacts in Active Directory.

Simply put, you need to uniquely identify your users to avoid duplicate entries in Azure AD. This step helps you define that and how you’d like to identify those users.

The options are pretty straight forward:

  • Users are represented once across all forests – all users are individual objects in Azure AD.
  • Mail attribute – This option will join users and contacts if their mail attribute has the same value in different forests. If you’ve used services like GALSync to create contacts, you’ll want to specify this option.
  • ObjectSID and msExchangeMasterAccountSID/msRTCSIP-OriginatorSid – This option joins an enabled user in an account forest with a disabled user in a resource forest. In the Exchange realm of taxonomy this is known simply as a linked mailbox. This option can also be leveraged if you only use Lync or Skype for Business and Exchange is not present in the forest.
  • SAMAccountName and MailNickName – This leverages those attributes where its expected that the sign-in ID for the user can be found.
  • Specific Attributes – You can select and define your own attribute. The only limitation here is this has been to be a searchable attribute across the Active Directory metaverse.

As we go into the next steps of this wizard, we start to look at specific filtering options that are available. Some examples of this would-be group-based filtering. This allows us to synchronize only a smaller subset of objects for a specific use (i.e. pilot, proof of concept, test, etc.). The most important thing to note is this really is meant and intended for pilot type deployments and not meant for large scale production deployments.

As we go into the next step of the wizard, we talk about the use of optional features. Here we can add options like Exchange hybrid deployment, Password writeback, Group writeback, etc. to the mix.

The list of features each has their own description if you click the source link above. If you go through the wizard, you’ll see the ? next to each item. This will also provide you with that description of each feature as well. I won’t belabor the details of each feature in this blog but if you want to add additional features, you will simply set that and it will allow you to provision/enable that feature in the wizard directly as a next step.

On this guide, we are not enabling anything beside the Password Hash Synchronization.

Regardless of if you’re using password synchronization or pass-through authentication, you simply need to ensure these two steps are completed:

Once you hit the final steps in the wizard, you’ll simply need to configure and verify. For the configure step, you simply need to do check whether you wish to start the synchronization process as soon as the wizard completes and if you wish to enable Staging Mode. Staging mode has some other steps that we will save for another blog. For now, we’ll synchronize (as we would if this were our first time running through the wizard) and proceed to the verification steps.

How would you know whether your Azure AD is connected to the On-premises AD? You can connect to the Azure AD Dashboard on the Azure portal. Then Navigate to Users blade. If the synchronization has succeeded, you can find the users which on your on-premises being synchronized on the portal

And That’s it!

Your on-premises directory is now synchronized with Azure AD. You can continue to connect your Azure application with your on-premises credential.

This post is also posted on Cloudraya Knowledgebase on 7 January 2021
Connect Windows Active Directory on Cloud Raya with Azure AD

Leave Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.