AAD Connect: Identity sync for the layperson
It used to be the case that a business owned its "identity story" end-to-end. Employees get hired, their account gets created, and the IT folks manage everything. Access to file shares, password policies, and everything else related to the user account was owned and managed by the company. External access (if allowed) was done only through a VPN or similar secure mechanism. When the employees leave the company, the account it removed, and access goes away. In retrospect, this almost seems easy. Quaint perhaps.
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.
Comments
Anonymous
August 16, 2014
Hi Ryan! 3 years ago in your old blog you wrote: On the new blog, I will still talk about the Windows Time Service, as well as a few other interesting topics. The first few posts will be dedicated to the Active Directory Management Pack, but take heart; I have a few ideas already lined up for the Windows Time Service. What about this? Any hope ?Anonymous
September 08, 2014
yeah. there is no time, ther is no hopeAnonymous
September 12, 2014
Ok, what do you want to know about? Pick a topic and I will see what I can do.Anonymous
October 26, 2014
Does AAD Connect set up Managed or Federated identities or let you choose?