Integrating your Active Directory domain with Azure Active Directory

With the plethora of service that Microsoft offers via its Office365 service, it’s hard to ignore the fact that having multiple identities across your organization can be quite problematic. With every Azure or Office 365 subscription you get provisioned an Azure Active Directory account in order for you to be able to login to consume the services you just paid for. Using one account you can get access to Exchange, SharePoint, Office 201(x) on demand, Dynamics CRM, Skype For Business and other neat tools like Planner, Sway. With Enterprise Mobility Suite you get access to Azure Rights Management, Intune, Information Security, Azure Active Directory Premium which include a lot of features like service wide MFA, Azure Active Directory Join (Windows 10 is best for this job).

What I’m trying to say here that using one account you get access to a multitude of services that improve your workflow and organization. The only problem with this is that most organizations have on-premise servers and a central directory management system (Active Directory, OpenLDAP/Samba, 389 Server etc.) and having multiple accounts (and passwords) proves to be quite a challenge for the IT staff to enforce security whilst providing the best experience for their users. We all know that password security is a big problem (look at all the breaches that happened in the last 2 years) and enabling the best security under one roof is one of the ways to go.

In this article I will talk about how you can integrate your on-premise Active Directory domain with Azure Active Directory in order to provide your users the best experience while accessing their resources without compromising your organizations security.

First of all, why should we integrate our on-premise identities with Azure Active Directory?

The main reason in doing this is to provide your users a common identity for accessing both your on-premise and cloud resources with the capability of monitoring and enforcing security models across all your services. This is one of the main advantages of deploying a solution this like.

Think of this, there are thousands of applications out there that work with Azure Active Directory. How does the thought of having a single-sign-on experience for GitHub Enterprise, Dropbox for Business, Salesforce, Amazon Web Services including Office 365 services while enforcing a complex password security plus multi-factor authentication? I for one can’t be any happier that I only need to keep one password updated in my password manager and my trusty phone nearby.

So if everything sound good so far then keep on reading because I’m going to talk about how you can integrate your Active Directory environment with Azure Active Directory by using the Azure AD Connect tool.

The Azure AD Connect tool is the successor to Azure AD Sync (DirSync) that was used in the not so long past to enable hybrid identity.

Azure AD Connect is is made up of three components:

Synchronization Services – This component is responsible for synchronizing Active Directory objects from your on-premise environment to the cloud environment.
Active Directory Federation Services (optional) – This component is optional because you’re not obligated to have an ADFS server in your environment but if you want to handle complex deployments like AD sign-in policy, or 3rd party MFA then this type of deployment is the way to go.
Monitoring Services – This component handles all the monitoring part and can provide a central location inside the Azure Portal where you can monitor all the synchronization activity. You can read more about this component here – https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-health/-

The installation process of the Azure AD Connect tool is pretty straightforward but before you actually start installing and configuring the tool, you must do a simple configuration on your Azure Active Directory deployment. The only thing that you’re required to do in order to continue with the installation is to configure a custom domain. This operation can only be done in the old V1 portal (manage.windowsazure.com). The process is quite easy, you basically add a custom domain and a DNS record at your DNS provider and complete the registration.

If you already Office 365 with a custom domain configured then there’s nothing else you need to do.

From this point, you can start installing the Azure AD Connect tool. In test environments you can install the tool directly on your Domain Controller but I advise against that when it comes to production environments and a separate server should handle this job.

1. Download Azure AD Connect from the Microsoft Download Center – http://go.microsoft.com/fwlink/?LinkId=615771 –

2. Install the tool and select either Express Settings or Customized settings -For most deployments you can safely go with the express settings but if you have a non routable domain (domain.local) or multiple forests then you should really go with the customized settings part to ensure that everything gets synced properly. I will go with the customized part so you can see some of the options you have.

3. At the User Sign-In part you are presented with three options:

a. Password Synchronization
b. Federation with ADFS
c. Do not configure.


The options presented are not explained very well and may cause some confusion.

There are three ways to synchronize your Active Directory Environment:

1. You can synchronize AD Objects without password hashes – You can do this part by selecting “Do not configure” and you will be only synchronizing users, groups and other objects while the passwords remain on-premise. By using this options, your users will be maintaining two passwords instead of one. In simple terms, they will be able to login to the cloud applications but with a different password.

2. You can synchronize AD Objects with password hashes – Same as option one but with the difference that password hashes will be synchronized to Azure Active Directory and users will be able to login to their cloud resources using the same account and password but when the password expires, they will not be able to login to their cloud services using the same password until a synchronization cycle runs, this is a matter of a couple of minutes and shouldn’t be an issue.

3. Federate the domains using ADFS – By using this option, you enable a true single sign-on experience while having the possibility of not synchronizing the password hashes to the cloud. By using ADFS you can even go further and enable options as 3rd party MFA, Smart Cards, Domain Join Single Sign-On. By having a hybrid identity backed up by ADFS you can also address even more complex necessities like limiting cloud resource access to the enterprise users when they are at the workplace or when connected to a VPN.

After you decide how you’re going to handle user logins, you can proceed to the next steps where you provide logins to the AAD deployment (global administrator required and a @onmicrosoft.com address) and a domain admin to your on-premise environment. After that you’re presented with the step where you configure your sign-in configuration. The default way is by using the user principal name (UPN).

The screenshot above shows a warning that users will not be able to login using their on-premise credentials because in this example I’m using a non-routable domain. For this to work, some transformations need to happen

The next step involves filtering where you can either synchronize the whole directory (by default) or specific domains / objects.

At the identifying users step, you are required to either go with the default setting where the users are unique across all directories or by configuring a match filter by specific attributes accompanied by a Azure AD Pivot which by default is the Object GUID.

The next step is a filtering step that is only required if you’re doing a pilot to see if everything fits nicely in your plan.

And finally we get to the optional features step where we can configure:

Exchange Hybrid Deployment – This option allows the coexistence of Exchange Mailboxes between your on-premise environment and your Azure environment.

Azure AD Application and Attribute filtering – You can use this option if you want to limit which attributes are synchronized to Azure AD.

Password Synchronization – This option allows you to either synchronize the passwords or not. In case of a federated domain with ADFS this option would be recommended as a fall back procedure in case the ADFS server is not available.

Password Writeback – This options allows two-way password synchronizations which enables the user to reset his password from the cloud. Password writeback requires additional configuration in the V1 portal but it’s a matter of point and click. This option is not available on free Azure AD instances and you require either a basic, premium or a paid Office 365 license for it to work.

Group Writeback – This option allows synchronization of newly created groups in Office 365 Groups. This only works if you have and on-premise installation of Exchange

Device Writeback – This options allows synchronization of cloud joined devices to be synchronized back to the on-premise environment for conditional access.

Directory Extension Attribute Sync – This option enables you the possibility of synchronizing any custom attributes from your on-premise environment so that your Line of Business applications can use them. Office 365 will not be able to use these attributes if you chose to synchronize them.

Once you’ve decided what optional features, you can finish the installation and start synchronizing the domains.

If you want to go with the federation step with ADFS, the tool can do everything that’s required to set up an ADFS server. If you don’t have ADFS then the tool can also install ADFS. You only need a domain joined machine and a trusted SSL certificate for your custom domain.

The synchronization can take a while depending on the size of your domain but from my experience it shouldn’t take long.

When the full synchronization process is completed, you can login to your cloud resources by using your on-premise credentials and from there you can start adding applications from the market ?

That’s it folks, have a great one!