Installation in Four Steps

The installation comprises four steps. To begin, download and launch the MicrosoftAzureADConnectionTool.exe file. The installer unpacks all the data required for the configuration in the C:\Program Files\Microsoft Azure AD Connection Tool directory. The configuration wizard then launches automatically. You need to quit the wizard at this point to install AADSync with a SQL Server – Microsoft provides the command-line program DirectorySyncTool.exe in the AADSync directory for installing with SQL.

For this article, I used the wizard for the SQL Express version. After you have agreed to the license conditions on the welcome page, the wizard installs the SQL Express database and the synchronization service. Both steps are completed automatically after pressing Next on the welcome screen.

The next step involves telling the wizard the account with the global administrative privileges in Azure AD. The account is specified in the form of an email address (e.g., syncadmin@contoso.onmicrosoft.com ). Next, define your local AD's service account, which has read access to the AD data. Also, add the AD forests to be synchronized. The tool is capable of synchronizing the identities of several forests connected by a trust.

In the subsequent third step, AADSync wants to know where users come from and how they log in. The case is clear if all users only exist once in all the connected forests (Figure 1). If users have multiple accounts in a multiforest environment, AADSync wants to merge these accounts so they only have to synchronize them once. The Exchange Resource forest is an example of several accounts for one user: Users who use Exchange in this trusted forest have a shadow account in the Exchange forest and an account for the computer application for AD. AADSync obviously does not aim to synchronize both accounts in the cloud, but instead merges the accounts logically and then syncs the work account with Azure AD.

Figure 1: The basic configuration can be set up quickly in less complex environments, thanks to the wizard.

Next, you select the unique AD attribute for the sourceAnchor attribute ; you can identify user accounts with this in the future. The default selection, objectGUID , is a good choice in a single forest, because this GUID does not change for a security principal as long as it does not leave the forest boundaries. However, this also makes life a little difficult in multiforest environments: You need an attribute that does not change when migrating an account so that AADSync still recognizes the user after the migration and can link the user with the cloud account. The employeeID attribute, which must not change when migrating, is a good candidate for this. In principle, however, any other attribute can be used for this purpose, but it must be unique and should not be modified over time (e.g., because of a username change).

Set the attribute that you would like users to enter for login to userPrincipalName (UPN), which you can select if the local Active Directory UPN can be routed and the domains belong to you. Otherwise, you need to select an attribute that meets these requirements. Typically, the mail attribute is a good candidate because it can be uniquely assigned to a user, has an email format, and uses a routable company domain. Ownership of this domain is checked later by Azure, which rules out cheating.

Assigning Privileges

In the fourth step (Optional Features ), you can determine in AADSync what you want to allow in the Azure AD and local AD. You will need the Exchange hybrid deployment option if users' mailboxes are to be kept on a local Exchange server and in Office 365. You need to enable Password synchronization if users can log in to Azure AD without ADFS or another identity provider being available. This causes AADSync to synchronize the users' password hashes in the cloud.

A note in advance: Not all IT security staff think this synchronization is a good idea, which is why many companies prefer ADFS. The passwords and their hashes then remain in the local AD and the box for Password synchronization remains unchecked. You will need Password write-back if you want to allow users to reset their local AD passwords using Azure AD. Again, IT security would probably be happy to have a quick chat with you about allowing Azure AD to reset passwords in your local AD using AD service accounts.

If you do not have any other requirements, this is the end of the AADSync configuration. If you are aiming for more precise control of the synchronized attributes, check Azure AD app and attribute filtering . The wizard then opens two further steps for you, in which you can define your planned use cases in more detail. In this way, you can just synchronize the necessary attributes in Azure AD. The downside: If needs change and your users want to use further applications that require additional attributes, you need to re-run the wizard.

Finally, you can trigger directory synchronization in the Finished section by checking Synchronize now . AADSync then proceeds to synchronize all the common and chosen attributes of users, contacts, and groups with the cloud directory.

