This post is part of a series, for the series contents see:
Nothing fancy in this post, I’ll just following along with a Microsoft article to setup OU filtering when synchronising my on-premise directory up to AAD.
The default install of AAD Connect, which is exactly what I have, simply synchronises everything up to AAD. From a functionality point of view, that’s great, things just work but in reality everyone is going to want to apply some filters to things that have no place, or use, in the cloud:
- Filtering out local service accounts
- Some admin accounts
- Legacy accounts
- Accounts for third-parties to whom your not going to provide any cloud related services
There are also different ways you can filter:
- AD Attributes: You might have a starters and leavers process that tags new users, via an AD attribute, as requiring a cloud directory presence.
- Groups: This is probably more appropriate for filtering out local (by that I mean: on-premise AD) admin groups that have no use in the cloud.
- OU: To me, this is by far the most sensible method. It’s always good practice to have a well organised OU structure anyway, and this method takes advantage of that. Also, in comparison with the other methods it’s nice and transparent. When troubleshooting why an account isn’t synchronising up to AAD you’re much more likely to spot a difference of OU than you are that an account is missing an AD attribute you’d only spot via ADSI Edit.
- Disable the scheduled synchronisation job before you start work
- Make sure you have the correct rights
- Edit the filters (I’ll be using OU filtering)
- Run a full import from Azure AD
- Run a delta synchronisation to see the changes the filters will cause
- Run a full import on the AAD connector to apply those changes to AAD
- Re-enable the scheduled synchronisation job
Step 1 – Disable Scheduled Synchronisation
This is a simple PowerShell one-liner run on the AAD Connect box:
#Disable the sync job Set-ADSyncScheduler -SyncCycleEnabled $False
Step 2 – Permissions
Before you can edit or setup filters, your account will need the rights to do so. This is as simple as making sure it’s a member of the “ADSyncAdmins” local group on the AAD Connect box:
Step 3 – Editing the Filters
First up you need to open up the Synchronisation Service Manager on the AAD Connect box and go to “Connectors”. From there select the local AD connector and then go to its properties.
Click “Configure Directory Partitions” from the left-hand menu and then the “Containers” button. You’ll then be prompted to authenticate using an AD account. That account just needs permissions to read AD so any old account will do, it doesn’t need any special permissions. I used my “irankon” domain admin account:
A menu will then open to allow you to choose the OUs that you want to synch up to AAD. A blue tick on a OU means that all sub-OUs are included and any new ones added in the future will be too. A grey tick means that any new child OU additions in the future will need to be added in manually or they’ll be filtered out of the synchronisation process.
Trying to stick with some kind of tenuous real world link I imagined a scenario whereby I’ve filtered on the following criteria:
- The default “Users” isn’t synchronised as I want some control over whether or not new accounts are synchronised by default.
- Partners and company departments are all synchronised.
- Of the contractors, the maintenance team need access to company systems to log tickets so they are synchronised but the caterers and cleaners have no need to use those systems so they aren’t.
The end picture looks like this:
Notice that if I add a child OU for a new contractor then I’ll need to go in and edit these filters again if I want those accounts to synchronise with AAD.
Step 4 – Run a Full Import
To run a Full Import you need to go back to the Connectors screen from the first part of step 3 and instead of choosing “Properties” select “Run” instead. A menu will pop up from where you can choose “Full Import”:
Step 5 – Run a Delta Synchronisation
Repeat the steps above to run a Delta Synchronisation:
The Microsoft article then gives a couple of handy commands to export a copy of what those deltas between on-premise and AAD are:
#Export changes expected csexport "irankon.onmicrosoft.com - AAD" %temp%\export.xml /f:x #View those changes in csv format CSExportAnalyzer %temp%\export.xml > %temp%\export.csv
The output is something that looks like this:
Not the most readable but I guess if you were really jittery you could power through and use it to double check.
Step 6 – Run a Full Import
Assuming that you’re happy with what the filters are going to do to AAD the next step is to run a full export of the on-premise directory to make those changes a reality:
This time I’m running the import from the perspective of the Azure AD connector (the ones above were run on the on-premise AD connector):
When the job finishes the summary will let you know that there have been some deletions as our Cleaners and Caterers will have been removed from AAD:
I then went and verified this by browsing my AAD users in the management portal. Following the export I could still see my maintenance users as expected:
The catering team, however, were no longer there, they’d been filtered:
Step 7 – Re-enable the Scheduled Synchronisation
With all the changes complete it’s important to remember to re-enable the sych job or you’ll soon start have odd problems. Again, this is just a simple PowerShell one-liner run from the AAD Connect box:
#Re-enable the sync job Set-ADSyncScheduler -SyncCycleEnabled $True