Creación de reglas más sencillas y eficaces para grupos de pertenencia dinámica en Microsoft Entra ID
El equipo de ingeniería de Microsoft Entra ID, parte de Microsoft Entra, recibe informes de incidentes relacionados con grupos de pertenencia dinámica y el tiempo de procesamiento de sus reglas de pertenencia. La información notificada se presenta en este artículo. En este artículo también se describen los métodos más comunes con los que Microsoft ayuda a los clientes a simplificar sus reglas para los grupos de pertenencia dinámica. 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ámica, sigue los pasos de este artículo para asegurarte 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 de pertenencia dinámica.
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"