Condividi tramite

Creare regole più semplici ed efficienti per i gruppi dinamici in Microsoft Entra ID

  • Articolo

Il team per Microsoft Entra ID, parte di Microsoft Entra, riceve report di eventi imprevisti correlati a gruppi dinamici e il tempo di elaborazione per le regole di appartenenza. Questo articolo usa le informazioni segnalate per presentare i metodi più comuni in base ai quali il team di progettazione aiuta i clienti a semplificare le regole di appartenenza. Regole più semplici ed efficienti generano tempi di elaborazione dei gruppi dinamici migliori. Quando si scrivono regole di appartenenza per i gruppi dinamici, seguire questa procedura per assicurarsi che le regole siano il più efficienti possibile.

Ridurre al minimo l'uso di MATCH

Ridurre al minimo l'utilizzo dell'operatore match nelle regole il più possibile. Esplorare invece se è possibile usare gli startswith operatori o -eq . Prendere in considerazione l'uso di altre proprietà che consentono di scrivere regole per selezionare gli utenti che si desidera trovarsi nel gruppo senza usare l'operatore -match . Ad esempio, se si vuole una regola per il gruppo per tutti gli utenti la cui città è La Città, invece di usare regole come:

  • user.city -match "ago"
  • user.city -match ".*?ago.*"

È preferibile usare regole come:

  • user.city -startswith "Lag"

In alternativa, meglio di tutti:

  • user.city -eq "Lagos"

Ridurre al minimo l'uso di CONTAINS

Simile all'uso di MATCH. Ridurre al minimo l'utilizzo dell'operatore contains nelle regole il più possibile. Esplorare invece se è possibile usare gli startswith operatori o -eq . L'uso di CONTAINS può aumentare i tempi di elaborazione, in particolare per i tenant con molti gruppi dinamici.

Usare meno operatori OR

Nella regola identificare quando usa vari valori per la stessa proprietà collegata con -or gli operatori. Usare invece l'operatore -in per raggrupparli in un singolo criterio per semplificare la valutazione della regola. Ad esempio, anziché avere una regola simile alla seguente:

(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")

È preferibile avere una regola simile alla seguente:

  • user.department -eq "Accounts" -and user.city -in ["Lagos", "Ibadan", "Kaduna", "Abuja", "Port Harcourt"]

Al contrario, identificare sotto criteri simili con la stessa proprietà non uguale a vari valori, collegati con -and operatori. Usare quindi l'operatore -notin per raggrupparli in un singolo criterio per semplificare la comprensione e la valutazione della regola. Ad esempio, anziché usare una regola simile alla seguente:

  • (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")

È preferibile usare una regola simile alla seguente:

  • user.city -notin ["Lagos", "Ibadan", "Kaduna", "Abuja", "Port Harcourt"]

Evitare criteri ridondanti

Assicurarsi di non usare criteri ridondanti nella regola. Ad esempio, anziché usare una regola simile alla seguente:

  • user.city -eq "Lagos" or user.city -startswith "Lag"

È preferibile usare una regola simile alla seguente:

  • user.city -startswith "Lag"

Passaggi successivi