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 obter mais informações sobre versões prévias, consulte Termos de Uso Complementares para Versões Prévias 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 Principal do Usuário (UPN) do Microsoft Entra é definido com o mesmo valor do 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 a Contoso for renomeada para Fabrikam, o email poderá ser usado como uma ID de logon alternativa, em vez de continuar a entrar com o UPN herdado ana@contoso.com. 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 habilita 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 (business-to-business) da Microsoft Entra na seção B2B.
• Quando um usuário entra com um email que não é UPN, as declarações unique_name e preferred_username (se presentes) no token de identificação 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 o recurso:
  • Política de Descoberta de Reino Doméstico (HRD) – use essa opção para habilitar o recurso para todo o tenant. Pelo menos a função de Administrador de Aplicativos é necessária.
  • Política de distribuição em etapas – use essa opção para testar o recurso com grupos específicos do Microsoft Entra. 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 da versão prévia

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 – os usuários podem ver seu UPN, mesmo quando se conectarem com seu email não UPN. O seguinte comportamento de exemplo pode ser observado:

  • O usuário é solicitado a fazer login com UPN quando direcionado para o login do 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 "Insira sua senha" muda para exibir o UPN.
  • Em alguns sites e aplicativos da Microsoft, como o Microsoft Office, o controle do 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 – alguns fluxos atualmente não são compatíveis com emails não UPN, como o seguinte:

  • A Proteção de ID do Microsoft Entra não associa emails que não sejam UPN à detecção de risco de Credenciais Vazadas. Essa detecção de risco usa o UPN para identificar credenciais que vazaram. Para obter mais informações, consulte Como investigar o 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 o SSPR, o usuário poderá ver seu UPN ao verificar sua identidade usando um email não UPN.

• Cenários sem suporte – não há suporte para os cenários a seguir. Entrar com email que não é UPN para:

  • Dispositivos híbridos ingressados no Microsoft Entra
  • Dispositivos ingressados no Microsoft Entra
  • Dispositivos registrados do Microsoft Entra
  • Sign-On individual e Políticas de Proteção de Aplicativos na Plataforma Móvel
  • Autenticações herdadas, como POP3 e SMTP

• Aplicativos sem suporte – alguns aplicativos de terceiros podem não funcionar como esperado se assumirem 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 UPN.

• Log – as alterações feitas na configuração do recurso na política de HRD não são mostradas explicitamente nos registros de auditoria.

• Política de distribuição em etapas – as seguintes limitações se aplicam somente quando o recurso está 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 suporta 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 de associação dinâmica.
  • 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 – dentro de um locatário, o UPN de um usuário somente na nuvem pode ser o mesmo valor que o endereço proxy de outro usuário sincronizado do diretório local. Nesse cenário, com a funcionalidade habilitada, o usuário somente em nuvem não poderá entrar com seu UPN. Mais informações sobre esse problema na seção Solução de 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 alternativo para 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, você define um ou mais endereços de email no atributo ProxyAddresses do usuário no diretório local. Os ProxyAddresses são sincronizados com a ID do Microsoft Entra automaticamente usando o Microsoft Entra Connect.

Opção	Descrição
ID de logon alternativa para o AD FS	Habilite o login com um atributo alternativo (como e-mail) 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 o logon com ProxyAddresses de domínio verificado para usuários do Microsoft Entra.

Sincronizar endereços de email de login para 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 seu ambiente do AD DS local com a ID do Microsoft Entra usando o Microsoft Entra Connect e configure-o para usar PHS ou PTA. Para obter mais informações, consulte Escolher o método de autenticação correto para sua solução de identidade híbrida do 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 de usuário sincronizados automaticamente pelo Microsoft Entra Connect é 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á sincronizado automaticamente com a ID do Microsoft Entra. 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, consulte Adicionar e verificar um nome de domínio personalizado na ID do Microsoft Entra.

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

O email como uma ID de login alternativa se aplica à colaboração do Microsoft Entra B2B em um modelo de "traga seus próprios identificadores de login". Quando o email como ID de logon alternativa estiver 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 logon alternativa é usada em um ponto de extremidade de um locatário de recurso que não tem a funcionalidade habilitada, o processo de logon 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 obter mais informações, consulte o tipo de recurso homeRealmDiscoveryPolicy.

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

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 Entra Microsoft

1. Entre no Centro de administração do Microsoft Entra como pelo menos um Administrador de Identidade Híbrida.

2. Navegue até Entra ID>Entra Connect>Connect Sync

3. Selecione Email como ID de logon alternativa**.

   

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

5. Clique em 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 obter mais informações, consulte o tipo de recurso homeRealmDiscoveryPolicy.

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

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

   Install-Module Microsoft.Graph
   

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

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 um HomeRealmDiscoveryPolicy já existe em seu tenant usando o cmdlet da seguinte forma:

   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 o HomeRealmDiscoveryPolicy ao locatário, use o New-MgPolicyHomeRealmDiscoveryPolicy cmdlet e defina o atributo AlternateIdLogin como "Enabled": true , conforme mostrado no exemplo a seguir:

   $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 na seguinte saída de política de exemplo:

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

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

   Importante

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

   O exemplo a seguir adiciona o atributo AlternateIdLogin e preserva o atributo AllowCloudPasswordValidation que foi definido anteriormente:

   $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 suas 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 o login 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 obter mais informações, consulte o recurso de tipo 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 o lançamento gradual para testar o login 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 a política de HRD.

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, selecione Y para instalar o NuGet ou instalar em um repositório não confiável.

2. Entre no locatário do Microsoft Entra usando o cmdlet 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 de ID , pois ele será usado na próxima etapa.

   Get-MgBetaGroup -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 da 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 o login 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 login deve parecer e funcionar da mesma forma que o login com 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, certifique-se de que o Microsoft Entra ID HomeRealmDiscoveryPolicy tem a propriedade AlternateIdLogin definida como "Enabled": verdadeiro e a propriedade IsOrganizationDefault definida como Verdadeiro:

   Get-MgBetaPolicyHomeRealmDiscoveryPolicy | Format-List *
   

   Se estiver usando a política de implementação gradual, confirme se a FeatureRolloutPolicy do Microsoft Entra ID tem a propriedade IsEnabled definida como True:

   Get-MgBetaPolicyFeatureRolloutPolicy
   

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

Logs de entrada

Você pode examinar os logs de entrada na ID do Microsoft Entra para obter mais informações. As entradas com email como uma ID de logon alternativa emitirão proxyAddress o 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 Microsoft Graph usando o cmdlet Install-Module :

   Install-Module Microsoft.Graph.Authentication
   

   Se solicitado, selecione Y para instalar o NuGet ou instalar em um repositório não confiável.

2. Conecte-se ao Microsoft Graph:

   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 exibir os 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 exportar os usuários afetados em 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, consulte a 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, consulte como a sincronização de hash de senha ou a sincronização de autenticação de passagem funcionam.