Setting up a solid identity and access management foundation with Azure AD Sync

Not everyone has a simple Active Directory structure, not everyone can move all their user objects and every single attribute to Azure AD, without a little nip-and-tuck. This post is going to help you deepen your core skills around Azure AD Sync Services, so you can go beyond the basics!

In this post, we’re going deeper than just setting up a simple sync. Let’s ramp your skills up!

Get your user’s stuff together!

How long have you been running on your current AD? At the very most it is about 14 years… Wowzers! People’s kids have started and FINISHED school in that time and now their thinking about college!

It’s quite possible that some of those objects in your on-prem AD DS might not be all that fresh or important anymore. Perhaps you’ve got some attributes that you just don’t need, perhaps you’ve got some user objects that you don’t need to be cloud enabled, perhaps – just perhaps – you have a non-“standard” AD DS (!)

Think about exactly what you want to sync

Azure AD Sync service, if you aren’t familiar with it yet, is the replacement technology for DirSync. Azure AD Sync makes some default assumptions about your environment that you need to understand.

Users have only one enabled account and the forest where this account is located is used to federate the user.

Users have only one mailbox.

The forest that hosts a user’s mailbox has the best data quality for attributes visible in the Exchange Global Address List (GAL).
If there is no mailbox on the user, then any forest can be used to contribute these attribute values.

Having said that these are the default assumptions doesn’t mean that you can’t challenge them. Out of the box (so to speak) Azure AD Sync setup drop-dead easy for a simple scenario. Either single or multi AD forests, where there is no duplication.

But what if there is duplication? Azure AD Sync can help here too, you just might need to break out the more advanced tools.

Let’s first take a look at the components that we need to understand.

Azure AD

One single Azure AD can be the “recipient” of users, groups, contacts and InetUsers from multiple on-premises Active Directories. Centralization is one of Azure ADs most powerful features, but you need to help Azure AD Sync service to understand exactly what your plan is. The first step is to identify the forests that you’re going to sync from and how those forests work with each other.

On-Prem Active Directory Forest topologies simplified.

There are typically three types of forest topologies:

Separate Technologies

The first is pretty simple, two forests that don’t trust each other. For example, you might come across this if Contoso and Fabrikam were two companies under the same parent organization that shared no management structure. In this case, you could just use Azure AD Sync out of the box.

Full mesh with optional GAL sync

The second option is more complex. Here you have two on-premises AD DS forests that trust each other. There might be duplicated user accounts and contacts in the GAL in each company. For example, if Contoso acquired Fabrikam, IT set up trusts between them and they started to share business functions. Here you will need to set up “matching” across the forests – usually on the mail attribute as it’s uncommon for a corporate user to have multiple email address (although it does happen).

Account Resource Forest

The third option is when there are one or more account forests with active user accounts. Here, one forest trusts all the account forests and typically shared resources live in that forest. For example, Contoso and Fabrikam are subsidiaries of Tailspin, Tailspin is the resource forest.

Introducing the Metaverse and Connector Spaces

Azure AD Sync’s job is to make sense of the objects in your on-premises AD DS and deliver them into Azure AD. Azure AD Sync takes the information stored in objects in your AD DS forests and projects them into a construct (actually a SQL Server DB) called the Metaverse. Azure AD Sync does this based on synchronization rules, both inbound and outbound in Connector Spaces.

We are getting into the internal workings, but it’s important to understand what’s happening for a less “off the peg” scenario. Really, it’s all about matching and provisioning.

When Azure AD Sync finds and object, it takes a look at what it already knows in the metaverse to see if the new object in the connector space matches anything already there. If it does, it will, based on some attributes, join the objects. If not it will either provision or disregard the object.

Let’s move on to look at the objects we are syncing.

Users

Users can exist in any synchronized forest. An active account will always contribute login information, including userPrincipalName and sourceAnchor. The user will have a number of attributes, some of those attributes can be used by the Azure AD Sync tool for user matching. For example the Mail attribute.

Of course, many of those other attributes store lots of bits of information. The available attributes depend upon how the AD DS schema was extended. Do you have Exchange or Lync, for example? Azure AD Sync usually creates an Azure AD User for a user account when it doesn’t see a matching instance in the metaverse, but if it does see a match then it will join the objects.

Disabled accounts are also synchronized to Azure AD. For non-Exchange folks, disabled accounts are often used to represent resources such as conference rooms in Exchange. A disabled account will contribute userPrincipalName and sourceAnchor, unless it is a linked mailbox in which case it’s effectively ignored because an active account will be found later.

Contacts

Contacts are common in scenarios where a global address sync has taken place between two forests. When Azure AD Sync sees a match between a Contact and a User in the metaverse it will join the two. If a User object isn’t seen, a Contact object is created. However, if a subsequent User object is found that matches the Contact then it is promoted to a User and a User object is created in Azure AD, ultimately.

What’s the net effect?

It’s really hard to see what the effect will be before synchronizing directories and assembling the metaverse. However, the net is that you’ll have a deduplicated, single Azure AD.

Azure AD Sync is designed to run continuously ,on a periodic basis. On an first sync, where multiple AD DSs are imported into the metaverse, it’s impossible to know with accuracy which objects from which AD DS will be imported first. That’s why Azure AD Sync takes the approach it does to matching.

Now you understand how Sync works a little better, what can you do with that information?

Having grasped the basics of the sync engine, you can start to make tweaks to the rules that make sense for your organization. For example, you can change the rules for how objects in your AD DS are joined to existing objects in the metaverse. Or you can “transform” the information in the attributes, changing almost anything about it. Transformation is actually a very powerful feature and has a rich language all its own, so you can get really custom. If you’re familiar with IdFix this is a better way of fixing issues that IdFix may have found.

