Azure AD Connect: Filtrage par attribute – Attribute filtering

La mise en place d’Azure AD connect est dans la plupart des cas relativement simple dès lors qu’il s’agit de répliquer simplement un ou plusieurs annuaires locaux vers un tenant Office 365. Le programme de paramétrage est relativement bien construit et vous guide graduellement vers une configuration standard. Mais dans plusieurs cas et notamment si vous voulez effectuer des filtres d’objet basés sur des valeurs d’attributs, alors ce même programme de paramétrage va se révéler insuffisant.

Setting up Azure AD connect is in most cases relatively simple when it comes to simply replicating one or more local directories to an Office 365 tenant. The setup program is relatively well constructed and guides you gradually towards a standard configuration. But in many cases, and especially if you want to perform object filters based on attribute values, then this same setup program will prove insufficient.

Dans cet article, je vais vous présenter comment effectuer un filtrage d’objet par attribut. Prenons un cas très simple :

Une entreprise envisage de déployer Office 365 pour une partie de ses utilisateurs dont les comptes sont répartis dans plusieurs dizaines d’unités Organisation de son Active Directory locale. (Un grand classique). Au sein de ses Unités Organisationnelles, certains utilisateurs doivent être synchronisés vers 0365 d’autres non. Elle envisage de déployer la solution Intune et donc à la nécessité de synchroniser une partie de ses postes de travail. Pour répondre à cela, il existe 3 solutions possibles.

• Le filtrage par Unités Organisationnelles : Une des solutions possibles serait de déplacer ces utilisateurs de façon à créer des OU spécifiques pour les comptes devant se synchroniser. C’est une solution jouable, mais qui peut avoir un impact important en raison de la présence au sein de ses OU de stratégies de groupes (GPO). Autre inconvénient, cela reviendrait à changer l’organisation des Unités Organisationnel de l’entreprise et vous contraindrait à les sélectionner une à une dans la configuration Azure AD. De plus, en cas de nouvelle Unité Organisationnelle, il faudra pensez à relancer le programme de paramétrage d’Azure AD pour prendre en compte ce changement. Si un utilisateur est déplacé par erreur dans une OU non sélectionnée, alors son compte synchronisé sera purement supprimé par Azure AD connect. Vous l’aurez compris ce n’est pas mon option favorite, car en maintenance opérationnelle, elle induit des complexités supplémentaires liées notamment aux Stratégies de groupe et risque d’avoir un impact important sur une structure d’OU déjà existante.
• L’appartenance à un groupe : Il est possible dans Azure AD d’utiliser le critère d’appartenance à un groupe pour synchroniser des objets. C’est tout à fait possible, mais pour moi non souhaitable, pour la bonne et simple raison que ce groupe va prendre une importance considérable. Si ce dernier venait à être supprimé, l’impact sur l’ensemble des utilisateurs synchronisés serait très important. Azure AD ne trouvant pas ce groupe et si vous décidez de le recréer il faudra que ses membres soient positionnés à l’identique. Si vous êtes une T.P. E et que vous avez 20 personnes c’est faisable, si vous synchronisez des milliers de comptes, je vous laisse imaginer le problème.
• Filtrage par attributs : Le filtrage par attribut consiste à convenir d’une valeur (Exemple : syncaad) que vous allez positionner sur tous les objets que vous envisagez de synchroniser dans l’Azure AD, et ce quelques soit leur emplacement géographique dans vos annuaires Active Directory locaux. Prenons par exemple le champs extendedAttribut14 qui est présent pour les objets utilisateur mais aussi Ordinateur. L’avantage de cette solution est que vous pourrez déplacer ou bon vous semble vos objets, ils resteront synchronisés tant que cette valeur reste présente dans l’attribut que vous avez retenu. Au sein d’une même OU vous pourrez avoir des comptes utilisateurs ou Ordinateurs qui pour certains se synchroniserons pour d’autre non. Votre structure Active Directory reste inchangée et vous n’introduisez pas de risques supplémentaires comme le risque des GPO ou le fait de disposer d’un seul et unique groupe. C’est, je pense la meilleure solution, car de très loin, la moins intrusive.

