Créez des règles plus simples et plus efficaces pour les groupes dynamiques dans Microsoft Entra ID

L’équipe 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. Cet article utilise les informations ainsi fournies pour présenter les méthodes les plus courantes que notre équipe d’ingénierie utilise pour aider les clients à simplifier leurs règles d’appartenance. 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 pour des groupes dynamiques, procédez comme suit pour vous assurer que vos règles sont 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"

Étapes suivantes