Identitásszinkronizálás és ismétlődő attribútumok rugalmassága

A Duplikált attribútum rugalmassága a Microsoft Entra-azonosító egyik funkciója, amely kiküszöböli a UserPrincipalName és SMTP ProxyAddress ütközések okozta súrlódást a Microsoft egyik szinkronizálási eszközének futtatásakor.

Ennek a két attribútumnak általában egyedinek kell lennie egy adott Microsoft Entra-bérlő összes felhasználói, csoport- vagy partnerobjektumában .

Feljegyzés

Csak a felhasználók rendelkezhetnek UPN-ekkel.

A funkció által lehetővé tévő új viselkedés a szinkronizálási folyamat felhőbeli részében található, ezért ügyfél-agnosztikus és releváns bármely Microsoft-szinkronizálási termékhez, beleértve a Microsoft Entra Csatlakozás, a DirSync és a MIM + Csatlakozás or szolgáltatást. A dokumentumban az általános "szinkronizálási ügyfél" kifejezés jelenik meg ezen termékek bármelyikének ábrázolására.

Aktuális viselkedés

Ha egy új objektumot próbál kiépíteni egy UPN vagy ProxyAddress értékkel, amely megsérti ezt az egyediségi korlátozást, a Microsoft Entra ID letiltja az objektum létrehozását. Hasonlóképpen, ha egy objektum nem egyedi UPN vagy ProxyAddress szolgáltatással frissül, a frissítés sikertelen lesz. A kiépítési kísérletet vagy frissítést a szinkronizálási ügyfél minden exportálási cikluskor újra megpróbálja végrehajtani, és az ütközés feloldásáig továbbra is sikertelen marad. Minden kísérletkor hibajelentési e-mail jön létre, és a szinkronizálási ügyfél naplózza a hibát.

Ismétlődő attribútum rugalmasságával rendelkező viselkedés

Ahelyett, hogy egy objektumot nem sikerült teljesen kiépíteni vagy frissíteni duplikált attribútummal, a Microsoft Entra-azonosító "karanténba helyezi" az ismétlődő attribútumot, amely megsértené az egyediség korlátozását. Ha ez az attribútum szükséges a kiépítéshez (például UserPrincipalName), a szolgáltatás helyőrző értéket rendel hozzá. Ezeknek az ideiglenes értékeknek a formátuma a következő:
<OriginalPrefix>+<4DigitNumber>@<InitialTenantDomain.onmicrosoft.com>.

Az attribútum rugalmassági folyamata csak az UPN- és SMTP ProxyAddress-értékeket kezeli.

Ha az attribútumra nincs szükség, például ProxyAddressre, a Microsoft Entra ID egyszerűen karanténba helyezi az ütközési attribútumot, és folytatja az objektum létrehozását vagy frissítését.

Az attribútum quarantinálása után az ütközésre vonatkozó információk ugyanabban a hibajelentési e-mailben lesznek elküldve, amelyet a régi viselkedésben használtak. Ez az információ azonban csak egyszer jelenik meg a hibajelentésben, a karanténba helyezéskor azonban nem lesz naplózva a jövőbeni e-mailekben. Mivel az objektum exportálása sikeres volt, a szinkronizálási ügyfél nem naplóz hibát, és nem próbálkozik újra a létrehozási/frissítési művelettel a későbbi szinkronizálási ciklusok során.

Ennek a viselkedésnek a támogatásához új attribútum lett hozzáadva a Felhasználó, a Csoport és a Kapcsolattartó objektumosztályhoz:
DirSyncProvisioningErrors

Ez egy többértékű attribútum, amely azokat az ütköző attribútumokat tárolja, amelyek normál hozzáadása esetén megsértik az egyediségi kényszert. A Microsoft Entra-azonosítóban engedélyezve van egy háttér időzítőfeladat, amely óránként fut a feloldott ismétlődő attribútumütközések kereséséhez, és automatikusan eltávolítja a kérdéses attribútumokat a karanténból.

Duplikált attribútum rugalmasságának engedélyezése

Az attribútumok ismétlődő rugalmassága lesz az új alapértelmezett viselkedés az összes Microsoft Entra-bérlőben. Alapértelmezés szerint be van kapcsolva az összes olyan bérlő esetében, amely először engedélyezte a szinkronizálást 2016. augusztus 22-én vagy később. Azoknak a bérlőknek, amelyek a dátum előtt engedélyezték a szinkronizálást, a szolgáltatás engedélyezve lesz a kötegekben. Ez a bevezetés 2016 szeptemberében kezdődik, és e-mailben értesítést küldünk minden bérlő technikai értesítési kapcsolattartójának a funkció engedélyezésének konkrét dátumával.

Feljegyzés