Synchronization takes place automatically if you selected Synchronize now in the final wizard step. Sync jobs are controlled as a scheduled task in Windows: Azure AD Sync Scheduler is the task that AADSync defines for this purpose. If you uncheck the Synchronize now box to make additional configurations, you will need to start the task manually later. The setup may create the task, but it also disables it. Right-clicking on the task and selecting Enable then starts the job.

After successful synchronization, you should find the synchronized user accounts in the Azure portal or in the Users section of the Office 365 portal. To make sure the synchronization worked correctly, you need the Synchronization Service , which you can launch in the Windows Modern UI or as miisclient.exe in the C:\Program Files\Microsoft Azure AD Sync\UIShell directory. Membership for one of the local ADSync groups is required for this action. You will thus want to add the Azure AD server administrators to the local ADSyncAdmins group, and the employees from operations to ADSyncOperations . Both user groups can then launch the tool.

Linking Services

You now need to establish a federation trust between the local infrastructure and Azure AD to enable SSO for users within the domain. The bridge connecting the two worlds will be ADFS. You cannot create a typical AD trust for the purpose of a forest trust, even if Azure AD and the local AD share a confusingly similar name. ADFS creates this trust for you: For each connection, Azure AD trusts your ADFS, which then delivers a token to your authenticated users who can, in turn, be evaluated by Azure AD and other web applications on the web.

There are two prerequisites for federating with ADFS: a routable domain that has been verified in the Azure AD portal and a configured ADFS server that you link with Azure AD via PowerShell. The routable domain is verified by adding it as a domain to Azure AD. The portal then requires you to create a TXT or MX DNS record in the root of the DNS zone to check the domains' ownership (Figure 2). The check may take several hours depending on the service life of the zone records and is something you will want to do in advance. You can see the domains' status under Domains in the portal. It should be Verified .

Figure 2: A domain must be verified by creating DNS records before use with Azure AD and Office 365.

If you already have an ADFS installation, you can use it for connecting with Azure AD. Connecting with Office 365 and Azure AD can be done painlessly from ADFS 2.0 and newer. New developments for ADFS in Windows Server 2012 R2 are, however, worth a closer look, such as the possibilities of the Workplace Join or the Extranet Lockout feature. Anyone who is contemplating a new ADFS instance for the project should use ADFS in Windows Server 2012 R2. Microsoft has simplified setting up the connection with Azure AD to the effect that the setup and configuration are handled completely via PowerShell.

Download the Azure Active Directory PowerShell module [2] if the ADFS installation is already running correctly. The Microsoft Online Services Sign-In wizard is also required for installing the module [3] – initiate this before the module installation. You can install both on any computer and do not have to include them on the ADFS server. Now there are no more obstacles to connecting and installing domains that were verified previously. Set up the connection with Azure AD using Connect-MSOLService, which will prompt you for the username and password for the subscription's administrator. Once connected, the domain verified using Get-MSOLDomain appears with a status of Verified (Figure 3). The following command then completes the federation between ADFS and Azure AD to secure SSO:

Convert-MSOLDomainToFederated -DomainName <domain>

Figure 3: If everything went smoothly, the verified domains are shown as Federated under the Authentication column.

If multiple domains need to be connected, for example, to link more forests, include the -SupportMultipleDomain parameter at the end of the command. Each additional domain is then also added with Convert-MSOLDomainToFederated. SSO is immediately supported for the added domains, both in the PowerShell with Get-MSOLDomain and in ADFS, under Trust Relationships | Relying Party Trusts . The Microsoft Office 365 Identity Platform is available as the new relying party here.

You can check the associated Office 365 login by accessing the Office portal in your browser below https://portal.office.com and using a synchronized user account. After entering the user's UPN, the Office 365 login page will redirect the browser to ADFS. There, the user will be authenticated and finally allowed to access the Office 365 portal. If this login succeeds, the lion's share of the work is already complete: The connection has been made and the users have also been correctly synchronized from your local AD to the Azure AD.