Entrar no Microsoft Entra ID com o email como ID de logon alternativa (versão prévia)

Observação

Entrar no Microsoft Entra ID com o email como uma ID de logon alternativa é uma versão prévia pública do recurso do Microsoft Entra ID. Para saber mais sobre versões prévias, consulte os Termos de Uso Complementares para Visualizações do Microsoft Azure.

Muitas organizações desejam permitir que os usuários entrem no Microsoft Entra ID usando as mesmas credenciais do ambiente de diretório local. Com essa abordagem, conhecida como autenticação híbrida, os usuários só precisam se lembrar de um conjunto de credenciais.

Algumas organizações não migraram para autenticação híbrida pelos seguintes motivos:

• Por padrão, o Nome da Entidade de Segurança do Usuário (UPN) do Microsoft Entra é definido como o mesmo valor que o UPN local.
• A alteração do UPN do Microsoft Entra cria uma incompatibilidade entre os ambientes locais e o Microsoft Entra, o que pode causar problemas com determinados aplicativos e serviços.
• Por motivos comerciais ou de conformidade, a organização não quer usar o UPN local para entrar no Microsoft Entra ID.

Para mudar para a autenticação híbrida, você pode configurar o Microsoft Entra ID para permitir que os usuários entrem com o email deles como uma ID de logon alternativa. Por exemplo, se Contoso for rebatizado como Fabrikam, em vez de continuar a entrar com o UPN herdado ana@contoso.com, será possível usar o email como uma ID de logon alternativa. Para acessar um aplicativo ou serviço, os usuários devem entrar no Microsoft Entra ID usando emails que não sejam UPN, como o ana@fabrikam.com.

Este artigo mostra como habilitar e usar o email como uma ID de logon alternativa.

Antes de começar

Veja o que há para saber sobre o email como uma ID de logon alternativa:

• O recurso está disponível na edição do Microsoft Entra ID Gratuito e superior.
• O recurso permite a entrada com ProxyAddresses, além do UPN, para usuários do Microsoft Entra autenticados na nuvem. Saiba mais sobre como isso se aplica à colaboração B2B (entre empresas) do Microsoft Entra na seção B2B.
• Quando um usuário entra com um email não UPN, as declarações unique_name e preferred_username (se presentes) no token de ID retornarão o email não UPN.
  • Se o email não UPN em uso ficar obsoleto (não pertence mais ao usuário), essas declarações retornarão o UPN.
• O recurso é compatível com a autenticação gerenciada com PHS (Sincronização de Hash de Senha) ou PTA (autenticação de passagem).
• Há duas opções para configurar essa funcionalidade:
  • Política de HRD (Descoberta de Realm Inicial) – use essa opção para habilitar o recurso em todo o locatário. É necessário ter uma função de Administrador Global, Administrador de Aplicativos ou Administrador de Aplicativos de Nuvem.
  • Política de distribuição em etapas: use essa opção para testar o recurso com grupos específicos do Microsoft Entra. São necessários privilégios de Administrador Global. Ao adicionar um grupo de segurança pela primeira vez para a distribuição em etapas, você tem um limite de 200 usuários para evitar um tempo limite de UX (experiência do usuário). Depois de adicionar o grupo, você poderá adicionar mais usuários diretamente a ele conforme necessário.

Limitações de visualização

No estado de versão prévia atual, as seguintes limitações se aplicam a um email como ID de logon alternativa:

• Experiência do usuário – Usuários pode ver o próprio UPN mesmo quando conectados com o email não UPN. O seguinte comportamento de exemplo pode ser observado:

  • O usuário é solicitado a entrar com UPN quando direcionado para entrar no Microsoft Entra com login_hint=<non-UPN email>.
  • Quando um usuário entra com um email não UPN e insere uma senha incorreta, a página "Inserir a sua senha" é alterada para exibir o UPN.
  • Em alguns sites e aplicativos da Microsoft, como o Microsoft Office, o controle Gerenciador de Contas normalmente exibido no canto superior direito, pode exibir o UPN do usuário em vez do email não UPN usado para entrar.

