This year we are in a transition from an older sync tool (DirSync) to a new set of sync technologies, AAD Sync + AAD Connect (which will become one integrated tool before they GA). In addition, we have Forefront Identity Manager, which is great for managing complex on-premises identity workflows. So we get a lot of questions around which technology to use for which purpose.  In this post I will walk you through the different options here and what they do.  This isn’t going to be an extensive comparison between the product but rather a high-level overview. I will include links to external sites with more information where applicable.

Directory Sync

When it comes to synchronizing an on-premise directory with Azure (more specifically, an Azure AD tenant), the most commonly-known product is the Directory Sync tool (aka DirSync). If you have an Office 365 subscriptions, this is most likely the product that you are familiar with, since it is the one offered to you from the Office 365 portal when you are setting up synchronization, which looks like this:

DirSync is also available through the Azure Management Portal. When configuring synchronization between an Azure domain and your on-premise AD, the portal will offer the DirSync download in step 3, which looks like this:

In either case, you will be offered the currently available version of DirSync, which is version 1.0.x. The DirSync team makes regular updates to the version of DirSync that is available, so the version number here is approximate.

Forefront Identity Manager

When it comes to the actual synchronization of data (copying of users and attributes), DirSync relies on Forefront Identity Manager (aka FIM). If you have DirSync installed and examine the list of installed application, you will see both DirSync and FIM in that list:

FIM itself is highly adaptable platform for synchronizing data from one place to another, with the ability to synchronization with SQL databases, Active Directory, Azure Active Directory, LDAP, and other data stores. However, the setup and configuration of FIM can be tedious for less-experienced users. For users wanting to synchronize their on-prem AD with AAD, the setup process is almost always the same. To simplify thing, DirSync was create the streamline the process.

It's still possible to setup FIM to synchronize on-prem AD with AAD, but most users opt to install DirSync given its ease of deployment.

Azure Active Directory Synchronization Service

The eventual successor to DirSync is the Azure Active Directory Synchronization Service, also known as AADSync. As discussed on the overview page, AADSync provides new features that DirSync does not have, though at the same time lacks a few features currently in DirSync. A comprehensive comparison between DirSync and AADSync can be found here: Directory Integration Tools Feature Comparison. As of this writing, the comparison page was updated less than a week ago, so I believe the information is correct.

AADSync has both a simplified deployment experience (in following with DirSync), but is also a "next generation" synchronization server (to supersede FIM). The main selling point of AADSync is that is has the capability to synchronize from multiple Active Directory forests to a single AAD tenant - a feature that is not present in DirSync.

Azure Active Directory Connect

Today customers have the option between DirSync and AADSync to use as a synchronization technology. Both have their pros and cons, though at some point in the future AADSync will be the single choice.

However, a growing number of customers are interested in not just identity synchronization, but also federation. Federation (as described in a previous post) is where an on-premise service is utilized to authenticate users, typically Active Directory Federation Services (AD FS). For customer interested in federation, selecting a synchronization technology (DirSync or AADSync) is only the first part of deployment, after which servers need to be deployed and configured, and the Azure AD configuration updated accordingly.

This is where Azure Active Directory Connect (aka AADConnect) come in. As first mentioned on the AD Team Blog, AADConnect is a deployment solution for all of your DirSync/AADSync/AD FS needs. In the same way that DirSync simplifies the installation and configuration of FIM, AADConnect will simplify the deployment and configuration of your end-to-end identity setup. AADConnect isn't a synchronization engine like FIM or AADSync - simply installing AADConnect won't cause identities to magically begin synchronizing with AAD. What is does do however is provide an easy-to-understand experience  for deploying whatever technologies are required, based on your needed.

As an example (and I will cover this is more detail in a future post), instead of asking "Do you want DirSync or AD FS?", AADConnect asks "Do you want Password Sync or Single Sign-On?".

Distinctions like this are how we plan to simplify the process of installing and configuring an identity solution based on what you need, not what you know.

Wrap Up

With any luck, this post has shed a bit of light on the confusion among the various technologies mentioned above. Still confused? As a question below and I will expand the post as needed.

However, that world is almost completely gone, replaced by "the cloud". Services like Office 365 are compelling for a number of reasons: Cost effective (buy what you need), no on-premise infrastructure needed, it's always up-to-date, and best of all it's managed by someone else. The big tradeoff however is that, because it lives in the cloud, the identity story gets more complicated.

