Noções básicas sobre atualizações de usuários em massa durante alterações de domínio verificadas
Este 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 do UserManagement nos logs de auditoria que ocorrem durante as alterações de domínio verificadas. O artigo fornece um mergulho profundo na operação de back-end que dispara alterações de objeto em massa no ID do Microsoft Entra.
Sintomas
Os logs de auditoria do Microsoft Entra mostram que várias atualizações de usuário ocorreram no meu locatário do Microsoft Entra. As informações do Ator para esses eventos estão vazias ou mostram N/A.
As atualizações em massa envolvem a UserPrincipalName alteração do domínio alterado do domínio preferencial da organização para o sufixo de domínio padrão *.onmicrosoft.com .
Exemplos de detalhes do log de auditoria
Data da atividade (UTC): 2022-01-27 07:44:05
Atividade: Atualizar usuário
Tipo de ator: Outro
Ator UPN: N/A
Estado: sucesso
Categoria: UserManagement
Serviço: Core Directory
ID alvo: aaaaaa-bbbb-0000-11111-bbbbbbbbbbbbb
Nome do destino: user@contoso.com
Tipo de destino: Usuário
Dentro dos detalhes completos da entrada do log de auditoria, procure a modifiedProperties seção . Esta seção mostra as alterações feitas no objeto de usuário. Os oldValue campos e newValue mostram a alteração do domínio.
"modifiedProperties":
"displayName": "UserPrincipalName",
"oldValue": "[\"user@contoso.onmicrosoft.com\"]",
"newValue": "[\"user@contoso.com\"]"
Causas
Uma razão comum por trás das alterações de objeto em massa é devido a uma operação de back-end não síncrona. Esta operação determina os apropriados UserPrincipalName e proxyAddresses que são atualizados em usuários, grupos ou contatos do Microsoft Entra.
A finalidade dessa operação de back-end 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 Fabrikam.com de domínio verificado ao locatário Contoso.onmicrosoft.com, essa ação acionará a operação de back-end em todos os objetos no locatário. Esse evento é capturado nos logs de auditoria do Microsoft Entra como eventos Update User precedidos por um evento Add verified domain .
Se Fabrikam.com foi 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, você pode se beneficiar do uso do Microsoft Entra Connect para sincronizar dados entre seu diretório local e o Microsoft Entra ID. Esta ação garante que o UserPrincipalName e proxyAddresses são consistentes em ambos os ambientes.
Quando você tenta adicionar ou manter manualmente esses objetos, corre o risco de outra operação de back-end disparar uma alteração em massa.
Analise os seguintes artigos para se familiarizar com esses conceitos:
Considerações
Essa operação de back-end não causa alterações em determinados objetos que:
- não tem uma licença ativa do Microsoft Exchange
- definiram
MSExchRemoteRecipientTypecomo Nulo - não são considerados um recurso compartilhado
Um recurso compartilhado é quando CloudMSExchRecipientDisplayType contém um dos seguintes valores:
MailboxUser(partilhado)PublicFolderConferenceRoomMailboxEquipmentMailboxArbitrationMailboxRoomListTeamMailboxUserGroupMailboxSchedulingMailboxACLableMailboxUserACLableTeamMailboxUser
Para criar mais correlação entre esses dois eventos díspares, a Microsoft está trabalhando na atualização das informações do Ator nos logs de auditoria para identificar essas alterações como acionadas 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 como suas UserPrincipalName e proxyAddresses são consistentes, portanto, estamos trabalhando para exibir apenas nos logs de auditoria as atualizações que causaram uma alteração real no objeto. Essa ação evita o ruído nos logs de auditoria e ajuda os administradores a correlacionar as alterações de usuário restantes 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 dispara alterações de objeto em massa no Microsoft Entra ID. Antes de mergulhar, confira 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, o 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 o ShadowUserPrincipalName ou, no caso de o sufixo de domínio ter sido removido do locatário, converte-o no sufixo de domínio padrão *.onmicrosoft.com .
ProxyAddresses
Para usuários somente na nuvem, consistência significa que a correspondência é um sufixo proxyAddresses de domínio verificado. Quando um proxyAddresses inconsistente é processado, a operação de back-end o converte no sufixo de domínio padrão *.onmicrosoft.com , por exemplo: SMTP:username@Contoso.onmicrosoft.com.
Para usuários sincronizados, consistência significa que os proxyAddresses correspondem ao valor proxyAddresses local (ou seja, ShadowProxyAddresses). Espera-se que os proxyAddresses estejam em sincronia 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 back-end 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 recalculará e adicionará os proxyAddresses de ShadowProxyAddresses de volta ao objeto no ID do Microsoft Entra.
Nota
Para objetos sincronizados, para evitar que a lógica de operação de back-end calcule resultados inesperados, é melhor definir proxyAddresses como um domínio verificado do Microsoft Entra no objeto local.