Share via


Informatie over bulkupdates van gebruikers tijdens wijzigingen in geverifieerde domeinen

In dit artikel wordt een veelvoorkomend scenario beschreven waarin in de auditlogboeken veel UserPrincipalName updates worden weergegeven die worden geactiveerd door een geverifieerde domeinwijziging. In dit artikel worden de oorzaken en overwegingen voor updates van UserManagement in de auditlogboeken uitgelegd die optreden tijdens wijzigingen in geverifieerde domeinen. In het artikel wordt dieper ingegaan op de back-endbewerking waarmee massaobjectwijzigingen in Microsoft Entra-id worden geactiveerd.

Symptomen

In de auditlogboeken van Microsoft Entra worden meerdere gebruikersupdates weergegeven die zijn opgetreden in mijn Microsoft Entra-tenant. De actorinformatie voor deze gebeurtenissen is leeg of toont N/B.

De bulkupdates omvatten het wijzigen van het domein voor het UserPrincipalName gewijzigde domein van het voorkeursdomein van de organisatie in het standaarddomeinachtervoegsel *.onmicrosoft.com .

Voorbeeld van details van auditlogboek

Activiteitsdatum (UTC): 2022-01-27 07:44:05

Activiteit: Gebruiker bijwerken

Actortype: Overig

Actor UPN: N.B.

Status: geslaagd

Categorie: UserManagement

Service: Core Directory

Doel-id: aaaaaaaaa-bbbb-0000-11111-bbbbbbbbbbbbbbb

Doelnaam: user@contoso.com

Doeltype: Gebruiker

Zoek in de volledige details van de vermelding van het auditlogboek naar de modifiedProperties sectie. In deze sectie ziet u de wijzigingen die zijn aangebracht in het gebruikersobject. De oldValue velden en newValue velden geven de wijziging van het domein weer.

"modifiedProperties":
  "displayName": "UserPrincipalName",
  "oldValue": "[\"user@contoso.onmicrosoft.com\"]",
  "newValue": "[\"user@contoso.com\"]"

Oorzaken

Een veelvoorkomende reden achter wijzigingen in massaobjecten is het gevolg van een niet-synchrone back-endbewerking. Deze bewerking bepaalt de juiste UserPrincipalName en proxyAddresses die worden bijgewerkt in Microsoft Entra-gebruikers, -groepen of -contactpersonen.

Het doel van deze back-endbewerking zorgt ervoor dat UserPrincipalName en proxyAddresses op elk gewenst moment consistent zijn in Microsoft Entra ID. Een expliciete wijziging, zoals een geverifieerde domeinwijziging, activeert deze bewerking.

Als u bijvoorbeeld een geverifieerd domein toevoegt Fabrikam.com aan uw Contoso.onmicrosoft.com tenant, wordt met deze actie de back-endbewerking voor alle objecten in de tenant geactiveerd. Deze gebeurtenis wordt vastgelegd in de Auditlogboeken van Microsoft Entra als Update User-gebeurtenissen voorafgegaan door een geverifieerde domeingebeurtenis toevoegen.

Als Fabrikam.com is verwijderd uit de Contoso.onmicrosoft.com-tenant, worden alle gebeurtenissen van de updategebruiker voorafgegaan door een geverifieerde domeingebeurtenis verwijderen.

Oplossing

Als u dit probleem hebt aangetroffen, hebt u mogelijk baat bij het gebruik van Microsoft Entra Verbinding maken om gegevens te synchroniseren tussen uw on-premises adreslijst en Microsoft Entra-id. Deze actie zorgt ervoor dat de UserPrincipalName en proxyAddresses zijn consistent in beide omgevingen.

Wanneer u deze objecten handmatig probeert toe te voegen of te onderhouden, loopt u het risico dat een andere back-endbewerking een bulkwijziging activeert.

Bekijk de volgende artikelen om vertrouwd te raken met deze concepten:

Overwegingen

Deze back-endbewerking veroorzaakt geen wijzigingen in bepaalde objecten die:

  • geen actieve Microsoft Exchange-licentie hebben
  • hebben MSExchRemoteRecipientType ingesteld op Null
  • worden niet beschouwd als een gedeelde resource