For any user-based service to function, it needs a source of identities to reference; an "identity store" if you will. The identity store informs the service of who the connecting user is and how to interact with them. For Office service like SharePoint or Exchange running on-premise, the service can talk directly to Active Directory. When user account get added or removed, the service "sees" the change by virtue of being directly connected to the identity store, aka Active Directory. Authentication happens by the user logging onto their computer with an account created for them in Active Directory. When they attempt to connect to SharePoint, Kerberos generates a ticket and the user is authenticated without them ever noticing. When a user changes his or her password, the change is processed by Active Directory and the ticket is refreshed, again without the user ever seeing anything different. For 20-some-odd years, this has worked well because the service (SharePoint or Exchange) existed within the same circle of trust as the user: Active Directory.

With the introduction of cloud services, the story isn't homogenous anymore. Office 365 can't directly "trust" an on-premise Active Directory (henceforth known as Windows Server Active Directory, or WSAD) in the way that your on-premise applications can. Instead, Office 365 trusts Azure Active Directory (AAD) - Active Directory running in the cloud. The trick now is to get the identities in AAD to "line up" with the identities of WSAD, which happens in one of two basic ways: synchronization or federation.

Managed Identities

Synchronization is the process by which parts of the on-premise identities are copied into AAD. In this scenario, AAD is the source for both the identities and for authentication used by Office 365 (and other cloud services that rely upon AAD). The Directory Sync Tool (aka DirSync) is employed for this purpose and handles the (secure) copying of data from WSAD into you "tenant" in AAD. To ease the discussion, you can think of a tenant as your company's own instance of Active Directory in the cloud. When users get added to WSAD, DirSync copies them into AAD. When users get removed, their account also gets removed from AAD. Passwords are also synchronized, thought that is a complicated topic that already has content that explains its functioning.

Users in this scenario are considered to the 'managed' (as opposed to federated). When a managed user attempts to log onto an AAD service (such as Office 365), they do so directly through the AAD portal.

Upon clicking Sign In, the user's credentials are verified against those store in AAD. Then end-to-end process of looking up a user's account, verifying their password, and redirecting them to the service happen within AAD (and its related sites). Your on-premise environment is not involved in any way, other than being the source for identities.

Federated Identities

The other primary way of linking WSAD to AAD is through federation. In this scenario, AAD is the source of identity but your on-premise servers are used to authenticate users. Users must have an identity in AAD in the same way as with synchronization, but they must authenticate with a server outside of AAD. DirSync is still needed to ensure that identities are copied into the cloud, but the organization must provide the external authentication "portal" to which users will be redirected.

AAD supports a number of different external authentication systems, but our focus is on Active Directory Federation Services (AD FS). By using AD FS for federation with AAD, a user logging onto an AAD-based service starts by entering their username on the AAD portal page. However, instead of entering their password on that page, they are redirected to a page provided by the external authentication service (AD FS, in this case).

The redirect occurs by AAD knowing that the user's account is federated (as opposed to managed), then issuing a 302 redirect to his/her browser with the address of the federation provider. With AD FS, the users will then see a page that looks like the following. Also, notice that this page is the one to collect your password, not the AAD login page, and is specific to the organization.

In this case, after entering their password and clicking Sign In, AD FS will validate the password then redirect the user back to AAD to finish the sign-in process (a transparent process).

AAD Connect

While both scenarios have their pros and cons, anyone wanting to use AAD with identities from WSAD will need to perform some amount of setup. This includes installing and configuring DirSync, configuring AAD domains, testing, validation, and lots of small steps along the way. The allure of AAD can be compelling, but as we have heard from customers, this process can be tedious, time consuming, and fraught with pitfalls along the way. Finally, this is where AAD Connect comes into the picture.

AAD Connect is a downloadable wizard whose aim is to lower the bar to getting your on-premise AD synced up with AAD. Using a wizard-driven experience, AAD Connect will ask a series of questions and prompt you to provide settings as needed in order to get synchronization setup. You don't need to have a complete understanding of how AAD authentication work, or understand technologies like Windows PowerShell. We even try to avoid situations like "Please download and install component X" by downloading and installing them for you. All you need to do is click a button. By making the process of connecting WSAD with AAD easier, our hope is that more companies will be able to leverage AAD and the services that run on it.