• Fluxos sem suporte – Atualmente, alguns fluxos não são compatíveis com emails não UPN, como os seguintes:

  • O Identity Protection não corresponde emails não UPN à detecção de risco de Credenciais Vazadas. Essa detecção de risco usa o UPN para fazer a correspondência das credenciais que vazaram. Para saber mais, confira Como investigar risco.
  • Quando um usuário está conectado por um email não UPN, ele não pode alterar sua senha. A SSPR (redefinição de senha self-service) do Microsoft Entra deve funcionar conforme o esperado. Durante a SSPR, o usuário poderá acabar vendo seu UPN ao verificar sua identidade usando um email não UPN.

• Cenários sem suporte – Os cenários a seguir não têm suporte. Entrar com email não UPN em:

  • Dispositivos ingressados de forma híbrida no Microsoft Entra
  • Dispositivos ingressados no Microsoft Entra
  • Dispositivos registrados no Microsoft Entra
  • Credenciais da senha de proprietário do recurso (ROPC)
  • Políticas de logon único e proteção de aplicativo na plataforma móvel
  • Autenticações herdadas, como POP3 e SMTP
  • Skype for Business

• Aplicativos sem suporte – alguns aplicativos de terceiros podem não funcionar conforme o esperado se presumirem que as declarações unique_name ou preferred_username são imutáveis ou sempre corresponderão a um atributo de usuário específico, como o UPN.

• Registro em log – As alterações feitas na configuração dessa funcionalidade na política HRD não são mostradas explicitamente nos logs de auditoria.

• Política de distribuição em etapas – As seguintes limitações se aplicam somente quando o recurso é habilitado usando a política de distribuição em etapas:

  • O recurso não funciona conforme o esperado para usuários que estão incluídos em outras políticas de distribuição em etapas.
  • A política de distribuição em etapas é compatível com um máximo de 10 grupos por recurso.
  • A política de distribuição em etapas não é compatível com grupos aninhados.
  • A política de distribuição em etapas não é compatível com grupos dinâmicos.
  • Os objetos de contato dentro do grupo impedirão que o grupo seja adicionado a uma política de distribuição em etapas.

• Valores duplicados – Em um locatário, o UPN de um usuário somente em nuvem pode ter o mesmo valor que o endereço proxy de outro usuário sincronizado no diretório local. Nesse cenário, com a funcionalidade habilitada, o usuário somente em nuvem não poderá entrar com seu UPN. Veja mais sobre esse problema na seção Solucionar problemas.

Visão geral das opções de ID de logon alternativa

Para entrar no Microsoft Entra ID, os usuários inserem um valor que identifica exclusivamente a conta. Historicamente, você só podia usar o UPN do Microsoft Entra como identificador de entrada.

Para organizações em que o UPN local é o email de conexão preferencial do usuário, essa abordagem era excelente. Essas organizações definiam o UPN do Microsoft Entra exatamente com o mesmo valor do UPN local, e os usuários tinham uma experiência de entrada consistente.

ID de logon alternativa no AD FS

No entanto, em algumas organizações, o UPN local não é usado como um identificador de entrada. Nos ambientes locais, você teria que configurar o AD DS local para permitir a entrada com uma ID de logon alternativa. Definir o UPN do Microsoft Entra com o mesmo valor do UPN local não é uma opção, pois o Microsoft Entra ID exigiria que os usuários entrassem com esse valor.

ID de logon alternativa no Microsoft Entra Connect

A solução típica para esse problema era definir o UPN do Microsoft Entra como o endereço de email com o qual o usuário espera entrar. Essa abordagem funciona, mas resulta em UPNs diferentes entre o AD local e o Microsoft Entra ID, e essa configuração não é compatível com todas as cargas de trabalho do Microsoft 365.

