Comprendre les mises à jour groupées des utilisateurs lors des changements de domaine vérifiés
Cet article décrit un scénario courant dans lequel les journaux d’audit affichent les nombreuses mises à jour UserPrincipalName déclenchées par une modification de domaine vérifié. Cet article explique les causes et les considérations relatives aux mises à jour de UserManagement dans les journaux d'audit qui se produisent lors des modifications de domaine vérifiées. L’article fournit une analyse approfondie de l’opération backend qui déclenche des modifications massives d’objets dans Microsoft Entra ID.
Symptômes
Les journaux d’audit Microsoft Entra indiquent que plusieurs mises à jour utilisateur se sont produites dans mon tenant Microsoft Entra. Les informations Acteur pour ces évènements sont vides ou affichent N/A.
Les mises à jour en bloc impliquent la modification du domaine pour le UserPrincipalName, changé du domaine préféré de l’organisation au suffixe de domaine par défaut *.onmicrosoft.com.
Exemples de détails du journal d’audit
Date d’activité (UTC) : 2022-01-27 07:44:05
Activité : Mise à jour utilisateur
Type d’acteur : Autre
UPN Acteur : N/A
État : Réussite
Catégorie : UserManagement
Service : répertoire principal
ID cible : aaaaaaaaa-bbbb-0000-11111-bbbbbbbbbbbbb
Nom de cible : user@contoso.com
Type de cible : Utilisateur
Dans les détails complets de l’entrée du journal d’audit, recherchez la section modifiedProperties. Cette section présente les modifications apportées à l’objet utilisateur. Les champs oldValue et newValue affichent la modification de domaine.
"modifiedProperties":
"displayName": "UserPrincipalName",
"oldValue": "[\"user@contoso.onmicrosoft.com\"]",
"newValue": "[\"user@contoso.com\"]"
Causes
L’une des raisons courantes des modifications apportées aux objets en masse est due à une opération back-end non synchronisée. Cette opération détermine les éléments appropriés UserPrincipalName et proxyAddresses, qui sont mis à jour dans les utilisateurs, groupes ou contacts Microsoft Entra.
L’objectif de cette opération back-end garantit que UserPrincipalName et proxyAddresses sont cohérents dans Microsoft Entra ID à tout moment. Une modification explicite, telle qu’une modification de domaine vérifié, déclenche cette opération.
Par exemple, si vous ajoutez le domaine vérifié Fabrikam.com à votre tenant Contoso.onmicrosoft.com, cette action déclenche l’opération back-end sur tous les objets du tenant. Cet événement est capturé dans les journaux d’audit Microsoft Entra comme évènement Mise à jour utilisateur, précédé d’un évènement Ajout d’un domaine vérifié.
En revanche, si Fabrikam.com a été supprimé du tenant Contoso.onmicrosoft.com, alors tous les évènements Mise à jour utilisateur sont précédés d’un événement Suppression de domaine vérifié.
Résolution
Si vous avez rencontré ce problème, vous pourriez tirer parti de l’utilisation de Microsoft Entra Connect pour synchroniser les données entre votre répertoire local et Microsoft Entra ID. Cette action garantit que UserPrincipalName et proxyAddresses sont cohérents dans les deux environnements.
Lorsque vous essayez d’ajouter ou de gérer manuellement ces objets, vous courez le risque d’une autre opération back-end qui déclenche une modification en bloc.
Étudiez les articles suivants pour vous familiariser avec ces concepts :
À propos de l’installation
Cette opération back-end n’entraîne pas de modifications à certains objets qui :
- ne disposent pas d’une licence Microsoft Exchange active
- ont
MSExchRemoteRecipientTypedéfini sur Null - ne sont pas considérés comme ressources partagées
Une ressource partagée existe si CloudMSExchRecipientDisplayType contient l’une des valeurs suivantes :
MailboxUser(partagé)PublicFolderConferenceRoomMailboxEquipmentMailboxArbitrationMailboxRoomListTeamMailboxUserGroupMailboxSchedulingMailboxACLableMailboxUserACLableTeamMailboxUser
Pour établir une meilleure corrélation entre ces deux évènements disparates, Microsoft travaille à la mise à jour de l’information Acteur dans les journaux d’audit pour identifier ces modifications comme déclenchées par un changement de domaine vérifié. Cette action permet de vérifier à quel moment l’évènement de changement de domaine vérifié s’est produit et a lancé la mise à jour en masse des objets dans le tenant.
Dans la plupart des cas, il n’y a aucune modification apportée aux utilisateurs, comme leur UserPrincipalName et leur proxyAddresses sont cohérents. Nous travaillons donc à afficher uniquement dans les journaux d’audit les mises à jour qui ont provoqué une modification réelle de l’objet. Cette action supprime les informations parasite des journaux d’audit et permet aux administrateurs de mettre en corrélation les autres modifications utilisateur avec l’évènement de changement de domaine vérifié.
Présentation approfondie
Vous souhaitez en savoir plus sur ce qui se passe en arrière-plan ? Voici une présentation approfondie de l’opération back-end qui déclenche des modifications d’objet en masse dans Microsoft Entra ID. Avant de vous y plonger, consultez l’article Attributs fantôme du service Microsoft Entra Connect Sync pour comprendre les attributs fantôme.
UserPrincipalName
Pour les utilisateurs cloud uniquement, UserPrincipalName est défini sur un suffixe de domaine vérifié. Quand un UserPrincipalName incohérent est traité, l’opération le convertit avec le suffixe onmicrosoft.com par défaut, par exemple : username@Contoso.onmicrosoft.com.
Pour les utilisateurs synchronisés, UserPrincipalName est défini sur un suffixe de domaine vérifié et correspond à la valeur locale, ShadowUserPrincipalName. Lorsqu’un UserPrincipalName incohérent est traité, l’opération revient à la même valeur que le ShadowUserPrincipalName ou, dans le cas où le suffixe de domaine a été supprimé du tenant, le convertit au suffixe de domaine *.onmicrosoft.com par défaut.
ProxyAddresses
Pour les utilisateurs cloud uniquement, la cohérence signifie que les proxyAddresses correspondent à un suffixe de domaine vérifié. Lorsqu’un proxyAddresses incohérent est traité, l’opération back-end la convertit au suffixe de domaine *.onmicrosoft.com par défaut, par exemple : SMTP:username@Contoso.onmicrosoft.com.
Pour les utilisateurs synchronisés, la cohérence signifie que les proxyAddresses correspondent à la valeur proxyAddresses locale(c’est-à-dire, ShadowProxyAddresses). Les proxyAddresses sont censées être synchronisées avec les ShadowProxyAddresses. Si un utilisateur synchronisé dispose d’une licence Exchange attribuée, les valeurs cloud et locales doivent correspondre. Ces valeurs doivent également correspondre à un suffixe de domaine vérifié.
Dans ce scénario, l’opération back-end assainit les proxyAddresses incohérents avec un suffixe de domaine non vérifié et ils sont supprimés de l’objet dans Microsoft Entra ID. Si ce domaine non vérifié est vérifié ultérieurement, l’opération back-end recalcule et ajoute les proxyAddresses à l’objet dans Microsoft Entra, depuis ShadowProxyAddresses.
Remarque
Pour les objets synchronisés, afin d’éviter que la logique back-end ne calcule des résultats inattendus, il est préférable de définir les proxyAddresses sur un domaine Microsoft Entra vérifié sur l’objet local.