Over the next couple of posts, I will dive into what AAD Connect does and how it works under the covers, as this post is only to set the stage for future posts. There will be (much) more to come; we are just getting started.

Questions about AAD Connect? The best place to ask is the Windows Azure AD Forum.

What’s in a Management Pack?

Before installing the ADMP, it’s worth taking a detour to talk about what a management pack actually is.

It is easiest to think of Operations Manager as a very sophisticated engine for running health checks, and a management pack as a file containing how these health checks are actually performed. Obviously, I am oversimplifying things, but generally the purpose of Operations Manager is to provide a common and reliable infrastructure for running health checks, while management packs provide the logic of how to monitor a component or application. All management packs are written in XML following a specific schema, and can also contain embedded scripts (either VB script Windows or PowerShell script).

With that bit of a foundation, let’s get started with install the ADMP.

Getting the Management Pack

Management Packs that have been verified by Microsoft are made available through a service known as the Management Pack Catalog. You can browse (and download from) the list of all management packs available via the catalog on the catalog website. Additionally, if the machine where the management console is running has Internet access, you can download management packs using the Download Management Pack wizard. For our environment, I am going to download the ADMP manually.

Using the catalog website, searching for “Active Directory” should lead you to the Management Pack for Active Directory, and the Download link on the left side of the page will take you to the ADMP Download page (currently version 6.0.7670.0). You will also need to download and install the Windows Server Operating System Management Pack since the ADMP has dependencies on it.

After downloading, run the installer to un-pack the management pack files. By default, the installer will place the files in the System Center Management Packs directory inside of the ‘Program Files’ directory (or ‘Program Files (x86)’ if running on x64). Once the installer is finished, the directory containing the MP files will be opened.

If the management console isn’t yet running, go ahead and start it up. From the Administration tab, right-click on ‘Management Packs’ and select ‘Import Management Packs…’ to start the import wizard.

Using the ‘Add’ button in the top-right, select ‘Add from disk…’. Click “No” on the dialog that pops up, since we have already downloaded all of the management packs that we need.

Start by browsing to and adding the Microsoft.Windows.Server.AD.Library file. You should see an error being reported by the import wizard that looks similar to the following.

From the text at the bottom of the window, we can see that the problem is that the Active Directory Server Common Library depends on another management pack that is not yet imported. By clicking on the Error link, the wizard reports that the missing dependency is the Microsoft.Windows.Server.Library management pack. Click ‘Close’ on the error dialog window, then use the Add button to add the Microsoft.Windows.Server.Library MP file. Now you should see both MP files ready to be imported.

Now we can add the other management pack files that we will need. Since the only domain controllers that we are monitoring are running Windows Server 2008 R2, we only need to import the 2008 monitoring management pack. Note that we will however need to import all of the discovery management packs, despite the fact that we won’t be monitoring them. This doesn’t make much sense now, but in a future post I will talk about why this requirement exist. Trust me in that it will take an entire post of delve into the issue.

You should have the following list of management packs ready for import.

Click the Install button, and the installation process for the management packs will begin. If everything goes smoothly, you should see a message indicating that the import was successful.

With the management packs successfully imported, we can begin taking a look at the monitoring provided by the ADMP, which we will cover in the next post.

Create the Default Action Account

The first step is to create a Run As account, since the Operations Manager installation process will ask for it. We will dive into the finer details of what a Run As account is later, but for now you can think of it as the account that will to the “work” of monitoring, such as reading performance counters, executing scripts, etc. We can create this account the using Active Directory Administrative Center (ADAC):

We only need to provide a display name an SAM account name for the account. For my environment, I have set the password to never expire. This is fine for test environments, but be sure not to do this in a production environment.

Click OK to create the account. You can then close ADAC.

Installing System Center Operations Manager

With the Run As account create, we can start the Operations Manager installation process. Most of this is your typical Microsoft product installation process, but I will call out specific steps of interest.

After starting installer and selecting the components you want to install, you will be asked for a management group name. Simply enter a name to identify the group of computers that you will be monitoring. This can be any string (within reason) that  you want to use to identify the management group.

After setting the management group name, the installation wizard with prompt you for the SQL server name and database information. Next, you will need to provide the account name and password for the action account we created earlier.