Email como uma ID de logon alternativa

Uma abordagem diferente é sincronizar o Microsoft Entra ID e os UPNs locais com o mesmo valor e, em seguida, configurar o Microsoft Entra ID para permitir que os usuários entrem no Microsoft Entra ID com um email verificado. Para fornecer essa capacidade, defina um ou mais endereços de email no atributo ProxyAddresses do usuário no diretório local. Os ProxyAddresses são então sincronizados com o Microsoft Entra ID automaticamente usando o Microsoft Entra Connect.

Opção	Descrição
ID de logon alternativa no AD FS	Habilite a entrada com um atributo alternativo (como Email) para usuários do AD FS.
ID de Logon Alternativa no Microsoft Entra Connect	Sincronize um atributo alternativo (como Email) como o UPN do Microsoft Entra.
Email como uma ID de logon alternativa	Habilite a entrada com ProxyAddresses de domínio verificado para usuários do Microsoft Entra.

Sincronizar endereços de email de entrada com o Microsoft Entra ID

A autenticação tradicional do Active Directory Domain Services (AD DS) ou dos Serviços de Federação do Active Directory (AD FS) ocorre diretamente em sua rede e é tratada pela sua infraestrutura de AD DS. Com a autenticação híbrida, os usuários podem entrar diretamente no Microsoft Entra ID.

Para dar suporte a essa abordagem de autenticação híbrida, sincronize o ambiente AD DS local com o Microsoft Entra ID usando o Microsoft Entra Connect e o configure para usar PHS ou PTA. Para obter mais informações, confira Escolher o método de autenticação correto para sua solução de identidade híbrida Microsoft Entra.

Em ambas as opções de configuração, o usuário envia seu nome de usuário e senha para o Microsoft Entra ID, que valida as credenciais e emite um tíquete. Quando os usuários entram no Microsoft Entra ID, isso elimina a necessidade da organização hospedar e gerenciar uma infraestrutura do AD FS.

Um dos atributos do usuário que é sincronizado automaticamente pelo Microsoft Entra Connect é o ProxyAddresses. Se os usuários tiverem um endereço de email definido no ambiente do AD DS local como parte do atributo ProxyAddresses, ele será automaticamente sincronizado com o Microsoft Entra ID. Esse endereço de email pode ser usado diretamente no processo de entrada do Microsoft Entra como uma ID de logon alternativa.

Importante

Somente emails em domínios verificados para o locatário são sincronizados com o Microsoft Entra ID. Cada locatário do Microsoft Entra tem um ou mais domínios verificados, para os quais você comprovou a propriedade, e estão associados exclusivamente ao seu locatário.

Para obter mais informações, confira Adicionar e verificar um nome de domínio personalizado no Microsoft Entra ID.

Entrada do usuário B2B convidado com um endereço de email

O email como ID de logon alternativa se aplica à colaboração B2B do Microsoft Entra em um modelo "traga seus próprios identificadores de entrada". Quando o email como ID de logon alternativa está habilitado no locatário inicial, os usuários do Microsoft Entra podem entrar como convidado com um email não UPN no ponto de extremidade do locatário do recurso. Nenhuma ação é necessária do locatário do recurso para habilitar essa funcionalidade.

Observação

Quando uma ID de login alternativa é usada em um ponto de extremidade de um locatário de recurso que não tem a funcionalidade habilitada, o processo de login funcionará sem problemas, mas o SSO será interrompido.

Habilitar a entrada do usuário com um endereço de email

Observação

Essa opção de configuração usa a política HRD. Para mais informações, consulte o tipo de recursohomeRealmDiscoveryPolicy.

