In the previous post Azure Active Directory Connect overview Part 1 we explored on a high level the options for installing the AAD Connect tool. Even though there is an automatic setup for a default installation a custom setup has been used in order to change specific settings. What it is important to mention at this point is that the actual configuration can be changed at any time like mentioned in the previous post. But how the AAD Connect tool operates it is now covered in this post. So from here a continued overview of the Synchronization tool.
The AAD Connect synchronizes identities between Active Directories on Premise and Online. During the setup the necessary information have been provided to let the tool create the required connectors as in the picture below:
Each one of these connectors than has the ability to run several profiles (one at a time). Each profile essentially can be used to:
In the case of Import and Synchronize they can run in Full or Delta mode. The picture below for example shows the preconfigured profiles for the AD on premise
Of course it is possible to change the default value associated to each profile depending on the number of objects that need to be retrieved and synchronized. Once the data (objects) are imported from the Connector and placed into the Connector Space then the synchronization process will create/update/delete objects and attributes in the Metaverse based on the Inbound Synchronization Rules. Depending on the Outbound Synchronization Rules then the data (objects and attributes) will be exported to the other Connector Space talking with the Connector configured with the AD instance in Azure.
I’m conscious though I’ve just introduced new terms.. so to make things a little bit more familiar here you are a simple picture showing the steps with a brief explanation below:
This is the main module which connects with the data source (AD on premise/online). There are two main functions: Import data from connected system to the Connector Space based on ISR (Inbound Synchronization Rules); Export data from the Metaverse to other Connector Space based on OSR (Outbound Synchronization Rules). Import can be Full and Delta. Export will operate primarily from the last “synchronization”.
The action of creating/updating/deleting the objects in the Metaverse is called Attribute Flow. So the Metaverse is a consolidated view of all the Attribute Flows. The Attributes Flows operate only between the Connector Space and the Metaverse both ways. This operation it is only possible through the Synchronization steps (Full and Delta) and for both ISR and OSR. This prevents for example unwanted imported changes or deletions from the pertinent data sources through the Connectors. Reviewing data in the Metaverse before committing this one with an Export can help a lot in troubleshooting scenarios or to do some fine tuning on the objects and attributes that should be synchronized. This is covered later on with regards to the Metaverse Search
This is the space where the Connector is storing the data (objects and attibutes) from the connected data source (for example the local Active Directory) using the Import profiles. In this way the data is ready for the Synchronization process to merge with the one in the Metaverse according to the ISR/OSR rules. This will also prevent the AAD Connect Tool to continuously connect to the different data sources.
Inbound/Outbound Synchronization Rules
These rules are created automatically during the installation of the AAD Connect Tool and serve the purpose of filter the objects that should be created/updated/deleted in the Metaverse or exported to the relevant Connector Space. It is also worth mentioning that the Metaverse cannot edit any object directly but only synchronize based on the ISR/OSR rules with the connected data sources. It is also possible to customise and create specific rules using the Synchronization Service Rule Editor. This will covered in a different post.
Whenever a new object needs to be created by mean of an ISR rule this operation is regarded as Provisioning. However this operation only takes place in the Metaverse hence the provisioned objects will not touch the destination data source connector space (for example Azure AD instance) until an Export profile is run.
One more information I would like to provide before running the AAD Connect tool is about the configuration of the connectors. And in particular the one used for the local AD instance. As already mentioned in my previous post Azure Active Directory Connect overview Part 1 during the installation I selected the entire Domain Directory on purpose. But at the same I wanted to run the AAD Connect tool only on a portion of the Active Directory as I didn’t want to specify a particular AD group for testing. Well as a matter of truth this is still possible by selecting specific containers (OUs) and then use these ones for testing instead. The AAD Connect Tool allows 3 types of filtering:
The lower level you choose the higher complexity and flexibility you have with configurations.
For the purpose of this post I will use the Domain and OU levels for filtering. For testing I want to synchronize all the objects within one OU and the pertinent children containers. The next screenshots will show the necessary steps.
So from the Synchronization Service Manager a right click on the Connector for the AD on premise to access the properties:
Then in Configure Directory Partitions we can select the preferred AD Server (when using more than one on premise) and also specific OU’s selecting the button Containers…
In my example I have only one domain. Should more domains be available they can be selected from here.
At this point we are prompted to enter the credentials for a user that has access to local Active Directory.
OU’s level filtering is possible from here where we can select specific containers we want to synchronize with Azure Active Directory.
The Advanced button also shows the ability to provide more OU’s by mean of inclusive/exclusive rules.
Once the Containers are selected it is also possible choose which object types within these containers will be synchronized. This would be the options we use for objects filtering.
Last but not least also which attributes should be included in the Metaverse before being replicated to the Azure Active Directory. This would be the options we use for attributes filtering.
Now we are ready to Import the data in the Connector Space by running a Full Import profile.
At the end of the import job it is possible to see the number of objects imported into the Connector Space. This includes categories like Unchanged, Adds, Updates, Renames and Deletes.
Interestingly by clicking on the Adds will show the new objects imported in the Connector Space. Furthermore it is also possible to check the properties of each one of these objects. The screenshot below shows Users and Computers which are two categories part of the filtering configuration in the previous steps selecting the object types and relative attributes. Plus all these objects reside on the selected OU’s.
We can use this first step to analyse on the data we are importing in the Connector Space. Should this data be different from what we were expecting we can still review the Connector configuration and rerun the Full Import again. The same applies also if we make changes to the AD structure. We might need to rerun the Full Import if these changes to the AD are affecting the OU’s selected as Active Directory Partitions in the previous steps. If otherwise the shown data is reflecting our purpose then we can proceed with a Full Synchronization to populate the Metaverse with the objects as per ISR from the Connector Space.
At the completion of the Full Synchronization job we can review the imported objects (Projections – based on ISR) and also the number of Objects ready to be exported to the Azure Active Directory (Provisioning Adds – Based on OSR). Projections in the screenshot below shows Users and Computers in the chosen OU..
Provisioning Adds in this screenshot below shows the objects that will be exported to Azure AD. In this case Users or better call them Identities..
If we move to the Metaverse Search it is very easy to check which objects have been imported and synchronized. The view below shows some users with pertinent details in additional columns.
By changing the selection for the Object Type and adding a clause (for example excluding all Computers where DisplayName does not include “UK”) will show the synchronized objects and relative values that can be selected through the button Column Settings..
Note: On the Action menu can be found the Import/Export query which come quite handy to work with different “views” of the data in the Metaverse at the same time rather than building them every time.
If we are happy with the synchronized results in the Metaverve the last step would be to Export them.
Since in our configuration I selected not to start synchronizing content right after the wizard was completed this means I now need to run this step manually or wait for the default schedule to run this job (3hrs) after the initial trigger. In fact when installing the AAD Connect Tool this will create a scheduled task as per screenshot below. But according to previous wizard configuration it is Disabled. So Export will never happen! Not good for testing 😉
In this instance I’d rather run this manually following these two simple steps: by Enabling the Azure AD Sync task as per picture below. In the properties of the task it is allowed to change the schedule to something more suitable for the business needs.
As a last step by executing the ADSync tool by command line (PowerShell not needed in this case) to force a Full Synchronization and Export now with this command:
The tool can be found in the \..\Program Files\Microsoft Azure AD Sync\Bin\
At the completion of the command and then connecting to Azure as shown in my previous post we can see the synchronized Identities in Azure and relative properties.
This concludes the overview of the Synchronization Service tool. Next topic for this series will be about Synchronization Rule Editor.