Reste maintenant à la mettre en place avec Azure AD Connect dont le programme de paramétrage n’a pas été conçu pour proposer ce filtrage d’attribut. Dommage.

Si vous envisager de faire ça, vous allez devoir utiliser l’outil d’Azure AD connect « Synchronization Rules editor » qui permet de modifier manuellement les règles de synchronisation. En fait, l’outils de paramétrage d’Azure Ad connect qui vous guide dans la configuration va générer un certain nombre de règles que vous allez trouver dans cet éditeur. Chaque règle générée peut être soit active ou désactivée. Comme nous envisageons de les modifier et que nous ne voulons pas tout casser, il est possible de dupliquer la règle initiale que nous voulons modifier, modifier la copie, désactiver la règle originale puis activer notre copie. Avec cette méthode, le retour à la configuration d’origine sera garanti. C’est d’ailleurs ce que va vous proposer systématiquement l’outils dès lors que tentez d’éditer une régle.

In this article, I will show you how to perform object filtering by attribute. Let’s take a very simple case:

A company is considering deploying Office 365 for a portion of its users whose accounts are spread across several dozen Organizational units in its local Active Directory. (A great classic). Within its Organizational Units, some users need to be synchronized to 0365 and others not. The company is considering deploying the Intune solution and therefore needs to synchronize some of its workstations. To answer this, there are 3 possible solutions.

• Filtering by Organizational Units: One of the possible solutions would be to move these users in order to create specific OUs for the accounts that need to be synchronized. This is a feasible solution, but it can have a significant impact because of the presence of group policies (GPOs) within these OUs. Another disadvantage is that it would mean changing the organization of the company’s Organizational Units and would force you to select them one by one in the Azure AD configuration. Moreover, in case of a new Organizational Unit, you will have to remember to restart the Azure AD setup program to take this change into account. If a user is mistakenly moved to a non-selected OU, then his synchronized account will be purely deleted by Azure AD connect. As you can see, this is not my favorite option, because in operational maintenance, it leads to additional complexities related to Group Policies and may have a significant impact on an existing OU structure.
  
• Group membership: It is possible in Azure AD to use the group membership criterion to synchronize objects. This is possible, but I don’t think it’s a good idea, for the simple reason that this group will become very important. If this group were to be deleted, the impact on all synchronized users would be very important. Azure AD does not find this group and if you decide to recreate it, its members will have to be positioned identically. If you are a T.P. E and you have 20 people it is feasible, if you synchronize thousands of accounts, I let you imagine the problem.
  
• Attribute filtering: Attribute filtering consists of agreeing on a value (Example: syncaad) that you will set on all the objects that you plan to synchronize in Azure AD, regardless of their geographical location in your local Active Directory. Let’s take for example the extendedAttribute14 field which is present for both user and computer objects. The advantage of this solution is that you can move your objects wherever you want, they will remain synchronized as long as this value is present in the attribute you have chosen. Within the same OU you can have user or computer accounts that for some will synchronize for others not. Your Active Directory structure remains unchanged and you don’t introduce additional risks like the risk of GPOs or the fact of having a single group. This is, I think, the best solution, because it is by far the least intrusive.
  

Now you have to implement it with Azure AD Connect whose setup program was not designed to offer this attribute filtering. Too bad.
If you want to do this, you will have to use the Azure AD Connect tool « Synchronization Rules editor » which allows you to manually modify the synchronization rules. In fact, the Azure Ad connect setup tool that guides you through the configuration will generate a number of rules that you will find in this editor. Each rule generated can be either enabled or disabled. As we plan to modify them and we don’t want to break everything, it is possible to duplicate the initial rule we want to modify, modify the copy, deactivate the original rule and then activate our copy. With this method, the return to the original configuration is guaranteed. This is what the tool will systematically suggest when you try to edit a rule.

