Créer des règles d’appartenance dynamique aux groupes plus simples et plus efficaces dans Microsoft Entra ID
L’équipe d’ingénierie de Microsoft Entra ID, qui fait partie de Microsoft Entra, reçoit des rapports d’incidents liés aux groupes dynamiques et au temps de traitement de leurs règles d’appartenance. Les informations signalées sont présentées dans cet article. Cet article traite également des méthodes les plus courantes par lesquelles Microsoft aide ses clients à simplifier leurs règles d’appartenance dynamique aux groupes. Des règles plus simples et plus efficaces entraînent une meilleure durée de traitement des groupes dynamiques.
Lorsque vous écrivez des règles d’appartenance dynamique aux groupes, procédez comme suit pour vous assurer de créer des règles aussi efficaces que possible.
Réduisez l’utilisation de MATCH
Réduisez l’utilisation de l’opérateur match dans les règles autant que possible. Au lieu de cela, explorez s'il est possible d'utiliser les opérateurs startswith, ou -eq. Envisagez d’utiliser d’autres propriétés qui vous permettent d’écrire des règles pour sélectionner les utilisateurs que vous souhaitez avoir dans le groupe sans utiliser l’opérateur -match. Par exemple, si vous souhaitez une règle pour le groupe pour tous les utilisateurs dont la ville est Lagos, au lieu d’utiliser des règles comme :
user.city -match "ago"user.city -match ".*?ago.*"
Il est préférable d’utiliser des règles comme :
user.city -startswith "Lag"
Ou, le meilleur de tous :
user.city -eq "Lagos"
Réduire l’utilisation de CONTAINS
Semblable à l’utilisation de MATCH. Réduisez l’utilisation de l’opérateur contains dans les règles autant que possible. Au lieu de cela, explorez s'il est possible d'utiliser les opérateurs startswith, ou -eq. L’utilisation de CONTAINS peut accroître les temps de traitement, en particulier pour les locataires avec de nombreux groupes dynamiques.
Utiliser moins d’opérateurs OR
Dans votre règle, identifiez quand elle utilise différentes valeurs pour la même propriété liée aux opérateurs -or. Au lieu de cela, utilisez l’opérateur -in pour les regrouper en un seul critère pour faciliter l’évaluation de la règle. Par exemple, au lieu d’avoir une règle comme celle-ci :
(user.department -eq "Accounts" -and user.city -eq "Lagos") -or
(user.department -eq "Accounts" -and user.city -eq "Ibadan") -or
(user.department -eq "Accounts" -and user.city -eq "Kaduna") -or
(user.department -eq "Accounts" -and user.city -eq "Abuja") -or
(user.department -eq "Accounts" -and user.city -eq "Port Harcourt")
Il est préférable d’avoir une règle comme celle-ci :
user.department -eq "Accounts" -and user.city -in ["Lagos", "Ibadan", "Kaduna", "Abuja", "Port Harcourt"]
À l’inverse, identifiez les sous-critères similaires avec la même propriété qui n’est pas égale à diverses valeurs, liées aux opérateurs -and. Utilisez ensuite l’opérateur -notin pour les regrouper dans un critère unique pour faciliter la compréhension et l’évaluation de la règle. Par exemple, au lieu d’avoir une règle comme celle-ci :
(user.city -ne "Lagos") -and (user.city -ne "Ibadan") -and (user.city -ne "Kaduna") -and (user.city -ne "Abuja") -and (user.city -ne "Port Harcourt")
Il est préférable d’avoir une règle comme celle-ci :
user.city -notin ["Lagos", "Ibadan", "Kaduna", "Abuja", "Port Harcourt"]
Évitez les critères redondants
Vérifiez que vous n’utilisez pas de critères redondants dans votre règle. Par exemple, au lieu d’avoir une règle comme celle-ci :
user.city -eq "Lagos" or user.city -startswith "Lag"
Il est préférable d’avoir une règle comme celle-ci :
user.city -startswith "Lag"