Informazioni sugli aggiornamenti di utenti in massa durante le modifiche al dominio verificate

2025-03-16

Questo articolo descrive uno scenario comune in cui i log di controllo visualizzano molti UserPrincipalName aggiornamenti attivati da una modifica di dominio verificata. Questo articolo illustra le cause e le considerazioni per gli aggiornamenti di UserManagement nei log di controllo che si verificano durante le modifiche del dominio verificate. L'articolo fornisce un approfondimento sull'operazione back-end che attiva le modifiche apportate agli oggetti di massa in Microsoft Entra ID.

Sintomi

I log di controllo di Microsoft Entra mostrano più aggiornamenti utente che si sono verificati nel tenant di Microsoft Entra. Le informazioni sull'attore per questi eventi sono vuote o visualizzano N/A.

Gli aggiornamenti di massa includono la modifica del dominio per i UserPrincipalName, passando dal dominio preferito dell'organizzazione al suffisso di dominio predefinito *.onmicrosoft.com.

Dettagli del registro di controllo di esempio

Data attività (UTC): 2022-01-27 07:44:05

Attività: Aggiornare l'utente

Tipo di attore: Altro

Actor UPN: N/A

Stato: operazione riuscita

Categoria: UserManagement

Servizio: Directory principale

ID destinazione: aaaaaaaa-bbbb-0000-11111-bbbbbbbbbbbbb

Nome destinazione: [email protected]

Tipo di destinazione: Utente

All'interno dei dettagli completi della voce del log di controllo, cercare la sezione modifiedProperties. In questa sezione vengono illustrate le modifiche apportate all'oggetto utente. I campi oldValue e newValue mostrano la modifica del dominio.

"modifiedProperties":
  "displayName": "UserPrincipalName",
  "oldValue": "[\"[email protected]\"]",
  "newValue": "[\"[email protected]\"]"

Cause

Un motivo comune alla base delle modifiche degli oggetti di massa è dovuto a un'operazione back-end non asincrona. Questa operazione determina gli elementi appropriati UserPrincipalName e proxyAddresses che vengono aggiornati negli utenti, gruppi o contatti di Microsoft Entra.

Lo scopo di questa operazione back-end garantisce che UserPrincipalName e proxyAddresses siano coerenti in Microsoft Entra ID in qualsiasi momento. Una modifica esplicita, ad esempio una modifica di dominio verificata, attiva questa operazione.

Ad esempio, se si aggiunge un dominio verificato Fabrikam.com al tenant Contoso.onmicrosoft.com, questa azione attiva l'operazione back-end su tutti gli oggetti nel tenant. Questo evento viene acquisito nei log di controllo di Microsoft Entra come eventi di aggiornamento utente preceduti da un evento Aggiungi dominio verificato.

Se Fabrikam.com è stato rimosso dal tenant Contoso.onmicrosoft.com, tutti gli eventi Update User sono preceduti da un evento Remove verified domain .

Risoluzione

Se si è verificato questo problema, è possibile trarre vantaggio dall'uso di Microsoft Entra Connect per sincronizzare i dati tra la directory locale e l'ID Microsoft Entra. Questa azione garantisce che UserPrincipalName e proxyAddresses siano coerenti in entrambi gli ambienti.

Quando si tenta di aggiungere o gestire manualmente questi oggetti, si corre il rischio di un'altra operazione back-end che attiva una modifica in blocco.

Esaminare gli articoli seguenti per acquisire familiarità con questi concetti:

Considerazioni

Questa operazione back-end non causa modifiche a determinati oggetti che:

non dispone di una licenza di Microsoft Exchange attiva
avere MSExchRemoteRecipientType impostato su Null
non sono considerate una risorsa condivisa

Una risorsa condivisa è quando CloudMSExchRecipientDisplayType contiene uno dei valori seguenti:

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

Per creare una maggiore correlazione tra questi due eventi diversi, Microsoft sta lavorando per aggiornare le informazioni sull'attore nei log di controllo per identificare queste modifiche come attivate da una modifica verificata del dominio. Questa azione consente di verificare quando si è verificato l'evento di modifica del dominio e di aggiornare in massa gli oggetti nel tenant.

Nella maggior parte dei casi, non ci sono modifiche agli utenti poiché i loro UserPrincipalName e proxyAddresses sono coerenti, quindi stiamo lavorando per visualizzare nei log di controllo solo gli aggiornamenti che hanno causato una modifica effettiva all'oggetto. Questa azione impedisce il disturbo nei log di controllo e consente agli amministratori di correlare le modifiche utente rimanenti agli eventi di modifica del dominio verificati.

Approfondimento

Vuoi saperne di più su cosa sta succedendo dietro le quinte? Ecco un approfondimento sull'operazione back-end che attiva le modifiche apportate agli oggetti di massa in Microsoft Entra ID. Prima di approfondire, vedere l'articolo sugli attributi shadow del servizio di sincronizzazione Microsoft Entra Connectper comprendere gli attributi shadow.

userPrincipalName

Per gli utenti esclusivamente cloud, UserPrincipalName è impostato su un suffisso di dominio verificato. Quando viene elaborato un userPrincipalName incoerente, l'operazione lo converte nel suffisso onmicrosoft.com predefinito, ad esempio : [email protected].

Per gli utenti sincronizzati, UserPrincipalName è impostato su un suffisso di dominio verificato e corrisponde al valore locale, ShadowUserPrincipalName. Quando viene elaborato un UserPrincipalName incoerente, l'operazione viene ripristinata allo stesso valore di ShadowUserPrincipalName o, nel caso in cui il suffisso di dominio sia stato rimosso dal tenant, lo converte nel suffisso di dominio predefinito *.onmicrosoft.com .

ProxyAddresses

Per gli utenti solo cloud, la coerenza significa che proxyAddresses corrisponda a un suffisso di dominio verificato. Quando viene elaborato un proxyAddresses incoerente, l'operazione back-end la converte nel suffisso di dominio predefinito *.onmicrosoft.com , ad esempio: SMTP:[email protected].

Per gli utenti sincronizzati, la coerenza significa che i proxyAddresses corrispondono al valore locale proxyAddresses, ovvero ShadowProxyAddresses. È previsto che proxyAddresses sia sincronizzato con ShadowProxyAddresses. Se all'utente sincronizzato è assegnata una licenza di Exchange, i valori cloud e locali devono corrispondere. Questi valori devono corrispondere anche a un suffisso di dominio verificato.

In questo scenario, l'operazione di back-end sanitizza i proxyAddresses incoerenti con un suffisso di dominio non verificato e vengono rimossi dall'oggetto in Microsoft Entra ID. Se il dominio non verificato viene successivamente verificato, l'operazione di back-end ricalcola e aggiunge proxyAddresses da ShadowProxyAddresses all'oggetto in Microsoft Entra ID.

Nota

Per gli oggetti sincronizzati, per evitare che la logica operativa back-end calcoli risultati imprevisti, è consigliabile impostare proxyAddresses su un dominio verificato di Microsoft Entra nell'oggetto locale.

Attributi shadow del servizio di sincronizzazione Microsoft Entra Connect