A Closer Look at Azure AD Connect – Part 2

In the previous part of this article series, we've taken a first look at Azure AD Connect and reviewed what a default installation looks like using the express settings. In this part, we'll dive deeper into the advanced options of the installation wizard. The express settings option likely meets the needs for most organizations looking into deploying directory synchronization alone. However, if you are looking at a more complex synchronization scenario, like a multi-forest environment or if you would like to deploy and configure Active Directory Federation Services, the advanced options are what you are looking for!

Note: The advanced options, especially the ones related to the advanced synchronization scenarios, are very powerful and can create potentially disastrous consequences. Even though we will be discussing the various options throughout the next few articles, do not attempt to make any changes if you are not completely familiar and comfortable with the option and its effects on your deployment and environment!

If you have already installed Azure AD Connect before, you will no longer have access to all the options in the installation wizard. Instead, double-clicking the Azure AD Connect icon on the desktop will launch a similar configuration wizard, which allows you to:

• Review the current configuration
• (Re-)Configure synchronization options
• Enable/Disable staging mode (discussed later)

Changing the directory synchronization settings is for a different article. The steps below assume that you have just installed Azure AD Connect and you are running the installation wizard for the first time.

When the configuration wizard starts, click Customize instead of Use express settings, as explained in the previous article. This will allow you to select the following options:

• Specify a custom installation location, which allows you to specify a different path where the Azure AD Connect components will be installed.
• Use an existing SQL Server.
• Use an existing service account.
• Specify custom sync groups, which control what administrative actions one can execute with the directory synchronization tools through the use of existing Active Directory groups. By default, AAD Connect will create local groups on the server, not in Active Directory.

Unlike previous versions, where you had to revert to the command line (CLI) utility to install directory synchronization services with a separate SQL database, Azure AD Connect allows you to specify the SQL server (+ service account) right in the wizard — much easier and faster!

If you do specify a separate SQL server, you must also specify an existing service account. This service account can be a regular domain user account and does not require any special permissions. Also, make sure the account, which is used to run the configuration wizard, has the appropriate permissions to create a database on the SQL server. This often requires you to ask your database administrator to create a new login in the SQL server and assign the dbcreator server role to it. I suspect you can also pre-stage the SQL database (named ADSync) and just assign dbowner permission to the account as well. However, I have not tested that myself.

After clicking next, the wizard will install the synchronization components and take you to the User Sign-In page where you can: 

• Set up Password (Hash) Synchronization
• Configure identity Federation with AD FS
• Do nothing :)

If you do not configure Password (Hash) Synchronization here, you can still select it later in the wizard. This allows you to set up both Identity Federation and Password Hash Synchronization so the latter is already available should you ever encounter the need to "fail over" from identity federation to synchronized password hashes.

If you choose to configure Federation with AD FS, the wizard will automatically take you through a few additional steps related to the setup of Active Directory Federation Services later. First, you need to provide some additional parameters such as the credentials to your on-premises directories and Office 365 tenant:

Note: The account specified to connect to your tenant will not be used for synchronizations. Instead, AAD Connect will use the admin credentials to create a new 'service account' in your tenant. This service account will look similar to DirSync_ServerName_Guid@domain.com. That account is then given limited admin permissions in your tenant so it can write objects and changes to Azure AD. Similarly, an on-premises service account will be created in the default users container. This service account typically looks like MSOL_guid:

On the Identifying users page, you have the ability to alter how directory synchronization behaves in multi-forest environments. If you have a single on-premises environment, the defaults should work just fine. We won't go into detail on how to set up a multi-forest environment right now; that is reserved for a future part of this article!

The next page, Filtering, allows you to set up initial filtering by specifying an Active Directory group. If you do so, only members of this group will be synchronized to Azure AD. You can also configure additional filtering options after you have run through the entire wizard. This will require the use of the Synchronization Rule Editor, which we will also discuss in a future article.

On the Optional Features page, you can enable additional synchronization features such as support for a hybrid deployment, password synchronization and password write-back. You will also notice that the current GA version of the product also allows you to select certain features that are not fully supported in production (yet). These features include User- and Group writeback capabilities or the ability to synchronize non-standard directory attributes to Azure AD.

Note: The hybrid deployment option will trigger the installation wizard to automatically provision the necessary permissions for the service account so it can write back the attributes required to make a hybrid deployment work successfully. The installer does this by assigning the permissions on the top-level domain and assuming that security inheritance is not blocked in your OU structure. If that is the case, you might find that your hybrid deployment does not work as expected and synchronization errors occur. For more information about these write-back attributes and possible causes for issues, take a look at the following article: https://support.microsoft.com/en-us/kb/2406830

After configuring the synchronization option, you have the ability to specify options for the AD FS configuration. On the AD FS Farm page, you can either specify an existing AD FS farm or choose to deploy a new AD FS farm. The latter option will force you to select at least one server to be your AD FS server and one server for your Web Application Proxy. While this is probably OK for most customers, some environments do not wish to use a Web Application Proxy to publish their AD FS infrastructure to the Internet. In that case, you have to deploy your AD FS farm prior to running through the Azure AD Connect wizard. In the final step, you have to specify which domain you would like to federate. The list of domains available on this page is generated automatically from your Office 365 tenant:

 If you do not see your domain in this list, it might not be set up correctly or at all in your Office 365 tenant.

On the final step of the configuration process, you can select to set up the server in staging mode. This feature warrants a few words. Prior to Azure AD Connect, setting up a highly available synchronization environment was a bit tricky. In fact, one could argue whether or not high availability for directory synchronization is needed. Although the process itself is important, synchronization occurs every three hours, and the only downside of a failed synchronization server is that any changes will only be replicated after it's brought back online. So far, so good.

However, what happens if you cannot revive the failed server? The answer is you could simply set up a new synchronization server and be done with it. While this is true, the new synchronization server would have to set up its version of the metaverse. This is an intermediate database, which dirsync uses to compare contents between the on-premises Active Directory and Azure Active Directory. Depending on the size of your environment, the initial (full) synchronization could take multiple hours. Hence, this approach would potentially extend the outage window for directory synchronization.

Staging Mode essentially sets up a second directory synchronization server, but the server's ability to export changes to Azure AD or the on-premises organization is turned off. This means the server will run in conjunction with the other synchronization server, without actually making any changes in either environment. If the 'primary' synchronization server fails and you cannot recover it, re-run the configuration wizard to take the second server out of staging mode. It will almost instantly take over the functionality from its fallen comrade.

This concludes part 2 of this Azure AD Connect article series. Before exploring additional capabilities like how to configure object filtering, we'll first take a look at the upgrade experience from earlier versions of the directory synchronization tool in part 3. Stay tuned!