Really? I need to shorten an already short post? Well, you're welcome Generation-Y.
Azure AD Connect, like previous version of the directory synchronisation application, is able filter users, groups or contacts that are synchronised to Azure AD / Office 365 through a number of methods. The Microsoft Azure documentation page…
…outlines this and explains the various methods available to filter out objects. The various filter options include:
In numerous customer sites that I've worked with, or even deployed AADConnect, a handy filter was also to create a manual filter based on a CustomAttribute or CustomExtensionAttribute. This process usually went along the lines of: if the attribute contained the word or phrase like “DoNotSync”, it would filter this user out. This is most certainly handy when you have multiple forests synced with Azure AD and want to filter out a user that has a secondary account in your second forest. Often required when group based or organisational unit filtering is hard to maintain due to large data object counts.
A few months back though, an update to Azure AD Connect added this user based filter functionality “out of the box”. I came about this when working on a clients site who was using the attribute “adminDescription” for a custom purpose. This customer upgraded Azure AD Connect and found a fault with their custom rule. So, what happened?
AADConnect now has an INBOUND rule that when the attribute “adminDescription” in Active Directory has a value set with a prefix of User_ or Group_, it will filter out and not sync that into the metaverse.
An example to use would be: “User_DoNotSync” or “Group_DoNotSync”.
Sidebar - there's two types of AADConnect rules: Inbound and Outbound. Inbound rules sync data from Active Directory to the metaverse and Outbound rules sync data from the metaverse to Azure AD.
It's not every project that I work with the same technology. Part of the charm and positive of working at Kloud is that there's opportunity to work across multiple public clouds like Azure, Office 365 or AWS. I say it's been a good day if you learn something new that day. I firmly believe in always learning or trying to learn. Always! Never stop! So, coming across this was a great find and a trivial piece of luck having come across the client and project I happen to be working on. Timing is everything.
I would recommend putting into place steps to move away as much as possible from custom filters, used for user or group filtering, and leverage the now built in filter via attribute adminDescription.
The more standard the deployment, the easier it is to manage, monitor, upgrade and/or maintain moving forward.
Follow or start a discussion for this blog (The new Azure AD Connect built in user filter: adminDescription) on Twitter. If you're after something more in depth, or want to ask me an expanded question: raise an issue in my open GitHub AMA repo.