Dans tous les cas, je vous invite à vous entrainer sur un environnement de test pour être certain de la construction de vos règles de synchronisation et de leurs impacts. Surtout si vous avez déjà des utilisateurs synchronisés qui utilisent des ressources 0365. Les règles que vous devez modifier sont les suivantes. Notez que chaque règle a un ordre de préséance c’est-à-dire que dans la configuration Azure AD connect, l’ordre d’exécution des règles à une importance. Aussi, pour vous faciliter la vie, et surtout pour vous éviter de chercher, voici la configuration que vous devrez mettre en place pour filtrer vos utilisateurs via un attribut ExtendedAttribute14 dont la valeur devra comporter la chaine de caractère « syncaad ».

In any case, I invite you to practice on a test environment to be sure of the construction of your synchronization rules and their impacts. Especially if you already have synchronized users who use 0365 resources. The rules you need to modify are the following. Note that each rule has an order of precedence i.e. in the Azure AD connect configuration, the order of execution of the rules has an importance. Also, to make your life easier, and especially to save you from searching, here is the configuration you need to put in place to filter your users via an ExtendedAttribute14 whose value must contain the string « syncaad ».

Filtrage pour les objets utilisateurs ; Filtering for user objects

Dans l’exemple suivant j’ai modifié la règle « In from AD – User Join » en la clonant (In from AD – User Join – Cloned – 9/23/2021 2:34:18 PM) et le l’ai positionné avec une ‘precedence’ de 1 . J’ai aussi par la suite désactivé la règle d’origine
In the following example I modified the rule « In from AD – User Join » by cloning it (In from AD – User Join – Cloned – 9/23/2021 2:34:18 PM) and set it with a precedence of 1. I also later deactivated the original rule

Figure 1 : désactivation de la règle d’origine

Ensuite j’ai modifié la règle clonée comme ceci pour effectuer le filtrage / Then I modified the cloned rule like this to perform the filtering

Ensuite sur la partie Scoping filter il suffit d’ajouter une close comme celle-ci. / Then on the Scoping filter part you just have to add a close like this one.

Sur Join rule ne changez rien. La configuration doit ressembler à cela / Then on the Scoping filter part you just have to add a close like this one.

Idem pour transformation cela doit ressembler ca la figure ci-dessous. Aucun changement à effectuer / Ditto for transformation it should look like the figure below. No changes to be made

Une fois validé voici a qui cela doit ressembler . notez que la troisiéme régle en partant du haut est celle d’origine et est désactivée. / Once validated here is what it should look like. Note that the third rule from the top is the original and is disabled.

Filtrage pour les objet Ordinateurs / Filtering for Computer objects

Pour les objets de type ordinateur le principe est identique. J’ai désactivé la règle « In from AD – Computer Join » et je l’ai cloné en « In from AD – Computer Join -extendedAttribut14 =syncaad »/
For computer objects the principle is the same. I deactivated the rule « In from AD – Computer Join » and I cloned it into « In from AD – Computer Join -extendedAttribut14 =syncaad ».

Figure 2 : désactivation de la règle d’origine

J’ai ensuite modifié la règle clonée comme ceci / I then modified the cloned rule like this

Ne changez rien aux valeurs des écrans « Join Rules » et « transformation ». Une fois terminé, il ne vous reste plus qu’à modifier la valeur de l’attribut (extensionattribute14 ici), de vos objets Ordinateurs et utilisateurs pour vérifier que seul ces objets sont synchronisés dans Azure AD.
Do not change anything in the « Join Rules » and « transformation » screens. Once finished, you just have to modify the attribute value (extensionattribute14 here) of your Computer and User objects to verify that only these objects are synchronized in Azure AD.

Encore une fois faite un essai dans un premier temps sur un environnement de test avant de positionner cela en production / Again, test this first on a test environment before putting it into production

Cordialement
Laurent TERUIN