Depois que os usuários com o atributo ProxyAddresses aplicado forem sincronizados com o Microsoft Entra ID usando o Microsoft Entra Connect, será necessário habilitar o recurso para que os usuários entrem com o email como uma ID de logon alternativa para o locatário. Esse recurso instrui os servidores de logon do Microsoft Entra a verificar o identificador de entrada não apenas em relação aos valores UPN, mas também em relação aos valores de ProxyAddresses do endereço de email.

Durante a versão prévia, atualmente você precisa de permissões de Administrador Global para habilitar a entrada com email como uma ID de logon alternativa. Você pode usar o Centro de administração do Microsoft Entra ou o PowerShell do Graph para configurar o recurso.

Centro de administração do Microsoft Entra

Dica

As etapas neste artigo podem variar ligeiramente com base no portal do qual você começa.

1. Entre no centro de administração do Microsoft Entra como Administrador global.

2. No menu de navegação no lado esquerdo da janela do Microsoft Entra, selecione Microsoft Entra Connect > Email como ID de logon alternativa.

   

3. Clique na caixa de seleção ao lado de Email como uma ID de logon alternativa.

4. Clique em Save (Salvar).

   

Com a política aplicada, pode levar até uma hora para que ela seja propagada e os usuários possam entrar com a ID de logon alternativa.

PowerShell

Observação

Essa opção de configuração usa a política HRD. Para mais informações, consulte o tipo de recursohomeRealmDiscoveryPolicy.

Depois que os usuários com o atributo ProxyAddresses aplicado forem sincronizados com o Microsoft Entra ID usando o Microsoft Entra Connect, será necessário habilitar o recurso para que os usuários entrem com o email como uma ID de logon alternativa para o locatário. Esse recurso instrui os servidores de logon do Microsoft Entra a verificar o identificador de entrada não apenas em relação aos valores UPN, mas também em relação aos valores de ProxyAddresses do endereço de email.

Você precisa de privilégios de Administrador Global para concluir as seguintes etapas:

1. Abra uma sessão do PowerShell como administrador e instale o módulo Microsoft.Graph usando o cmdlet Install-Module:

   Install-Module Microsoft.Graph
   

   Para obter mais informações sobre a instalação, confira Instalar o SDK do PowerShell do Microsoft Graph.

2. Entre no locatário do Microsoft Entra usando o cmdlet Connect-MgGraph:

   Connect-MgGraph -Scopes "Policy.ReadWrite.ApplicationConfiguration" -TenantId organizations
   

   O comando solicitará que você se autentique usando um navegador da Web.

3. Verifique se uma política HomeRealmDiscoveryPolicy já existe em seu locatário usando o cmdlet Get-MgPolicyHomeRealmDiscoveryPolicy da seguinte maneira:

   Get-MgPolicyHomeRealmDiscoveryPolicy
   

4. Se não houver políticas configuradas no momento, o comando não retornará nada. Se uma política for retornada, ignore essa etapa e vá para a próxima etapa para atualizar uma política atual.

   Para adicionar HomeRealmDiscoveryPolicy ao locatário, use o cmdlet New-MgPolicyHomeRealmDiscoveryPolicy e defina o atributo AlternateIdLogin como "Enabled": true, conforme mostrado no seguinte exemplo:

   $AzureADPolicyDefinition = @(
     @{
        "HomeRealmDiscoveryPolicy" = @{
           "AlternateIdLogin" = @{
              "Enabled" = $true
           }
        }
     } | ConvertTo-JSON -Compress
   )
   
   $AzureADPolicyParameters = @{
     Definition            = $AzureADPolicyDefinition
     DisplayName           = "BasicAutoAccelerationPolicy"
     AdditionalProperties  = @{ IsOrganizationDefault = $true }
   }
   
   New-MgPolicyHomeRealmDiscoveryPolicy @AzureADPolicyParameters
   

   Quando a política tiver sido criada com êxito, o comando retornará a ID da política, conforme mostrado na seguinte saída de exemplo:

   Definition                                                           DeletedDateTime Description DisplayName                 Id            IsOrganizationDefault
   ----------                                                           --------------- ----------- -----------                 --            ---------------------
   {{"HomeRealmDiscoveryPolicy":{"AlternateIdLogin":{"Enabled":true}}}}                             BasicAutoAccelerationPolicy HRD_POLICY_ID True
   