Miután bekapcsolta az ismétlődő attribútum rugalmasságát, nem tiltható le.

Annak ellenőrzéséhez, hogy a szolgáltatás engedélyezve van-e a bérlőjéhez, ehhez töltse le az Azure Active Directory PowerShell modul legújabb verzióját, és futtassa a következőket:

Get-MsolDirSyncFeatures -Feature DuplicateUPNResiliency

Get-MsolDirSyncFeatures -Feature DuplicateProxyAddressResiliency

Feljegyzés

A Set-MsolDirSyncFeature parancsmaggal már nem engedélyezheti proaktívan a Duplikált attribútum rugalmasság funkcióját, mielőtt be lenne kapcsolva a bérlő számára. A funkció teszteléséhez létre kell hoznia egy új Microsoft Entra-bérlőt.

Feljegyzés

Az Azure AD- és MSOnline PowerShell-modulok 2024. március 30-ától elavultak. További információkért olvassa el az elavulás frissítését. Ezen dátum után ezeknek a moduloknak a támogatása a Microsoft Graph PowerShell SDK-ra való migrálásra és a biztonsági javításokra korlátozódik. Az elavult modulok 2025. március 30-ától működnek tovább.

Javasoljuk, hogy migráljon a Microsoft Graph PowerShellbe a Microsoft Entra ID (korábbi nevén Azure AD) használatához. Gyakori migrálási kérdésekért tekintse meg a migrálással kapcsolatos gyakori kérdéseket. Megjegyzés: Az MSOnline 1.0.x verziói 2024. június 30. után fennakadást tapasztalhatnak.

DirSyncProvisioningError típusú hibákat tartalmazó objektumok azonosítása

Jelenleg két módszer létezik az ismétlődő tulajdonságütközések miatt ilyen hibákat okozó objektumok azonosítására, az Azure Active Directory PowerShell és a Microsoft 365 Felügyeleti központ. A jövőben további portálalapú jelentéskészítésre is terveznek kiterjeszteni.

Azure Active Directory PowerShell

A jelen témakörben szereplő PowerShell-parancsmagok esetében a következő igaz:

  • Az alábbi parancsmagok mindegyike megkülönbözteti a kis- és nagybetűket.
  • A –ErrorCategory PropertyConflictet mindig tartalmaznia kell. Jelenleg nincs más típusú ErrorCategory, de ez a jövőben kiterjeszthető.

Első lépésként futtassa a Csatlakozás-MsolService szolgáltatást, és adja meg a bérlői rendszergazda hitelesítő adatait.

Ezután a következő parancsmagokkal és operátorokkal különböző módokon tekintheti meg a hibákat:

  1. Az összes megtekintése
  2. Tulajdonságtípus szerint
  3. Ütköző érték alapján
  4. Sztringkeresés használata
  5. Sorted
  6. Korlátozott mennyiségben vagy az összesben

Az összes megjelenítése

Miután csatlakozott, az attribútumkiépítési hibák általános listájának megtekintéséhez a bérlő futtatásakor:

Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict

Ez az alábbihoz hasonló eredményt eredményez:
Get-MsolDirSyncProvisioningError

Tulajdonságtípus szerint

A hibák tulajdonságtípus szerinti megjelenítéséhez adja hozzá a -PropertyName jelölőt a UserPrincipalName vagy a ProxyAddresses argumentummal:

Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict -PropertyName UserPrincipalName

Or

Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict -PropertyName ProxyAddresses

Ütköző érték alapján

Ha egy adott tulajdonsággal kapcsolatos hibákat szeretne látni, adja hozzá a -PropertyValue jelzőt (a -PropertyName-t is használni kell a jelző hozzáadásakor):

Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict -PropertyValue User@domain.com -PropertyName UserPrincipalName

Széles körű sztringkereséshez használja a -SearchString jelzőt . Ez a fenti jelzőktől függetlenül is használható, a -ErrorCategory PropertyConflict kivételével, amely mindig kötelező:

Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict -SearchString User

Korlátozott mennyiségben vagy az összesben

  1. A MaxResults <Int> használatával a lekérdezés meghatározott számú értékre korlátozható.
  2. Minden használható annak biztosítására, hogy az összes eredmény lekérhető abban az esetben, ha nagy számú hiba áll fenn.

Get-MsolDirSyncProvisioningError -ErrorCategory PropertyConflict -MaxResults 5

Microsoft 365 felügyeleti központ

A címtár-szinkronizálási hibákat a Microsoft 365 Felügyeleti központban tekintheti meg. A Microsoft 365 Felügyeleti központ jelentés csak az ilyen hibákat tartalmazó felhasználói objektumokat jeleníti meg. Nem jelenít meg információkat a csoportok és a partnerek közötti ütközésekről.