The following pages of the wizard will ask you to select an account to use as an “SDK and Config Service Account”. Basically, this is the account used to connect and interact with the database, and to perform other configuration-related tasks. I find it best to leave the default choice there. The installation wizard will install Operations Manager and set up the database. This process can take some time, so this would be a opportune time to get a cup of coffee.

If you did not choose to open the Operations Manager Console at the end of the wizard, you can open it from the start menu. We will need the console to deploy the agents, which is our next step.

Deploying the Agents

Now that Operations Manager is installed, we need to deploy the management agent to each machine that we will monitor. The “agent” I am referring to here is a small piece of software that runs as a service on each machine that you will monitor to collect our monitoring data. By itself, the agent software doesn’t do much. However, once we get our management packs installed, the agent will play a critical role in the monitoring process, but we will get into more of that later on. For now, we just want to get the agent installed.

The agent can be deployed either by using the console to “push” the agent software onto the desired machines through a process known as “discovery” or by manually installing the agent software. Since the discovery process automates almost all of the tasks involved, we will use this method. You can start the discovery wizard by selecting the “Administration” tab in the console, then clocking on “Discovery Wizard”.

The discovery wizard window will open. Be sure that “Windows computers” is selected, then click “Next”. In the next page, select “Automatic computer discovery ” since we want the discovery wizard to locate our computers for us. In a large environment with 100’s of computers, you may want to select “Advanced discovery” to pick only the machines you are interested in.

In the Administrator Account page, we will need provide credentials to use for discovering the computers that we want to install the agent on. If you look at the highlighted piece of text, you will notice that this account will be used to install the agent software. If we were to leave the “Use selected Management Server Action Account” option selected, we would find the machines in Active Directory, by the agent installation would fail because the Management Server Action account it a standard AD user which does not have permission to install software on the machines we are targeting. We will use the domain administrator account to discover the machines and install the agent software.

Once the credentials are entered, click “Discover”. The console will then attempt to find all machines in the selected domain that are not currently managed (machines that don’t currently have the agent installed).

When the discovery process is finished, you will see a list of machines that were found.

Check the boxes next to each machine where you want the agent installed. Be sure the Management Mode combo box at the bottom of the dialog has “Agent” selected, then click “Next”. Leave the Agent installation directory and Agent Action Account options unchanged (since we want to use the default action account that we set up earlier), and click “Finish”. The wizard will attempt to install the agent software. This can take a while depending on a number of factors, especially in a larger environment, so this may be a good time for that second cup of coffee.

If everything worked out, you should see a success status for each machine that looks similar to the image below. If any of the installations failed, you can use the link provided by the wizard to help troubleshoot the installation.

With the agents successfully deployed, we are ready to import the Active Directory Management Pack. Fortunately, that installation process is far simpler by comparison. We will tackle management pack installation in the next post when we talk about the basics of the ADMP.

Contoso has an Active Directory forest with multiple domain, sites, and version of Windows. The layout of their forest looks like the diagram below. As we progress through the different scenarios, I will likely need to add more machine to the environment, so expect this diagram to change over time.

In reality, the entire Contoso infrastructure lives as virtual machines on a server in my garage, so the setup will be quite simplified. However, this set of machines should provide an environment with enough variability to show how the ADMP can be used.

The first step deploying the ADMP is to setup System Center Operations Manager (SCOM) on a dedicated machine; this will be the first project we tackle, and the topic of the next post.

Since that time, I have expanded my bag of projects to include AD-related Management Packs and Active Directory Administrative Center. Since I am no longer a developer for the Windows Time Service (yet I still want to contribute information to the topic) and I want to discuss topics in addition to the Windows Time Service, I decided to start a new blog. This blog will focus on the following topics:

• Windows Time Service
• AD-related Management Packs (including the Active Directory MP, the Lightweight Directory Service MP, and possibly other MPs)
• Active Directory Administrative Center
• General WPF (Windows Presentation Foundation) development

Well, there is a lot of ground to cover, so let’s get started. My first few posts will dive into the Active Directory Management Pack – a topic that has received far less attention that it deserves. I’ve spend the past few years working on the ADMP, and based on user feedback, it sounds like there are a lot of questions out there.

Suggestions?

Have a suggestion for a topic? Just leave a comment at the bottom of this post. I am putting together my first few posts, so if you have an idea, let me know. Remember: This blog is for you, the community, not me. Let me know what you are interested in hearing about (regarding the topics above) and I will try my best to get you the information.