5. Se já houver uma política configurada, verifique se o atributo AlternateIdLogin está habilitado, conforme mostrado no seguinte exemplo de saída de política:

   Definition                                                           DeletedDateTime Description DisplayName                 Id            IsOrganizationDefault
   ----------                                                           --------------- ----------- -----------                 --            ---------------------
   {{"HomeRealmDiscoveryPolicy":{"AlternateIdLogin":{"Enabled":true}}}}                             BasicAutoAccelerationPolicy HRD_POLICY_ID True
   

   Se a política existir, mas o atributo AlternateIdLogin não estiver presente ou habilitado, ou se outros atributos existirem na política que você quer preservar, atualize a política existente usando o cmdlet Update-MgPolicyHomeRealmDiscoveryPolicy.

   Importante

   Ao atualizar a política, inclua as configurações antigas e o novo atributo AlternateIdLogin.

   O seguinte exemplo adiciona o atributo AlternateIdLogin e preserva o atributo AllowCloudPasswordValidation, que já foi definido:

   $AzureADPolicyDefinition = @(
     @{
        "HomeRealmDiscoveryPolicy" = @{
           "AllowCloudPasswordValidation" = $true
           "AlternateIdLogin" = @{
              "Enabled" = $true
           }
        }
     } | ConvertTo-JSON -Compress
   )
   
   $AzureADPolicyParameters = @{
     HomeRealmDiscoveryPolicyId = "HRD_POLICY_ID"
     Definition                 = $AzureADPolicyDefinition
     DisplayName                = "BasicAutoAccelerationPolicy"
     AdditionalProperties       = @{ "IsOrganizationDefault" = $true }
   }
   
   Update-MgPolicyHomeRealmDiscoveryPolicy @AzureADPolicyParameters
   

   Confirme se a política atualizada mostra as alterações e se o atributo AlternateIdLogin agora está habilitado:

   Get-MgPolicyHomeRealmDiscoveryPolicy
   

Observação

Com a política aplicada, pode levar até uma hora para que ela seja propagada e para que os usuários possam entrar usando o email como uma ID de logon alternativa.

Remoção de políticas

Para remover uma política HRD, use o cmdlet Remove-MgPolicyHomeRealmDiscoveryPolicy:

Remove-MgPolicyHomeRealmDiscoveryPolicy -HomeRealmDiscoveryPolicyId "HRD_POLICY_ID"

Habilitar a distribuição em etapas para testar as credenciais do usuário com um endereço de email

Observação

Esta opção de configuração usa a política de distribuição em etapas. Para mais informações, consulte tipo de recurso featureRolloutPolicy.

A política de distribuição em etapas permite que os administradores de locatários habilitem recursos para grupos específicos do Microsoft Entra. É recomendável que os administradores de locatários usem a distribuição em etapas para testar as credenciais do usuário com um endereço de email. Quando os administradores estiverem prontos para implantar esse recurso em todo o locatário, eles deverão usar uma política de HRD.

Você precisa de permissões de Administrador Global para concluir as seguintes etapas:

1. Abra uma sessão do PowerShell como administrador e instale o módulo Microsoft.Graph.Beta usando o cmdlet Install-Module:

   Install-Module Microsoft.Graph.Beta
   

   Se solicitado, escolha Y para instalar o NuGet ou instalar a partir de um repositório não confiável.

2. Entre no locatário do Microsoft Entra usando o Connect-MgGraph :

   Connect-MgGraph -Scopes "Directory.ReadWrite.All"
   

   O comando retorna informações sobre sua conta, seu ambiente e sua ID de locatário.

