Creare regole di appartenenza dinamica per i gruppi più semplici ed efficienti in Microsoft Entra ID
Il team di progettazione di Microsoft Entra ID, parte di Microsoft Entra, riceve segnalazioni di eventi imprevisti correlati ai gruppi di appartenenza dinamica e al tempo di elaborazione per le relative regole di appartenenza. Le informazioni segnalate sono presentate in questo articolo. Questo articolo illustra anche i metodi più comuni in base ai quali Microsoft consente ai clienti di semplificare le regole per i gruppi di appartenenza dinamica. Regole più semplici ed efficienti generano tempi di elaborazione dei gruppi dinamici migliori.
Quando si scrivono regole di appartenenza per i gruppi di appartenenza dinamica, seguire la procedura descritta in questo articolo per assicurarsi di creare tali regole nel modo più efficiente possibile.
Ridurre al minimo l'uso di MATCH
Ridurre il più possibile al minimo l'utilizzo dell'operatore match nelle regole. Esplorare invece se è possibile usare gli operatori startswith o -eq. Prendere in considerazione l'uso di altre proprietà che consentono di scrivere regole per selezionare gli utenti che si desidera includere nel gruppo senza usare l'operatore -match. Ad esempio, se si vuole una regola per il gruppo per tutti gli utenti la cui città è Lagos, invece di usare regole come:
user.city -match "ago"user.city -match ".*?ago.*"
È preferibile usare regole come:
user.city -startswith "Lag"
In alternativa, l'opzione migliore è:
user.city -eq "Lagos"
Ridurre al minimo l'utilizzo di CONTAINS
Simile all'uso di MATCH. Ridurre il più possibile al minimo l'utilizzo dell'operatore contains nelle regole. Esplorare invece se è possibile usare gli operatori startswith o -eq. L'uso di CONTAINS può aumentare i tempi di elaborazione, in particolare per i tenant con molti gruppi di appartenenza dinamica.
Usare meno operatori OR
Nella regola creata, identificare quando usa vari valori per la stessa proprietà collegata con gli operatori -or. Usare invece l'operatore -in per raggrupparli in un singolo criterio per semplificare la valutazione della regola. Ad esempio, anziché avere una regola come:
(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 come:
user.department -eq "Accounts" -and user.city -in ["Lagos", "Ibadan", "Kaduna", "Abuja", "Port Harcourt"]
Al contrario, identifica sottocriteri simili con la stessa proprietà che non è uguale a vari valori, collegati con operatori -and. Usare quindi l'operatore -notin per raggrupparli in un unico criterio per semplificare la comprensione e la valutazione della regola. Ad esempio, invece di usare una regola come:
(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")
È meglio usare una regola come la seguente:
user.city -notin ["Lagos", "Ibadan", "Kaduna", "Abuja", "Port Harcourt"]
Evitare criteri ridondanti
Assicurarsi di non usare criteri ridondanti nella regola. Ad esempio, invece di usare una regola come:
user.city -eq "Lagos" or user.city -startswith "Lag"
È meglio usare una regola come la seguente:
user.city -startswith "Lag"