Een gedeelde resource is wanneer CloudMSExchRecipientDisplayType deze een van de volgende waarden bevat:

  • MailboxUser (gedeeld)
  • PublicFolder
  • ConferenceRoomMailbox
  • EquipmentMailbox
  • ArbitrationMailbox
  • RoomList
  • TeamMailboxUser
  • GroupMailbox
  • SchedulingMailbox
  • ACLableMailboxUser
  • ACLableTeamMailboxUser

Om meer correlatie te bouwen tussen deze twee verschillende gebeurtenissen, werkt Microsoft aan het bijwerken van de actorgegevens in de auditlogboeken om deze wijzigingen te identificeren zoals geactiveerd door een geverifieerde domeinwijziging. Met deze actie kunt u controleren wanneer de gebeurtenis voor het wijzigen van het geverifieerde domein heeft plaatsgevonden en de objecten in de tenant massaal zijn bijgewerkt.

In de meeste gevallen zijn er geen wijzigingen in gebruikers als hun UserPrincipalName en proxyAddresses zijn ze consistent, dus we werken eraan om alleen weer te geven in de auditlogboeken die updates hebben veroorzaakt die een werkelijke wijziging in het object hebben veroorzaakt. Met deze actie voorkomt u ruis in de auditlogboeken en kunnen beheerders de resterende wijzigingen van gebruikers correleren met geverifieerde domeinwijzigingsgebeurtenissen.

Deep Dive

Wilt u meer weten over wat er achter de schermen gebeurt? Hier volgt een uitgebreide uitleg over de back-endbewerking waarmee massaobjectwijzigingen in Microsoft Entra-id worden geactiveerd. Voordat u aan de slag gaat, raadpleegt u het artikel microsoft Entra Verbinding maken Sync-serviceschaduwkenmerken om inzicht te hebben in de schaduwkenmerken.

UserPrincipalName

Voor gebruikers met alleen de cloud is userPrincipalName ingesteld op een geverifieerd domeinachtervoegsel. Wanneer een inconsistente UserPrincipalName wordt verwerkt, wordt deze door de bewerking geconverteerd naar het standaardachtervoegsel onmicrosoft.com, bijvoorbeeld: username@Contoso.onmicrosoft.com.

Voor gesynchroniseerde gebruikers wordt userPrincipalName ingesteld op een geverifieerd domeinachtervoegsel en komt deze overeen met de on-premises waarde. ShadowUserPrincipalName Wanneer een inconsistente UserPrincipalName wordt verwerkt, wordt de bewerking teruggezet naar dezelfde waarde als de ShadowUserPrincipalName of, in het geval dat het domeinachtervoegsel uit de tenant is verwijderd, converteert deze naar het standaarddomeinachtervoegsel *.onmicrosoft.com .

ProxyAddresses

Voor cloudgebruikers betekent consistentie dat het proxyAddresses overeenkomt met een geverifieerd domeinachtervoegsel. Wanneer een inconsistente proxyAddresses wordt verwerkt, converteert de back-endbewerking deze naar het standaarddomeinachtervoegsel *.onmicrosoft.com , bijvoorbeeld: SMTP:username@Contoso.onmicrosoft.com.

Voor gesynchroniseerde gebruikers betekent consistentie dat de proxyAddresses overeenkomen met de on-premises proxyAddresses-waarde (dat wil zeggen ShadowProxyAddresses). De proxyAddresses worden naar verwachting gesynchroniseerd met ShadowProxyAddresses. Als aan de gesynchroniseerde gebruiker een Exchange-licentie is toegewezen, moeten de cloud- en on-premises waarden overeenkomen. Deze waarden moeten ook overeenkomen met een geverifieerd domeinachtervoegsel.

In dit scenario worden met de back-endbewerking de inconsistente proxyAddresses met een niet-geverifieerd domeinachtervoegsel opgeschoond en verwijderd uit het object in Microsoft Entra-id. Als dit niet-geverifieerde domein later wordt geverifieerd, wordt de back-endbewerking opnieuw gecomputeerd en worden de proxyAddresses van ShadowProxyAddresses weer toegevoegd aan het object in Microsoft Entra-id.

Notitie

Voor gesynchroniseerde objecten kunt u voorkomen dat de logica van de back-endbewerking onverwachte resultaten berekent. Het is raadzaam proxyAddresses in te stellen op een door Microsoft Entra geverifieerd domein op het on-premises object.

Volgende stappen

Schaduwkenmerken van Microsoft Entra Verbinding maken Sync-service