Microsoft is working on a new version of its identity synchronization software for the Microsoft Online services. In this blog I’d like to share my experience in testing this tool in my test environment.
As you may know is that the version Active Directory Sync for the Microsoft Online services is based on FIM 2012 R2. This works very well if you do not have many demands in synchronizing your identities from Active Directory to Microsoft Online. But when your environment is a little bit more complex like with multiple forests, this version of AAD Sync might be interesting for you. One of feature you might be missing in the current version of DirSync is the support for multi forest synchronization. Until now the only way to overcome this limitation is to implement DirSyncs big brother Forefront Identity Manager with the Windows Azure Active Directory Connector for FIM 2010 R2, but FIM 2010 R2 is way more complex to manage and it adds additional pressure to your IT budget. With the beta release of Microsoft Azure Active Directory Sync Services (AAD Sync) this disadvantage is overcome with the support of multi forest synchronization. See here how it works.
 |
This blog is based on AAD Sync Beta 3 due it’s not finally released yet, future beta release might work different than this one. |
 |
Please note that in this blog a Active Directory schema update is discussed. When you decide to extend your Active Directory Schema, this attribute must not contain any special characters because AAD Sync cannot operate with special characters. In my case I’ve extended my Active Directory schema with the following attribute settings:
Please note that AD schema updates are not reversible. |
Preperations
My configuration will be set-up with the following parameters:
- Two forest environment;
- Using Azure Active Directory;
- Using a custom metaverse and Active Directory schema attribute as immutableID.
AAD Sync is installed on a Windows Server 2012 R2. Because it is still in beta you have to make some adjustments to make it work:
- Disable UAC;
- Run the .NET Framework Strong Name Utility so verification of the code will not fail: “sn – Vr *,*”
- Install the .NET 3.5 and .NET 4.5 features in Windows.
Initial Installation
First start the downloaded setup file MicrosoftAzureADConnectionTool.exe. This install the baseline for AAD Sync, creates a desktop shortcut to configure AAD Sync and starts the AAD Sync configuration wizard.
When you start the installation it will install the following components to your computer:
- Microsoft Online Services Sign-In assistant;
- SQL Server Express 2012;
- Microsoft Azure AD Sync;
- Forefront Identity Manager Windows Azure Active Directory Connector.
Extending Metaverse
After finishing the initial installation we have to make some adjustments before we can configure AAD Sync with our custom immutableID:
- Sign-out and sign-in from Windows to activate group memberships for starting the Synchronization Service Manager;
- Start the Synchronization Service Manager as Administrator from “C:Program FilesMicrosoft Azure AD SyncUIShellmiisclient.exe“.
In the Synchronization Service Manager we are going to create a custom metaverse attribute with the metaverse Designer with the following settings:
- Object type: Person;
- Attribute name: <your custom attribute name>;
- Attribute type: String (indexable);
- Checkbox: Indexable.
This concludes the metaverse extension, let’s continue with the AAD Sync configuration.
AAD Sync Configuration
When finished you can close the Synchronization Service Manager and start the configuration wizard from the desktop (as Administrator).
The most common challenge in the identity landscape is the design of a unique identifier across the environment. I will not further zoom in to this challenge, but this is also an important part in synchronizing a multi forest environment. During the installation of AAD Sync you are able to set the synchronization options. Here you can choose a unique attribute that exist in both forest.
There are a few options that can be chosen, the first is the easiest one and depends mainly on your Active Directory management skills. Duplicate accounts across the forest will give synchronization issues in AAD Sync.
In case you have an environment where users have multiple accounts, for instance an account and resource forest, you select “Use the following options”. Here you can choose one of the predefined attributes or you can even define your own schema attribute. When synchronizing with AAD it will join duplicate accounts based on the attribute you have chosen. Please note there are some limitations:
- A user will only have only one enabled user account and login information is taken from this forest.
- A user will only have only one Exchange mailbox.
- The data quality for a user is best in the forest where Exchange is located.
- If an Exchange mailbox is found, common user attributes are taken from this forest.
The ability to choose your own immutableID is a nice welcomed option in AAD Sync. By default DirSync always synced the object GUID as immutableID, but this is not sufficient in some cases. When looking at the immutableID the most important characteristic is that it is unique and it does not change for the specific identity, but in some cases you don’t want it be depending on the object GUID in Active Directory. For instance when you have an existing automated provisioning system, a unique identifier maybe already available from out the source or it is generated in the provisioning process. With the possibility of using a (custom) unique identifier you can provisioning this identifier value from your existing identity provisioning system to Active Directory and use it as you own custom immutableID in the Microsoft Online services. This makes the account more independent related to the account store where it is located. For instance if you have multiple forest and want to move user accounts across these forests without affecting the object in Microsoft Online.
|
|
Please note that when you are planning to use federated authentication, you correctly define your claims so the correct immutableID is provided in your claims. |
In my test environment I’ve created my own immutableID attribute in Active Directory to see how it works. As described above, you first have to extend the metaverse and your Active Directory schema before you can use a custom attribute.
The second identitfication option you have is the choice of the UserPrincipalName attribute. I leave it default at this moment, but with the new version of ADFS in Windows Server 2012 R2 Update 1 you will be able to choose another UPN attribute than the default. This makes it possible to use a UPN like login id different than the default in Active Directory. See http://technet.microsoft.com/en-us/library/dn659436.aspx for more information.
On the next screen you are able to configure a Hybrid deployment, password write-back and Azure AD app and attribute filtering. Because I do not have an Exchange environment in place at this moment I will not implement Hybrid Synchronization now and I will going to use federated login with ADFS so password write-back is also disabled. For I’ll select only the option to filter Azure AD app and attributes just to show you what the options are.
When ready you can confirm the configuration.
When the configuration is finished we can make some adjustments in the object filtering from AD, so we are not ready to synchronize right now.
Configure OU filtering
Open the Synchronization Service Manager and select the Management Agent screens. In this case I’ll filter the sources based on organizational unit level.
To edit filtering from the source Active Directory select the properties of the specified management agent and select Configure Directory Partitions. Then click Containers, enter a admin username and password and select the appropriate OU’s.
When finished this step we start the initial synchronization with Powershell.
Start Initial Synchronization
In the current version of DirSync a PowerShell command was included to start the initial sync (Start-OnlineCoexistenceSync), somehow this cmdlet is currently not included in this beta so we have to use another method to start the sync. This can be achieved with the DirectorySyncClientCMD typing DirectorySyncClientCmd.exe initial from the C:Program FilesMicrosoft Azure AD SyncBin at the command line.
From the Synchronization Service Manager you can monitor the synchronization process.
When the synchronization is finished we can see the results in AAD in Powershell:
As you may notice is that the user’s UPN in AAD is still based the <tenant name>.onmicrosoft.com UPN suffix. Currently I do not have registered a custom domain name in AAD, when this is accomplished you are able to use you custom UPN suffix.
Final thoughts
This concludes my blog article about the latest beta version of AAD Sync. As you have seen it adds welcomed new features to its repository enabling more flexibility in synchronizing identities to the Microsoft Online Services. Currently I’m not aware if a release date is communicated for AAD Sync, but as you can see beta 3 is working pretty well so I hope that it will not take to long for the final version.
(C) Copyright – Mark van Eijken – 2014
Login