Képernyőkép a címtár-szinkronizálási hibákról a Microsoft 365 Felügyeleti központ.

A címtár-szinkronizálási hibák Microsoft 365 Felügyeleti központ való megtekintésére vonatkozó útmutatásért lásd: Címtár-szinkronizálási hibák azonosítása a Microsoft 365-ben.

Identitásszinkronizálási hibajelentés

Ha egy ismétlődő attribútumütközéssel rendelkező objektumot ezzel az új viselkedéssel kezel, a rendszer értesítést küld a bérlő műszaki értesítési kapcsolattartójának küldött szabványos identitásszinkronizálási hibajelentésben. Ebben a viselkedésben azonban jelentős változás áll be. Korábban az ismétlődő attribútumütközésre vonatkozó információk az ütközés feloldásáig minden további hibajelentésben szerepelni fognak. Ezzel az új viselkedéssel egy adott ütközés hibaértesítése csak egyszer jelenik meg az ütköző attribútum karanténba helyezésekor.

Íme egy példa arra, hogy az e-mail-értesítés hogyan néz ki ProxyAddress-ütközés esetén:
A ProxyAddress ütközésére vonatkozó e-mail-értesítés példáját bemutató képernyőkép.

Ütközések feloldása

Ezeknek a hibáknak a hibaelhárítási stratégiája és megoldási taktikája nem térhet el az ismétlődő attribútumhibák korábbi kezelési módjától. Az egyetlen különbség az, hogy az időzítőfeladat végigfut a bérlőn a szolgáltatásoldalon, és automatikusan hozzáadja a kérdéses attribútumot a megfelelő objektumhoz az ütközés feloldása után.

Az alábbi cikk különböző hibaelhárítási és megoldási stratégiákat ismertet: Ismétlődő vagy érvénytelen attribútumok megakadályozzák a címtár-szinkronizálást az Office 365-ben.

Ismert problémák

Ezen ismert problémák egyike sem okoz adatvesztést vagy szolgáltatáscsökkenést. Ezek közül több esztétikai, mások normál "pre-resiliency" duplikált attribútumhibákat okoznak az ütközési attribútum quarantinálása helyett, egy másik pedig bizonyos hibák további manuális javítást igényelnek.

Alapvető viselkedés:

  1. Az adott attribútumkonfigurációkkal rendelkező objektumok továbbra is exportálási hibákat kapnak, szemben az ismétlődő attribútum(ok) karanténba helyezésével.
    Példa:

    a. Az új felhasználó az AD-ben jön létre egy UPN-nel Joe@contoso.com és ProxyAddress smtp-sel:Joe@contoso.com

    b. Az objektum tulajdonságai ütköznek egy meglévő csoporttal, ahol a ProxyAddress SMTP :Joe@contoso.com.

    c. Exportáláskor a ProxyAddress ütközési hiba jelenik meg ahelyett, hogy karanténba helyezték volna az ütközési attribútumokat. A rendszer minden további szinkronizálási ciklus után újrapróbálkozza a műveletet, ahogyan az a rugalmassági funkció engedélyezése előtt történt volna.

  2. Ha két csoport jön létre a helyszínen ugyanazzal az SMTP-címmel, az egyik nem tud kiépíteni az első kísérlet során egy szabványos duplikált ProxyAddress-hibával . A duplikált érték azonban a következő szinkronizálási ciklus során megfelelően karanténba kerül.

Office Portal-jelentés:

  1. Az UPN-ütközéskészlet két objektumának részletes hibaüzenete ugyanaz. Ez azt jelzi, hogy mindketten módosították az UPN-jüket / karanténba helyezték őket, amikor valójában csak az egyik adat módosult.

  2. Az UPN-ütközés részletes hibaüzenete helytelen displayName-et jelenít meg azon felhasználók számára, akik módosították vagy karanténba helyezték az UPN-et. Példa:

    a. Az A felhasználó először az UPN =User@contoso.com-val szinkronizál.

    b. A "B" felhasználót a rendszer a következő lépésben próbálja szinkronizálni az UPN = értékévelUser@contoso.com.

    c. A B felhasználó UPN-jét a rendszer a DirSyncProvisioningErrorsra módosítja User1234@contoso.onmicrosoft.com és User@contoso.com hozzáadja.

    d. A "B" felhasználó hibaüzenetének azt kell jeleznie, hogy az A felhasználó már rendelkezik User@contoso.com UPN-ként, de a B felhasználó saját displayName tulajdonságát jeleníti meg.

Identitásszinkronizálási hibajelentés:

A probléma megoldásának lépéseire mutató hivatkozás helytelen:
Aktív felhasználók

Ennek a pontra kell mutatnia https://aka.ms/duplicateattributeresiliency.

Lásd még