Informazioni sugli aggiornamenti degli utenti in blocco durante le modifiche al dominio verificate

  • Articolo

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 in blocco comportano la modifica del dominio per la UserPrincipalName modifica dal dominio preferito dell'organizzazione al suffisso di dominio predefinito *.onmicrosoft.com .

Dettagli del log di controllo di esempio

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

Attività: Aggiornare l'utente

Tipo di attore: Altro

UPN attore: N/A

Stato: operazione riuscita

Categoria: UserManagement

Servizio: Directory principale

ID destinazione: aaa-bbbb-0000-11111-bbbbbbbbb

Nome destinazione: user@contoso.com

Tipo di destinazione: Utente

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

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

Cause

Un motivo comune alla base delle modifiche degli oggetti di massa è dovuto a un'operazione back-end non asincrona. Questa operazione determina le impostazioni appropriate UserPrincipalName e proxyAddresses aggiornate in 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 update user preceduti da un evento Add verified domain .

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 Connessione 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 come e UserPrincipalNameproxyAddresses sono coerenti, quindi stiamo lavorando per visualizzare solo nei log di controllo 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.

Approfondimenti tecnici

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 sincronizzazione di Microsoft Entra Connessione per comprendere gli attributi shadow.

UserPrincipalName

Per gli utenti solo 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 : username@Contoso.onmicrosoft.com.

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 corrisponde a proxyAddresses 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:username@Contoso.onmicrosoft.com.

Per gli utenti sincronizzati, la coerenza significa che proxyAddresses corrisponde al valore proxyAddresses locale (ad esempio 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 back-end sanifica i proxyAddresses incoerenti con un suffisso di dominio non verificato e viene rimosso dall'oggetto in MICROSOFT Entra ID. Se il dominio non verificato viene verificato in un secondo momento, l'operazione back-end ricomputa 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.

Passaggi successivi

Attributi shadow del servizio Microsoft Entra Connessione Sync