Skapa enklare och effektivare regler för dynamiska grupper i Microsoft Entra-ID
Teamet för Microsoft Entra ID, som är en del av Microsoft Entra, tar emot rapporter om incidenter som rör dynamiska grupper och bearbetningstiden för deras medlemskapsregler. Den här artikeln använder den rapporterade informationen för att presentera de vanligaste metoderna som vårt ingenjörsteam hjälper kunder att förenkla sina medlemskapsregler med. Enklare och effektivare regler resulterar i bättre dynamiska bearbetningstider för grupper. När du skriver medlemskapsregler för dynamiska grupper följer du dessa steg för att säkerställa att dina regler är så effektiva som möjligt.
Minimera användningen av MATCH
Minimera användningen av operatorn match
i regler så mycket som möjligt. Utforska i stället om det är möjligt att använda operatorerna startswith
eller -eq
. Överväg att använda andra egenskaper som gör att du kan skriva regler för att välja de användare som du vill vara i gruppen utan att använda operatorn -match
. Om du till exempel vill ha en regel för gruppen för alla användare vars stad är Lagos, så i stället för att använda regler som:
user.city -match "ago"
user.city -match ".*?ago.*"
Det är bättre att använda regler som:
user.city -startswith "Lag"
Eller bäst av allt:
user.city -eq "Lagos"
Minimera användningen av CONTAINS
Liknar användningen av MATCH. Minimera användningen av operatorn contains
i regler så mycket som möjligt. Utforska i stället om det är möjligt att använda operatorerna startswith
eller -eq
. Användning av CONTAINS kan öka bearbetningstiderna, särskilt för klienter med många dynamiska grupper.
Använda färre OR-operatorer
I regeln identifierar du när den använder olika värden för samma egenskap som är länkad tillsammans med -or
operatorer. Använd i stället operatorn -in
för att gruppera dem i ett enda kriterium för att göra regeln enklare att utvärdera. I stället för att till exempel ha en regel som den här:
(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")
Det är bättre att ha en regel som den här:
user.department -eq "Accounts" -and user.city -in ["Lagos", "Ibadan", "Kaduna", "Abuja", "Port Harcourt"]
Identifiera däremot liknande undervillkor med samma egenskap som inte är lika med olika värden, som är länkade till -and
operatorer. Använd sedan operatorn -notin
för att gruppera dem i ett enda kriterium för att göra regeln enklare att förstå och utvärdera. I stället för att till exempel använda en regel som den här:
(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")
Det är bättre att använda en regel som den här:
user.city -notin ["Lagos", "Ibadan", "Kaduna", "Abuja", "Port Harcourt"]
Undvik redundanta villkor
Se till att du inte använder redundanta villkor i regeln. I stället för att till exempel använda en regel som den här:
user.city -eq "Lagos" or user.city -startswith "Lag"
Det är bättre att använda en regel som den här:
user.city -startswith "Lag"
Nästa steg
Feedback
https://aka.ms/ContentUserFeedback.
Kommer snart: Under hela 2024 kommer vi att fasa ut GitHub-problem som feedbackmekanism för innehåll och ersätta det med ett nytt feedbacksystem. Mer information finns i:Skicka och visa feedback för