Configuring Filtering

One of the other, less “off the peg” requirements you might have, is to not synchronize everything to Azure AD. There are three ways that you can filter your AD DS based on what’s going to meet your needs. Filtering will, essentially, prevent some objects from being created in the metaverse that otherwise would.

Domain-based filtering

If you manage Contoso and Contoso has two domains, Contoso-US and Contoso-DK, but only the Chief Security Officer from the US part of the organization is comfortable with storing User objects in Azure AD and her German counterpart isn’t, then this is the filtering method you would use. (Also you should have a word with that CSO and possibly mail her the link to the Azure Trust Center).

Organizational Unit based filtering

If Contoso has a Physical-Access-Only OU, which is only used to hold the most secure user objects then OU-based filtering is the way to go.

Attribute-based filtering

If Contoso doesn’t have a natural partitioning structure based on AD DS or, has users with a specific attribute that must or must not be synchronized this is the way to go. For example you could add an extension attribute with a value of “NoSync” to all the user objects that you don’t want synced for some reason.

It’s important to know that this is very different from configuring attribute synchronization in the wizard. Attribute-based filtering will import (or not import) objects into the metaverse based on attribute values for that object. Configuring the attributes (or apps) that are synchronized to Azure AD in the wizard will configure which attributes are synchronized for the objects in the metaverse. Two very different things.

Inbound and outbound filtering

The next important thing to realize is that there are two different types of attribute-based filtering, inbound and outbound, as defined from the viewpoint of the metaverse. That is, inbound attribute-based filters control what comes into the metaverse and outbound filters control what leaves to metaverse. When we work with synchronization rules we don’t want to mess around with the predefined rules because we would lose our changes upon upgrade of Azure AD Sync.

For the most part, inbound attribute filtering will do what you need, only projecting the objects you want from AD DS into Azure AD. However there are times when there isn’t enough information in the attributes to filter as you would like. As an example, take the account resource forest topology. There the information as imported from the objects in the resource domain might not be enough on its own and Azure AD Sync might need to join it with information from the user domains.

Attribute-based filtering can be configured at any time, and if you remove something through filtering it will also be removed from Azure AD. It’s possible to configure filtering in Azure AD Sync I’m not going to dive into thousands of words on this since the documentation is so good at explaining how.

Now we’ve covered what the objects are and how to control their appearance in the metaverse and subsequently Azure AD, let’s cover attributes.

Synchronizing Attributes to Azure AD

One of the most useful and intelligent features of Azure AD Sync is that, during setup, you can specify what attributes are to Azure AD.

You might not be an expert on exactly which attributes you need though, so the Azure AD team made it easy. Azure AD Sync gives you a list of all the Office 365, Microsoft Intune and Azure AD enabled apps from Microsoft, simply select which apps you use and Azure AD Sync will work out the attributes you need to sync.

Do you want to Sync Passwords?

This is one of the most important questions that your organization needs to answer. The ramifications are pretty huge.

If you do choose to sync your passwords you need to know that you aren’t actually sinking the passwords. You are syncing a non-reversible hash of the passwords. To put it simply: When a user attempts to authenticate against Azure AD, the authentication provider (which could be an app or a web page) will hash the characters they enter as the password. This hash is then sent to Azure AD and compared with the hash that Azure AD has. If they match, the user gets in, if not they don’t.

Password sync can be two way. Initially all passwords for synced users are hashed and stored in Azure AD. If a user changes their password on-prem, the password sync is quickly to Azure AD (the default is within 2 minutes). If the user changes their password in Azure AD (if you let them by enabling self service) then the reverse will happen, updating the users password on-prem.

What’s super-cool though, is that you can choose to do both. This means that if you implement AD FS and it fails for some reason, like you’re data center floods, then your users will still be able to authenticate with Azure AD using password sync. Pretty neat.

The one sacrifice you make here is that without AD FS you won’t be able to get Single Sign On (SSO) because there isn’t any way to synchronize or share tokens.

Related

Simon May is an Infrastructure Technology Evangelist at Microsoft concentrating on Devices and Services but with special interests in deployment and device management. Simon is a professional public speaker and the author of several books on Windows. Opinions on this blog are his own.

5 Comments

Nice article!!! Just a question though : you wrote that in a separate topologies situation, we can use AADsync out-of-the-box… A little more info on that? should we install an instance of AADsync in each forest? Cause I’ve read that having more than one synchronization server exporting to a single Azure Active Directory is unsupported… I’m a little confused!

Hi Simon,
I extended our AD for Exchange 2013 as we do not have an Exchange server. I did this after setting up AADSync. Microsoft really needs a big bold warning to do this first. Anyway, I can’t seem to get the Exchange attributes (specifically MsExchHideFromAddressLists) synched. Both connectors show the attribute as selected and I have run the sync manually on both connectors but no dice. I have searched the Metaverse and a query returns no results for the Exchange attribute. It appears that the updated schema info is not making its way into the Metaverse. Any suggestions?

I thought i would pass on what I figured out:
It turned out that I had to go to the Sync Rules Editor and add that Exchange attribute to the Inbound Transformations (in from AD – User Common). I didn’t check beforehand, but the Outbound rule (Out to AAD – User ExchangeOnline) already had that attribute already in place. (MsExchHideFromAddressLists). Once I ran the full sync the value was sync’d and the user is no longer hidden from the address lists.