Grundlegendes zu Massenbenutzerupdates bei überprüften Domain-Änderungen

In diesem Artikel wird ein gängiges Szenario beschrieben, in dem in den Überwachungsprotokollen viele UserPrincipalName-Updates angezeigt werden, die durch die Änderung einer überprüften Domänen ausgelöst wurden. In diesem Artikel werden die Ursachen und Überlegungen für Aktualisierungen im UserManagement in den Überwachungsprotokollen erläutert, die während überprüfter Domain-Änderungen auftreten. Hier ein tiefer Einblick in den Back-End-Vorgang, der Massenänderungen an Objekten in Microsoft Entra ID auslöst.

Problembeschreibung

Die Überwachungsprotokolle zeigen, dass in meinem Microsoft Entra-Mandanten mehrere Benutzeraktualisierungen aufgetreten wurden. Die Akteur-Informationen für diese Ereignisse sind leer oder zeigen N/V an.

Die Massenaktualisierungen umfassen das Ändern der Domäne für UserPrincipalName von der bevorzugten Domäne der Organisation zum standardmäßigen *.onmicrosoft.com-Domänensuffix.

Beispielhafte Details für das Überwachungsprotokoll

Datum der Aktivität (UTC): 2022-01-27 07:44:05

Aktivität: Benutzer aktualisieren

Akteurtyp: Sonstige

Akteur-UPN: N/V

Status: Erfolg

Kategorie: UserManagement

Dienst: Core Directory

Ziel-ID: aaaaaaaaa-bbbb-0000-11111-bbbbbbbbbbbbb

Zielname: user@contoso.com

Zieltyp: Benutzer

Suchen Sie in den vollständigen Details des Überwachungsprotokolleintrags nach dem Abschnitt modifiedProperties. In diesem Abschnitt werden die am Benutzerobjekt vorgenommenen Änderungen angezeigt. Die Felder oldValue und newValue zeigen die Domänenänderung an.

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

Ursachen

Ein häufiger Grund für Massenänderungen an Objekten ist ein nicht synchroner Back-End-Vorgang. Dieser Vorgang bestimmt den entsprechenden UserPrincipalName und die proxyAddresses, die in Microsoft Entra-Benutzern, -Gruppen oder -Kontakten aktualisiert werden.

Der Zweck dieses Back-End-Vorgangs besteht darin, sicherzustellen, dass „UserPrincipalName“ und „proxyAddresses“ in Microsoft Entra ID jederzeit konsistent sind. Eine explizite Änderung, z. B. die Änderung einer überprüften Domäne, löst diesen Vorgang aus.

Wenn Sie Ihrem Mandanten „Contoso.onmicrosoft.com“ beispielsweise die überprüfte Domäne „Fabrikam.com“ hinzufügen, löst diese Aktion den Back-End-Vorgang für alle Objekte im Mandanten aus. Dieses Ereignis wird in den Microsoft Entra-Überwachungsprotokollen als Benutzer aktualisieren aufgezeichnet, dem ein Ereignis vom Typ Überprüfte Domäne hinzufügen vorausgeht.

Wenn „Fabrikam.com“ aus dem Mandanten „Contoso.onmicrosoft.com“ entfernt wurde, geht allen Benutzer aktualisieren- Ereignissen ein Überprüfte Domäne entfernen- Ereignis voraus.

Lösung

Wenn dieses Problem aufgetreten ist, können Sie möglicherweise von der Verwendung von Microsoft Entra Connect profitieren, um Daten zwischen Ihrem lokalen Verzeichnis und Microsoft Entra ID zu synchronisieren. Diese Aktion stellt sicher, dass der UserPrincipalName und die proxyAddresses in beiden Umgebungen konsistent sind.

Wenn Sie versuchen, diese Objekte manuell hinzuzufügen oder zu verwalten, besteht das Risiko, dass durch einen weiteren Back-End-Vorgang eine Massenänderung ausgelöst wird.

Lesen Sie die folgenden Artikel, um sich mit diesen Konzepten vertraut zu machen:

Überlegungen

Dieser Back-End-Vorgang bewirkt keine Änderungen an bestimmten Objekten, für die Folgendes gilt:

  • Sie verfügen nicht über eine aktive Microsoft Exchange-Lizenz.
  • MSExchRemoteRecipientType ist auf Null festgelegt.
  • Sie werden nicht als freigegebene Ressource betrachtet.