3. Liste todas as políticas de distribuição em etapas existentes usando o seguinte cmdlet:

   Get-MgBetaPolicyFeatureRolloutPolicy
   

4. Se não houver políticas de distribuição em etapas existentes para esse recurso, crie uma política de distribuição em etapas e anote a ID da política:

   $MgPolicyFeatureRolloutPolicy = @{
   Feature    = "EmailAsAlternateId"
   DisplayName = "EmailAsAlternateId Rollout Policy"
   IsEnabled   = $true
   }
   New-MgBetaPolicyFeatureRolloutPolicy @MgPolicyFeatureRolloutPolicy
   

5. Localize a ID do directoryObject para o grupo que será adicionado à política de distribuição em etapas. Observe o valor retornado para o parâmetro Id, pois ele será usado na próxima etapa.

   Get-MgGroup -Filter "DisplayName eq 'Name of group to be added to the staged rollout policy'"
   

6. Adicione o grupo à política de distribuição em etapas, conforme mostrado no exemplo a seguir. Substitua o valor no parâmetro -FeatureRolloutPolicyId pelo valor retornado para a ID de política na etapa 4 e substitua o valor no parâmetro -OdataId pela Id anotada na etapa 5. Pode levar até uma hora para que os usuários do grupo possam entrar no Microsoft Entra ID com o email como ID de logon alternativa.

   New-MgBetaDirectoryFeatureRolloutPolicyApplyToByRef `
      -FeatureRolloutPolicyId "ROLLOUT_POLICY_ID" `
      -OdataId "https://graph.microsoft.com/v1.0/directoryObjects/{GROUP_OBJECT_ID}"
   

Para novos membros adicionados ao grupo, pode levar até 24 horas para que eles possam entrar no Microsoft Entra ID com o email como ID de logon alternativa.

Remoção de grupos

Para remover um grupo de uma política de distribuição em etapas, execute o seguinte comando:

Remove-MgBetaPolicyFeatureRolloutPolicyApplyToByRef -FeatureRolloutPolicyId "ROLLOUT_POLICY_ID" -DirectoryObjectId "GROUP_OBJECT_ID"

Remoção de políticas

Para remover uma política de distribuição em etapas, primeiro desabilite a política e remova-a do sistema:

Update-MgBetaPolicyFeatureRolloutPolicy -FeatureRolloutPolicyId "ROLLOUT_POLICY_ID" -IsEnabled:$false 
Remove-MgBetaPolicyFeatureRolloutPolicy -FeatureRolloutPolicyId "ROLLOUT_POLICY_ID"

Testar a entrada do usuário com um endereço de email

Para testar se os usuários podem entrar com email, acesse https://myprofile.microsoft.com e entre com um email não UPN, como balas@fabrikam.com. A experiência de entrada deve ser parecida com a de uma entrada baseada em UPN.

Solucionar problemas

Se os usuários tiverem problemas para entrar usando o endereço de email, examine as seguintes etapas de solução de problemas:

1. Certifique-se de que tenha passado pelo menos uma hora desde que o email como uma ID de logon alternativa foi habilitado. Se o usuário foi adicionado recentemente a um grupo da política de distribuição em etapas, certifique-se de que tenham passado pelo menos 24 horas desde que ele foi adicionado ao grupo.

2. Se estiver usando a política HRD, confirme se o Microsoft Entra ID HomeRealmDiscoveryPolicy tem a propriedade de definição AlternateIdLogin definida como "Enabled": true e a propriedade IsOrganizationDefault definida como True:

   Get-MgBetaPolicyHomeRealmDiscoveryPolicy | Format-List *
   

   Se estiver usando a política de distribuição em etapas, confirme se ProxyAddresses do Microsoft Entra ID tem a propriedade IsEnabled definida como True:

   Get-MgBetaPolicyFeatureRolloutPolicy
   

