Creación de reglas más sencillas y eficaces para grupos dinámicos en Microsoft Entra ID
El equipo de Microsoft Entra ID, parte de Microsoft Entra, recibe informes de incidentes relacionados con grupos dinámicos y el tiempo de procesamiento de sus reglas de pertenencia. En este artículo se usa esa información notificada para presentar los métodos más comunes por los que nuestro equipo de ingeniería ayuda a los clientes a simplificar sus reglas de pertenencia. Tener unas reglas más sencillas y eficaces dan lugar a mejores tiempos de procesamiento de grupos dinámicos. Al escribir reglas de pertenencia para grupos dinámicos, siga estos pasos para asegurarse de que las reglas sean lo más eficaces posible.
Minimizar el uso de MATCH
Minimice el uso del operador match en las reglas tanto como sea posible. En su lugar, comprueba si es posible usar los operadores startswith o -eq. Considere la posibilidad de usar otras propiedades que le permitan escribir reglas para seleccionar los usuarios que quiera que estén en el grupo sin usar el operador -match. Por ejemplo, si quiere obtener una regla para el grupo que abarque a todos los usuarios de la ciudad de Lagos, entonces, lugar de usar reglas como:
user.city -match "ago"user.city -match ".*?ago.*"
Es mejor usar reglas como:
user.city -startswith "Lag"
O bien, lo mejor de todo:
user.city -eq "Lagos"
Minimizar el uso de CONTAINS
Similar al uso de MATCH. Minimice el uso del operador contains en las reglas tanto como sea posible. En su lugar, comprueba si es posible usar los operadores startswith o -eq. El uso de CONTAINS puede aumentar los tiempos de procesamiento, especialmente para los inquilinos con muchos grupos dinámicos.
Use menos operadores OR
En la regla, identifique cuándo usa varios valores para la misma propiedad vinculada junto con operadores -or. En su lugar, use el operador -in para agruparlos en un único criterio que facilite la evaluación de la regla. Por ejemplo, en lugar de tener una regla como esta:
(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")
Es mejor tener una regla como esta:
user.department -eq "Accounts" -and user.city -in ["Lagos", "Ibadan", "Kaduna", "Abuja", "Port Harcourt"]
Por el contrario, identifique subcriterios similares con la misma propiedad, pero que no sea igual a varios valores que están vinculados con operadores -and. En su lugar, use el operador -notin para agruparlos en un único criterio que facilite la comprensión y la evaluación de la regla. Por ejemplo, en lugar de usar una regla como esta:
(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")
Es mejor usar una regla como esta:
user.city -notin ["Lagos", "Ibadan", "Kaduna", "Abuja", "Port Harcourt"]
Evite criterios redundantes
Asegúrese de que no usa criterios redundantes en la regla. Por ejemplo, en lugar de usar una regla como esta:
user.city -eq "Lagos" or user.city -startswith "Lag"
Es mejor usar una regla como esta:
user.city -startswith "Lag"