Descripción de las actualizaciones masivas de usuarios durante cambios en dominios comprobados
En este artículo se describe un escenario común en el que los registros de auditoría muestran muchas actualizaciones de UserPrincipalName desencadenadas por un cambio de dominio comprobado. En este artículo se explican las causas y consideraciones de las actualizaciones de UserManagement en los registros de auditoría que se producen durante cambios en dominios comprobados. En este artículo se proporciona una profundización en la operación de back-end que desencadena cambios masivos de objetos en Microsoft Entra ID.
Síntomas
En los registros de auditoría de Microsoft Entra se muestra que se han producido varias actualizaciones de usuario en mi inquilino de Microsoft Entra. La información de Actor de estos eventos está vacía o muestra N/D.
Las actualizaciones masivas implican cambiar el dominio de UserPrincipalName del dominio preferido de la organización al sufijo de dominio *.onmicrosoft.com predeterminado.
Ejemplo de detalles del registro de auditoría
Fecha de la actividad (UTC): 27-01-2022 07:44:05
Actividad: Actualización de usuario
Tipo de actor: Otro
UPN de actor: N/D
Estado: correcto
Categoría: UserManagement
Servicio: Directorio principal
Id. de destino: aaaaaaaaa-bbbb-0000-11111-bbbbbbbbbbbbb
Nombre de destino: user@contoso.com
Tipo de destino: Usuario
En los detalles completos de la entrada del registro de auditoría, busque la sección modifiedProperties. En esta sección se muestran los cambios realizados en el objeto de usuario. En los campos oldValue y newValue se muestra el cambio de dominio.
"modifiedProperties":
"displayName": "UserPrincipalName",
"oldValue": "[\"user@contoso.onmicrosoft.com\"]",
"newValue": "[\"user@contoso.com\"]"
Causas
Un motivo común de los cambios masivos en los objetos es una operación de back-end no sincrónica. Esta operación determina los valores UserPrincipalName y proxyAddresses adecuados que se actualizan en usuarios, grupos o contactos de Microsoft Entra.
El propósito de esta operación de back-end garantiza que UserPrincipalName y proxyAddresses sean coherentes en Microsoft Entra ID en todo momento. Un cambio explícito, como un cambio de dominio comprobado, desencadena esta operación.
Por ejemplo, si agrega un dominio comprobado Fabrikam.com al inquilino Contoso.onmicrosoft.com, esta acción desencadena la operación de back-end en todos los objetos del inquilino. Este evento se captura en los registros de auditoría de Microsoft Entra como un evento Actualizar usuario precedido por un evento Agregar dominio comprobado.
Si Fabrikam.com se ha quitado del inquilino Contoso.onmicrosoft.com, todos los eventos Actualizar usuario están precedidos de un evento Quitar dominio comprobado.
Solución
Si ha detectado este problema, puede beneficiarse del uso de Microsoft Entra Connect para sincronizar datos entre el directorio local y Microsoft Entra ID. Esta acción garantiza que UserPrincipalName y proxyAddresses sean coherentes en ambos entornos.
Al intentar agregar o mantener manualmente estos objetos, corre el riesgo de que otra operación de back-end desencadene un cambio masivo.
Revise los artículos siguientes para familiarizarse con estos conceptos:
Consideraciones
Esta operación de back-end no provoca cambios en determinados objetos que:
- no tiene una licencia activa de Microsoft Exchange
- tienen
MSExchRemoteRecipientTypeestablecido en Null - no se consideran un recurso compartido
Un recurso compartido es cuando CloudMSExchRecipientDisplayType contiene uno de los siguientes valores:
MailboxUser(shared)PublicFolderConferenceRoomMailboxEquipmentMailboxArbitrationMailboxRoomListTeamMailboxUserGroupMailboxSchedulingMailboxACLableMailboxUserACLableTeamMailboxUser
Para generar una mayor correlación entre estos dos eventos dispares, Microsoft trabaja en la actualización de la información del Actor en los registros de auditoría para identificar estos cambios como desencadenados por un cambio de dominio comprobado. Esta acción le ayuda a comprobar cuándo ha tenido lugar el evento de cambio de dominio comprobado y cuándo ha empezado a actualizar masivamente los objetos en el inquilino.
En la mayoría de los casos, no se realiza ningún cambio en los usuarios, ya que UserPrincipalName y proxyAddresses son coherentes; por este motivo, se trabaja en mostrar en los registros de auditoría solo aquellas actualizaciones que han provocado un cambio real en el objeto. Esta acción evitará la información innecesaria en los registros de auditoría y ayuda a que los administradores pongan en correlación los cambios de usuario restantes con los eventos de cambio de dominio comprobado.
Profundización
¿Quiere obtener más información sobre lo que sucede en segundo plano? Esta es una profundización en la operación de back-end que desencadena cambios de objetos masivos en Microsoft Entra ID. Antes de profundizar, consulte el artículo Atributos de propiedad reemplazada del servicio Sincronización de conexión de Microsoft Entra para comprender los atributos de propiedad reemplazada.
UserPrincipalName
En el caso de los usuarios que solo están en la nube, UserPrincipalName se establece en un sufijo de dominio comprobado. Cuando se procesa una instancia de UserPrincipalName incoherente, la operación la convierte al sufijo onmicrosoft.com predeterminado; por ejemplo: username@Contoso.onmicrosoft.com.
Para los usuarios sincronizados, UserPrincipalName se establece en un sufijo de dominio comprobado y coincide con el valor local, ShadowUserPrincipalName. Cuando se procesa una instancia de UserPrincipalName incoherente, la operación revierte al mismo valor de ShadowUserPrincipalName o, en caso de que se haya quitado el sufijo de dominio del inquilino, la convierte al sufijo del dominio *.onmicrosoft.com.
ProxyAddresses
En el caso de los usuarios que solo están en la nube, la coherencia implica que proxyAddresses coinciden con un sufijo de dominio comprobado. Cuando se procesa una instancia de proxyAddresses incoherente, la operación de back-end la convierte al sufijo de dominio *.onmicrosoft.com predeterminado; por ejemplo: SMTP:username@Contoso.onmicrosoft.com.
En el caso de los usuarios sincronizados, la coherencia implica que proxyAddresses coincide con el valor proxyAddresses local (es decir, ShadowProxyAddresses). Se espera que los valores proxyAddresses estén sincronizados con ShadowProxyAddresses. Si el usuario sincronizado tiene asignada una licencia de Exchange, los valores locales y en la nube deben coincidir. Estos valores también deben coincidir con un sufijo de dominio comprobado.
En este escenario, la operación de back-end corrige el valor proxyAddresses incoherente con un sufijo de dominio sin comprobar y se quita del objeto en Microsoft Entra ID. Si ese dominio sin comprobar se comprueba más adelante, la operación de back-end vuelve a calcular el valor proxyAddresses de ShadowProxyAddresses y lo agrega al objeto en Microsoft Entra ID.
Nota:
En el caso de los objetos sincronizados, para evitar que la lógica de la operación de back-end calcule resultados inesperados, se recomienda establecer proxyAddresses en un dominio comprobado de Microsoft Entra en el objeto local.
Pasos siguientes
Atributos paralelos del servicio de sincronización de Microsoft Entra Connect