3. Verifique se a conta de usuário tem o endereço de email definido no atributo ProxyAddresses no Microsoft Entra ID.

Logs de entrada

Para obter mais informações, veja os logs de entrada no Microsoft Entra ID. As entradas com email como uma ID de logon alternativa emitirão proxyAddress no campo Tipo de identificador de entrada e o nome de usuário inserido no campo Identificador de entrada.

Valores conflitantes entre usuários somente na nuvem e usuários sincronizados

Em um locatário, o UPN de um usuário somente na nuvem pode acabar tendo o mesmo valor que o endereço proxy de outro usuário sincronizado a partir do diretório local. Nesse cenário, com a funcionalidade habilitada, o usuário somente em nuvem não poderá entrar com seu UPN. Aqui estão as etapas para detectar instâncias desse problema.

1. Abra uma sessão do PowerShell como administrador e instale o módulo AzureADPreview usando o cmdlet Install-Module:

   Install-Module Microsoft.Graph.Beta
   

   Se solicitado, escolha Y para instalar o NuGet ou instalar a partir de um repositório não confiável.

2. Entre no locatário do Microsoft Entra como Administrador Global usando o cmdlet Connect-AzureAD:

   Connect-MgGraph -Scopes "User.Read.All"
   

3. Veja os usuários afetados.

   # Get all users
   $allUsers = Get-MgUser -All
   
   # Get list of proxy addresses from all synced users
   $syncedProxyAddresses = $allUsers |
       Where-Object {$_.ImmutableId} |
       Select-Object -ExpandProperty ProxyAddresses |
       ForEach-Object {$_ -Replace "smtp:", ""}
   
   # Get list of user principal names from all cloud-only users
   $cloudOnlyUserPrincipalNames = $allUsers |
       Where-Object {!$_.ImmutableId} |
       Select-Object -ExpandProperty UserPrincipalName
   
   # Get intersection of two lists
   $duplicateValues = $syncedProxyAddresses |
       Where-Object {$cloudOnlyUserPrincipalNames -Contains $_}
   

4. Para dar saída dos usuários afetados:

   # Output affected synced users
   $allUsers |
       Where-Object {$_.ImmutableId -And ($_.ProxyAddresses | Where-Object {($duplicateValues | ForEach-Object {"smtp:$_"}) -Contains $_}).Length -GT 0} |
       Select-Object ObjectId, DisplayName, UserPrincipalName, ProxyAddresses, ImmutableId, UserType
   
   # Output affected cloud-only users
   $allUsers |
       Where-Object {!$_.ImmutableId -And $duplicateValues -Contains $_.UserPrincipalName} |
       Select-Object ObjectId, DisplayName, UserPrincipalName, ProxyAddresses, ImmutableId, UserType
   

5. Para dar saída dos usuários afetados como CSV:

   # Output affected users to CSV
   $allUsers |
       Where-Object {
           ($_.ImmutableId -And ($_.ProxyAddresses | Where-Object {($duplicateValues | ForEach-Object {"smtp:$_"}) -Contains $_}).Length -GT 0) -Or
           (!$_.ImmutableId -And $duplicateValues -Contains $_.UserPrincipalName)
       } |
       Select-Object ObjectId, DisplayName, UserPrincipalName, @{n="ProxyAddresses"; e={$_.ProxyAddresses -Join ','}}, @{n="IsSyncedUser"; e={$_.ImmutableId.Length -GT 0}}, UserType |
       Export-Csv -Path .\AffectedUsers.csv -NoTypeInformation
   

Próximas etapas

Para saber mais sobre a identidade híbrida, como o proxy de aplicativo do Microsoft Entra ou o Microsoft Entra Domain Services, confira Identidade híbrida do Microsoft Entra para acesso e gerenciamento de cargas de trabalho no local.

Para obter mais informações sobre operações de identidade híbrida, veja Como a sincronização de hash de senha ou a autenticação de passagem funcionam.