Noções básicas sobre atualizações de usuários em massa durante alterações de domínio verificadas

Esse artigo descreve um cenário comum em que os logs de auditoria exibem muitas UserPrincipalName atualizações acionadas por uma alteração de domínio verificada. Este artigo explica as causas e considerações para atualizações UserManagement nos logs de auditoria que ocorrem durante as alterações de domínio verificadas. O artigo fornece um aprofundamento na operação de back-end que dispara alterações de objeto em massa no Microsoft Entra ID.

Sintomas

Os logs de auditoria do Microsoft Entra mostram que várias atualizações de usuário ocorreram em meu locatário do Microsoft Entra. As informações doAtor para esses eventos estão vazias ou mostram N/A.

As atualizações em massa envolvem a alteração do domínio UserPrincipalName alterado do domínio preferencial da organização para o sufixo de domínio *.onmicrosoft.com padrão.

Detalhes do registro de auditoria de amostra

Data da atividade (UTC): 27/01/2022 07:44:05

Atividade: Atualizar usuário

Tipo de ator: Outro

Ator UPN: N/A

Status: sucesso

Categoria: UserManagement

Serviço: Diretório Principal

ID de destino: aaaaaaaaa-bbbb-0000-11111-bbbbbbbbbbbbb

Nome do destino: user@contoso.com

Tipo de destino: Usuário

Nos detalhes completos da entrada do log de auditoria, procure a seção modifiedProperties. Essa seção mostra as alterações feitas no objeto de usuário. Os campos oldValue e newValue mostram a mudança de domínio.

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

Causas

Um motivo comum por trás das alterações em massa de objetos é devido a uma operação de back-end não síncrona. Essa operação determina os UserPrincipalName e proxyAddresses apropriados que são atualizados em usuários, grupos ou contatos do Microsoft Entra.

A finalidade dessa operação de backend garante que UserPrincipalName e proxyAddresses sejam consistentes no Microsoft Entra ID a qualquer momento. Uma alteração explícita, como uma alteração de domínio verificada, aciona essa operação.

Por exemplo, se você adicionar um domínio verificado Fabrikam.com ao seu locatário Contoso.onmicrosoft.com, essa ação disparará a operação de back-end em todos os objetos do locatário. Esse evento é capturado nos logs de auditoria do Microsoft Entra como eventos Atualizar usuário precedidos por um evento Adicionar domínio verificado.

Se Fabrikam.com tiver sido removido do locatário Contoso.onmicrosoft.com, todos os eventos Atualizar usuário serão precedidos por um evento Remover domínio verificado.

Resolução

Se você encontrou esse problema, poderá se beneficiar do uso do Microsoft Entra Connect para sincronizar dados entre seu diretório local e o Microsoft Entra ID. Essa ação garante que UserPrincipalName e proxyAddresses sejam consistentes em ambos os ambientes.

Ao tentar adicionar ou manter manualmente esses objetos, você corre o risco de outra operação de back-end acionar uma alteração em massa.

Revise os seguintes artigos para se familiarizar com esses conceitos:

• Preenchimento de UserPrincipalName do Microsoft Entra

• Como o atributo proxyAddresses é preenchido no Microsoft Entra ID

Considerações

Essa operação de back-end não causa alterações em determinados objetos que:

• não tenho uma licença ativa do Microsoft Exchange
• tenha MSExchRemoteRecipientType definido como Nulo
• não são considerados um recurso compartilhado

Um recurso compartilhado ocorre quando CloudMSExchRecipientDisplayType contém um dos seguintes valores:

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

Para construir uma maior correlação entre esses dois eventos díspares, a Microsoft está a trabalhar na atualização das informações do Ator nos registos de auditoria para identificar essas alterações como desencadeadas por uma alteração de domínio verificada. Essa ação ajuda a verificar quando o evento de alteração de domínio verificado ocorreu e começou a atualizar em massa os objetos no locatário.

Na maioria dos casos, não há alterações nos usuários UserPrincipalName e proxyAddresses são consistentes, por isso estamos trabalhando para exibir apenas nos logs de auditoria as atualizações que causaram uma alteração real no objeto. Essa ação evita ruídos nos logs de auditoria e ajuda os administradores a correlacionar as alterações restantes do usuário com eventos de alteração de domínio verificados.

Aprofundamento

Quer saber mais sobre o que está acontecendo nos bastidores? Aqui está um mergulho profundo na operação de back-end que aciona alterações em massa de objetos no Microsoft Entra ID. Antes de começar, verifique o artigo Atributos de sombra do serviço Microsoft Entra Connect Sync para entender os atributos de sombra.

UserPrincipalName

Para usuários somente na nuvem, UserPrincipalName é definido como um sufixo de domínio verificado. Quando um UserPrincipalName inconsistente é processado, a operação o converte no sufixo onmicrosoft.com padrão, por exemplo: username@Contoso.onmicrosoft.com.

Para usuários sincronizados, o UserPrincipalName é definido como um sufixo de domínio verificado e corresponde ao valor local, ShadowUserPrincipalName. Quando um UserPrincipalName inconsistente é processado, a operação reverte para o mesmo valor que ShadowUserPrincipalName ou, caso o sufixo de domínio tenha sido removido do locatário, converte-o para o sufixo de domínio *.onmicrosoft.com padrão.

ProxyAddresses

Para usuários somente na nuvem, consistência significa que proxyAddresses corresponde a um sufixo de domínio verificado. Quando um proxyAddresses inconsistente é processado, a operação de back-end o converte no sufixo de domínio *.onmicrosoft.com padrão, por exemplo: SMTP:username@Contoso.onmicrosoft.com.

Para usuários sincronizados, consistência significa que proxyAddresses corresponde ao valor proxyAddresses local (ou seja, ShadowProxyAddresses). Espera-se que os proxyAddresses estejam sincronizados com ShadowProxyAddresses. Se o usuário sincronizado tiver uma licença do Exchange atribuída, os valores na nuvem e no local deverão corresponder. Esses valores também devem corresponder a um sufixo de domínio verificado.

Nesse cenário, a operação de backend limpa os proxyAddresses inconsistentes com um sufixo de domínio não verificado e é removida do objeto no Microsoft Entra ID. Se esse domínio não verificado for verificado posteriormente, a operação de back-end recalcula e adiciona os proxyAddresses de ShadowProxyAddresses de volta ao objeto no Microsoft Entra ID.

Observação

Para objetos sincronizados, para evitar que a lógica de operação de back-end calcule resultados inesperados, é melhor definir proxyAddresses para um domínio verificado do Microsoft Entra no objeto local.

Próximas etapas

Atributos de sombra do serviço de sincronização do Microsoft Entra Connect