Identitetssynkronisering och duplicerad attributåterhämtning
Resiliency för duplicerade attribut är en funktion i Microsoft Entra-ID som eliminerar friktion som orsakas av konflikter med UserPrincipalName och SMTP ProxyAddress när du kör något av Microsofts synkroniseringsverktyg.
Dessa två attribut måste vanligtvis vara unika för alla användar-, grupp- eller kontaktobjekt i en viss Microsoft Entra-klientorganisation.
Kommentar
Endast användare kan ha UPN.
Det nya beteendet som den här funktionen aktiverar finns i molndelen av synkroniseringspipelinen, därför är den klientagnostisk och relevant för alla Microsoft-synkroniseringsprodukter, inklusive Microsoft Entra Anslut, DirSync och MIM + Anslut or. Den allmänna termen "synkroniseringsklient" används i det här dokumentet för att representera någon av dessa produkter.
Aktuellt beteende
Om det görs ett försök att etablera ett nytt objekt med ett UPN- eller ProxyAddress-värde som bryter mot denna unikhetsbegränsning blockerar Microsoft Entra-ID objektet från att skapas. På samma sätt misslyckas uppdateringen om ett objekt uppdateras med ett icke-unikt UPN eller ProxyAddress. Etableringsförsöket eller uppdateringen görs på nytt av synkroniseringsklienten vid varje exportcykel och fortsätter att misslyckas tills konflikten har lösts. Ett e-postmeddelande om felrapport genereras vid varje försök och ett fel loggas av synkroniseringsklienten.
Beteende med återhämtning av duplicerade attribut
I stället för att helt misslyckas med att etablera eller uppdatera ett objekt med ett duplicerat attribut " placerar Microsoft Entra-ID det duplicerade attributet i karantän, vilket skulle strida mot unikhetsbegränsningen. Om det här attributet krävs för etablering, till exempel UserPrincipalName, tilldelar tjänsten ett platshållarvärde. Formatet för dessa temporära värden är
<OriginalPrefix>+<4DigitNumber>@<InitialTenantDomain.onmicrosoft.com>.
Attributåterhämtningsprocessen hanterar endast UPN- och SMTP ProxyAddress-värden .
Om attributet inte krävs, till exempel en ProxyAddress, placerar Microsoft Entra-ID helt enkelt konfliktattributet i karantän och fortsätter med att objektet skapas eller uppdateras.
Vid kvartering av attributet skickas information om konflikten i samma e-post för felrapport som används i det gamla beteendet. Den här informationen visas dock bara i felrapporten en gång, när karantänen inträffar fortsätter den inte att loggas i framtida e-postmeddelanden. Eftersom exporten för det här objektet har slutförts loggar inte synkroniseringsklienten något fel och försöker inte skapa/uppdatera igen vid efterföljande synkroniseringscykler.
För att stödja det här beteendet har ett nytt attribut lagts till i objektklasserna Användare, Grupp och Kontakt:
DirSyncProvisioningErrors
Det här är ett attribut med flera värden som används för att lagra de attribut som står i konflikt med unikhetsbegränsningen om de läggs till normalt. En bakgrundstimeraktivitet har aktiverats i Microsoft Entra-ID som körs varje timme för att söka efter dubbletter av attributkonflikter som har lösts och automatiskt tar bort de aktuella attributen från karantänen.
Aktivera återhämtning av duplicerade attribut
Dubblettattributåterhämtning är det nya standardbeteendet för alla Microsoft Entra-klienter. Den är aktiverad som standard för alla klienter som aktiverade synkronisering för första gången den 22 augusti 2016 eller senare. Klienter som har aktiverat synkronisering före det här datumet har funktionen aktiverad i batchar. Den här distributionen börjar i september 2016 och ett e-postmeddelande skickas till varje klientorganisations tekniska meddelandekontakt med det specifika datum då funktionen ska aktiveras.
Kommentar
När dubblettattributåterhämtning har aktiverats kan det inte inaktiveras.
Om du vill kontrollera om funktionen är aktiverad för din klientorganisation kan du göra det genom att ladda ned den senaste versionen av Azure Active Directory PowerShell-modulen och köra:
Get-MsolDirSyncFeatures -Feature DuplicateUPNResiliency
Get-MsolDirSyncFeatures -Feature DuplicateProxyAddressResiliency
Kommentar
Du kan inte längre använda cmdleten Set-MsolDirSyncFeature för att proaktivt aktivera funktionen Duplicera attributåterhämtning innan den aktiveras för din klientorganisation. För att kunna testa funktionen måste du skapa en ny Microsoft Entra-klientorganisation.
Kommentar
Azure AD- och MSOnline PowerShell-moduler är inaktuella från och med den 30 mars 2024. Mer information finns i utfasningsuppdateringen. Efter det här datumet är stödet för dessa moduler begränsat till migreringshjälp till Microsoft Graph PowerShell SDK och säkerhetskorrigeringar. De inaktuella modulerna fortsätter att fungera till och med mars 30 2025.
Vi rekommenderar att du migrerar till Microsoft Graph PowerShell för att interagera med Microsoft Entra-ID (tidigare Azure AD). Vanliga migreringsfrågor finns i Vanliga frågor och svar om migrering. Obs! Versioner 1.0.x av MSOnline kan uppleva störningar efter den 30 juni 2024.
Identifiera objekt med DirSyncProvisioningErrors
Det finns för närvarande två metoder för att identifiera objekt som har dessa fel på grund av duplicerade egenskapskonflikter, Azure Active Directory PowerShell och Administrationscenter för Microsoft 365. Det finns planer på att utöka till ytterligare portalbaserad rapportering i framtiden.
Azure Active Directory PowerShell
Följande gäller för PowerShell-cmdletarna i det här avsnittet:
- Alla följande cmdletar är skiftlägeskänsliga.
- Egenskapen –ErrorCategoryConflict måste alltid inkluderas. Det finns för närvarande inga andra typer av ErrorCategory, men detta kan komma att utökas i framtiden.
Börja med att köra Anslut-MsolService och ange autentiseringsuppgifter för en klientadministratör.
Använd sedan följande cmdletar och operatorer för att visa fel på olika sätt:
- Se alla
- Efter egenskapstyp
- Efter motstridigt värde
- Använda en strängsökning
- Sorted
- I en begränsad kvantitet eller alla
Visa alla
När du är ansluten visas en allmän lista över attributetableringsfel i klientkörningen:
Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict
Detta ger ett resultat som liknar följande:
Efter egenskapstyp
Om du vill se fel efter egenskapstyp lägger du till flaggan -PropertyName med argumentet UserPrincipalName eller ProxyAddresses :
Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict -PropertyName UserPrincipalName
Eller
Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict -PropertyName ProxyAddresses
Genom motstridiga värden
Om du vill se fel som rör en specifik egenskap lägger du till flaggan -PropertyValue (-PropertyName måste också användas när du lägger till den här flaggan):
Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict -PropertyValue User@domain.com -PropertyName UserPrincipalName
Använda en strängsökning
Om du vill göra en bred strängsökning använder du flaggan -SearchString . Detta kan användas oberoende av alla ovanstående flaggor, med undantag för -ErrorCategory PropertyConflict, som alltid krävs:
Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict -SearchString User
I en begränsad mängd eller alla
- MaxResults <Int> kan användas för att begränsa frågan till ett visst antal värden.
- Alla kan användas för att säkerställa att alla resultat hämtas om det finns ett stort antal fel.
Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict -MaxResults 5
Microsoft 365 administrationscenter
Du kan visa katalogsynkroniseringsfel i Administrationscenter för Microsoft 365. Rapporten i Administrationscenter för Microsoft 365 visar endast användarobjekt som har dessa fel. Den visar inte information om konflikter mellan grupper och kontakter.
Anvisningar om hur du visar katalogsynkroniseringsfel i Administrationscenter för Microsoft 365 finns i Identifiera katalogsynkroniseringsfel i Microsoft 365.
Felrapport för identitetssynkronisering
När ett objekt med en dubblettattributkonflikt hanteras med det här nya beteendet inkluderas ett meddelande i e-postmeddelandet för standardfelrapporten för identitetssynkronisering som skickas till den tekniska meddelandekontakten för klientorganisationen. Det finns dock en viktig förändring i det här beteendet. Tidigare skulle information om en dubblettattributkonflikt inkluderas i varje efterföljande felrapport tills konflikten löstes. Med det här nya beteendet visas felmeddelandet för en viss konflikt bara en gång när det motstridiga attributet sätts i karantän.
Här är ett exempel på hur e-postmeddelandet ser ut för en ProxyAddress-konflikt:
Lösa konflikter
Felsökningsstrategi och lösningstaktik för dessa fel bör inte skilja sig från hur dubblettattributfel hanterades tidigare. Den enda skillnaden är att den tidsinställda aktiviteten sveper genom klientorganisationen på tjänstsidan för att automatiskt lägga till attributet i fråga till rätt objekt när konflikten har lösts.
I följande artikel beskrivs olika felsöknings- och lösningsstrategier: Duplicerade eller ogiltiga attribut förhindrar katalogsynkronisering i Office 365.
Kända problem
Inget av dessa kända problem orsakar dataförlust eller tjänstförsämring. Flera av dem är estetiska, andra orsakar standardfel med "pre-resiliency" duplicerade attribut som genereras i stället för att quarantining konfliktattributet, och en annan orsakar vissa fel som kräver extra manuell korrigering.
Kärnbeteende:
Objekt med specifika attributkonfigurationer fortsätter att ta emot exportfel i stället för de dubblettattribut som sätts i karantän.
Till exempel:a. Ny användare skapas i AD med upn Joe@contoso.com och ProxyAddress smtp:Joe@contoso.com
b. Egenskaperna för det här objektet står i konflikt med en befintlig grupp, där ProxyAddress är SMTP:Joe@contoso.com.
c. Vid export utlöses ett ProxyAddress-konfliktfel i stället för att konfliktattributen sätts i karantän. Åtgärden görs på nytt vid varje efterföljande synkroniseringscykel, som det skulle ha varit innan återhämtningsfunktionen aktiverades.
Om två grupper skapas lokalt med samma SMTP-adress kan den ena inte etableras vid det första försöket med ett standard duplicerat ProxyAddress-fel . Dubblettvärdet är dock korrekt i karantän vid nästa synkroniseringscykel.
Office Portal-rapport:
Det detaljerade felmeddelandet för två objekt i en UPN-konfliktuppsättning är detsamma. Detta indikerar att de båda har fått sitt UPN ändrat/satt i karantän, när i själva verket bara en av dem hade några data ändrades.
Det detaljerade felmeddelandet för en UPN-konflikt visar fel displayName för en användare som har fått sitt UPN ändrat/satt i karantän. Till exempel:
a. Användare A synkroniseras först med UPN = User@contoso.com.
b. Användare B försöker synkroniseras härnäst med UPN = User@contoso.com.
c. Användaren B:s UPN ändras till User1234@contoso.onmicrosoft.com och User@contoso.com läggs till i DirSyncProvisioningErrors.
d. Felmeddelandet för användare B bör indikera att användare A redan har User@contoso.com som ett UPN, men det visar användar-B:s eget displayName.
Felrapport för identitetssynkronisering:
Länken för steg om hur du löser problemet är felaktig:
Det bör peka på https://aka.ms/duplicateattributeresiliency.