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 Wert für „proxyAddresses“ (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.