Eine freigegebene Ressource liegt dann vor, wenn CloudMSExchRecipientDisplayType einen der folgenden Werte enthält:

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

Um mehr Korrelation zwischen diesen beiden unterschiedlichen Ereignissen zu erzielen, arbeitet Microsoft daran, die Informationen zum Akteur in den Überwachungsprotokollen zu aktualisieren, damit für diese Änderungen erkennbar ist, dass sie durch die Änderung einer überprüften Domäne ausgelöst wurden. Dies hilft bei der Überprüfung, ob eine Änderung an einer überprüften Domäne erfolgt ist und zu den Massenänderungen an den Objekte im Mandanten geführt hat.

In den meisten Fällen gibt es keine Änderungen an Benutzern, da ihr UserPrincipalName und ihre proxyAddresses konsistent sind. Daher arbeiten wir daran, in den Überwachungsprotokollen nur die Updates anzuzeigen, die eine tatsächliche Änderung am Objekt verursacht haben. Dadurch wird das „Rauschen“ in den Überwachungsprotokollen vermindert, sodass Administratoren die verbleibenden Benutzeränderungen mit dem Änderungsereignis an der überprüften Domäne wie oben erläutert korrelieren können.

Vertiefung

Möchten Sie mehr darüber erfahren, was hinter den Kulissen passiert? Hier ist ein tiefer Einblick in den Back-End-Vorgang, der Massenänderungen an Objekten in Microsoft Entra ID auslöst. Bevor Sie tiefer einsteigen, lesen Sie den Artikel Schattenattribute für den Microsoft Entra Connect-Synchronisierungsdienst, um Schattenattribute zu verstehen.

UserPrincipalName

Für reine Cloudbenutzer ist der „UserPrincipalName“ auf ein überprüftes Domänensuffix festgelegt. Wenn ein inkonsistenter „UserPrincipalName“ verarbeitet wird, konvertiert der Vorgang ihn in das Standardsuffix „onmicrosoft.com“, z. B. username@Contoso.onmicrosoft.com.

Für synchronisierte Benutzer wird der „UserPrincipalName“ auf ein überprüftes Domänensuffix festgelegt und entspricht dem lokalen Wert ShadowUserPrincipalName. Wenn ein inkonsistenter „UserPrincipalName“ verarbeitet wird, setzt der Vorgang ihn auf denselben Wert wie den des „ShadowUserPrincipalName“ zurück oder konvertiert ihn in das Standard-*.onmicrosoft.com-Domänensuffix, falls das Domänensuffix aus dem Mandanten entfernt wurde.

ProxyAddresses

Für reine Cloudbenutzer bedeutet Konsistenz, dass die proxyAddresses dem Suffix einer überprüften Domäne entsprechen. Wenn eine inkonsistente „proxyAddresses“ verarbeitet wird, konvertiert der Back-End-Vorgang ihn in das Standard-*.onmicrosoft.com-Domänensuffix, z. B. SMTP:username@Contoso.onmicrosoft.com.

Für synchronisierte Benutzer bedeutet Konsistenz, dass die „proxyAddresses“ mit dem lokalen „proxyAddresses“-Wert (d. h. „ShadowProxyAddresses“) übereinstimmen. Es wird erwartet, dass „proxyAddresses“ mit „ShadowProxyAddresses“ synchron ist. Wenn dem synchronisierten Benutzer eine Exchange-Lizenz zugewiesen ist, müssen die Cloud- und die lokalen Werte übereinstimmen. Diese Werte müssen auch mit einem überprüften Domänensuffix übereinstimmen.

In diesem Szenario bereinigt der Back-End-Vorgang die inkonsistente „proxyAddresses“ mit einem nicht überprüften Domänensuffix und wird aus dem Objekt in Microsoft Entra ID entfernt. Wenn diese nicht überprüfte Domäne später überprüft wird, berechnet der Back-End-Vorgang neu und fügt die „proxyAddresses“ aus „ShadowProxyAddresses“ wieder in das Objekt in Microsoft Entra ID ein.

Hinweis

Um zu vermeiden, dass die Logik des Back-End-Vorgangs unerwartete Ergebnisse berechnet, ist es für synchronisierte Objekte am besten, „proxyAddresses“ auf eine durch Microsoft Entra überprüfte Domäne auf dem lokalem Objekt festzulegen.

Nächste Schritte

Schattenattribute des Microsoft Entra Connect Sync-Dienstes