Connect Windows Active Directory on ServerStadium 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 still want 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 must synchronize identities between Azure AD and Windows Active Directory. 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 won’t cover every option for the installation of Azure AD Connect. This is because there are a variety of ways to configure it. But we will explain one of the easiest ways to do so.

Prepare the environment for Azure AD Connect.

Before setting 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 has this following specifications 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 ServerStadium 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 connecting our Active Directory with Azure AD, we must install an Active Directory Domain Controller role. It will 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. You can find the full steps on How to setup Active Directory Domain Service with ServerStadium.

One thing you need to make sure of when configuring the domain name. For the sake of simplicity, you need to use a Valid FQDN (Fully-Qualified Domain Name) and Valid TLD. For example, use .com, .net, .org, and so on instead of .local, .staging, and so forth.

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

Setup Azure AD Environment

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

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

To connect to Azure AD with your on-premises active directory credentials, you must add the matching domain on the Azure AD. This is why you must 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 adding the custom domain name, Azure will ask you to add a new TXT DNS record on your domain. Thus, add the record to your Domain Name DNS management tool.

Your custom domain will be shown as Verified on the Custom Domain Name dashboard when the domain has been validated.

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.

Download Azure AD Connect

Firstly, download the 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 the Azure AD Connect download page

Setup and Configuration

After completing the download, we can continue with the Azure AD Connect setup and configuration. To do so, open the downloaded file and install it.

After the installation, there will be a 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 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 Custom Installation. In this guide, we will pick a Customize option.

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

Authentication

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

Accordingly, there are three ways of authentication methods 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. You don’t have to deploy any additional infrastructure besides Azure AD Connect.

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

Federated authentication – Azure AD will hand off the authentication process when you choose this authentication method. This is 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’s sake, you can use PHS for the rest of this installation

Connect to Azure AD

We are now ready to connect to Azure AD; we need an account with a Global Administrator account. If you’re using Federation with ADFS, don’t 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 .onmicrosoft.com domain to facilitate this.

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

As you can see above, you can create a new account or use an existing one. If you create a new account, you must provide the enterprise admin credentials. This allows 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. contoso.com\administrator or CONTOSO\Administrator). 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.

Verification and Synchronization

This next phase is about the verification of the domains we’ve just connected. UserPrincipalName (or UPN) in Active Directory is the attribute users use to sign into Azure AD, Office 365, etc. Therefore, the domain (or UPN-suffix) should be verified before synchronizing any objects into Azure AD.

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

By default, Synchronizing everything from the On-premises AD is the behavior upon getting to the next phase of the wizard. In Domain and Organizational Unit (OU) filtering, we can specify what we DO NOT want to synchronize to Azure AD.

This step is pretty straightforward. That being said, you might be concerned about which domains and OUs you don’t want to synchronize. If so, you may review the domain-based filtering and OU-based filtering articles. You can easily find them on Microsoft’s doc library before you make any changes.

Identify Users

Next is identifying 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 straightforward:

• 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. You’ll want to specify this option if you’ve used services like GALSync to create contacts.
• 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 simply 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 it’s 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.

Filter Users and Devices

As we go into the next steps of this wizard, we need to look at the available filtering options. Some examples of this would be group-based filtering. This allows us to synchronize only a smaller subset of objects for a specific use. For example, pilot, proof of concept, test, etc.). Please note that this is only meant and intended for pilot-type deployments instead of large-scale production deployments.

Optional Features

As we go into the wizard’s next step, 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 its 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 a 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 can simply set that. Then, it will allow you to provision/enable that feature in the wizard directly as a next step.

In this guide, we are not enabling anything besides the Password Hash Synchronization.

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

• Create the necessary computer object account in your on-prem Active Directory
• Configure the intranet zone of the client machines to support SSO

Configure and Verify Everything

Once you hit the final steps in the wizard, you’ll simply need to configure and verify. You must check whether you wish to start the synchronization process as soon as the wizard completes. Also, you can do this if you wish to enable Staging Mode. Accordingly, staging mode has some other steps. However, we will save them 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.

After that, navigate to the Users blade. If the synchronization has succeeded, you can find the users which on your on-premises being synchronized on the portal.

Finally, it is ready!

At last, your on-premises directory is now synchronized with Azure AD. You can continue to connect your Azure application with your on-premises credentials.