Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Este artigo fornece informações de que você precisa para sincronizar suas senhas de usuário de uma instância do Ative Directory local para uma instância do Microsoft Entra baseada em nuvem.
Como funciona a sincronização de hash de palavra-passe
O serviço de domínio do Active Directory armazena palavras-passe na forma de uma representação de valor de hash, da palavra-passe real do utilizador. Os valores de hash são o resultado de uma função matemática unidirecional (o algoritmo hash). Não há nenhum método para reverter o resultado de uma função unidirecional para a versão de texto simples de uma senha.
Para sincronizar sua senha, o Microsoft Entra Connect Sync extrai seu hash de senha da instância local do Ative Directory. O processamento de segurança extra é aplicado ao hash de senha antes de ser sincronizado com o serviço de autenticação do Microsoft Entra. As senhas são sincronizadas por usuário e em ordem cronológica.
O fluxo de dados real do processo de sincronização do hash de palavras-passe é semelhante à sincronização dos dados do utilizador. No entanto, as senhas são sincronizadas com mais frequência do que a janela de sincronização de diretórios padrão para outros atributos. O processo de sincronização do hash de palavras-passe é executado a cada 2 minutos. Não é possível modificar a frequência desse processo. Quando você sincroniza uma senha, ela substitui a senha de nuvem existente.
A primeira vez que ativa a funcionalidade de sincronização do resumo das palavras-passe, é executada uma sincronização inicial das palavras-passe de todos os utilizadores incluídos no âmbito. A Distribuição em Estágios permite testar recursos de autenticação na nuvem, como autenticação multifator Microsoft Entra, Acesso Condicional, Proteção de Identidade e Governança de Identidade, com grupos de usuários selecionados antes de alternar seus domínios para a autenticação na nuvem. Não é possível definir explicitamente um subconjunto de senhas de usuário que deseja sincronizar. No entanto, se houver vários conectores, é possível desabilitar a sincronização de hash de senha para alguns conectores, mas não para outros, usando o cmdlet Set-ADSyncAADPasswordSyncConfiguration .
Quando você altera uma senha local, a senha atualizada é sincronizada, na maioria das vezes em questão de minutos. A funcionalidade de sincronização do hash de palavras-passe tenta novamente e de forma automática sincronizar as tentativas falhadas. Se ocorrer um erro durante uma tentativa de sincronizar uma palavra-passe, é registado um erro no visualizador de eventos.
A sincronização de uma senha não tem impacto sobre o usuário que está conectado no momento. Se uma alteração de senha for sincronizada enquanto você estiver conectado a um serviço de nuvem, sua sessão atual não será afetada.
Um usuário deve inserir suas credenciais corporativas uma segunda vez para se autenticar na ID do Microsoft Entra, independentemente de estar conectado à rede corporativa. No entanto, esse padrão pode ser minimizado se o usuário selecionar a caixa de seleção Manter-me conectado (KMSI) no login. Esta seleção define um cookie de sessão que ignora a autenticação durante 180 dias. O comportamento KMSI pode ser gerenciado pelo administrador do Microsoft Entra. Além disso, pode reduzir os pedidos de senha configurando a ingressão do Microsoft Entra ou a ingressão híbrida do Microsoft Entra, que conecta automaticamente os utilizadores quando estão nos seus dispositivos corporativos ligados à sua rede corporativa.
Mais vantagens
- Geralmente, a sincronização do hash de palavras-passe é mais simples de implementar do que um serviço de federação. Ele não requer mais servidores e elimina a dependência de um serviço de federação altamente disponível para autenticar usuários.
- A sincronização do hash de palavras-passe também pode ser ativada além da federação. Pode ser usado como uma alternativa se o serviço de federação sofrer uma interrupção.
Nota
A sincronização de senha só é suportada para o usuário do tipo de objeto no Ative Directory. Não há suporte para o tipo de objeto iNetOrgPerson.
Descrição detalhada do funcionamento da sincronização do hash de palavras-passe
A seção a seguir descreve, detalhadamente, como a sincronização de hash de senha funciona entre o Ative Directory e o Microsoft Entra ID.
A cada dois minutos, o agente de sincronização dos hashes de palavras-passe no servidor AD Connect solicita os hashes de palavras-passe armazenados (o atributo unicodePwd) a um servidor de domínio (DC). Essa solicitação é feita por meio do protocolo de replicação padrão MS-DRSR usado para sincronizar dados entre DCs. A conta do Conector dos Serviços de Domínio do Active Directory (ADDS) deve ter as permissões Replicar Alterações de Diretório e Replicar Todas as Alterações de Diretório AD (concedidas por padrão na instalação) para obter os hashes de palavra-passe.
Antes de enviar, o DC criptografa o hash de senha MD4 usando uma chave que é um hash MD5 da chave de sessão RPC (Chamada de Procedimento Remoto) e um salt. Em seguida, envia o resultado para o agente de sincronização do hash de palavras-passe através do RPC. O DC também passa o sal para o agente de sincronização usando o protocolo de replicação DC, para que o agente possa descriptografar o envelope.
Depois de o agente de sincronização do hash de palavras-passe ter o envelope encriptado, utiliza o MD5CryptoServiceProvider e o salt para gerar uma chave para desencriptar os dados recebidos de volta ao formato MD4 original. O agente de sincronização do hash de palavras-passe nunca tem acesso à palavra-passe em texto claro. O agente de sincronização de hash de senha usa MD5 somente para compatibilidade com o protocolo de replicação do controlador de domínio. Esse uso é limitado à comunicação local entre o controlador de domínio e o agente.
O agente de sincronização do hash de palavras-passe expande o hash de palavras-passe binário de 16 bytes para 64 bytes ao converter primeiro o hash numa cadeia hexadecimal de 32 bytes e, em seguida, ao converter esta cadeia de volta num binário com codificação UTF-16.
O agente de sincronização de hash de senha adiciona um "salt" por utilizador, que consiste em 10 bytes, ao binário de 64 bytes para aumentar a proteção do hash original.
Em seguida, o agente de sincronização do hash de palavras-passe combina o hash MD4 com o salt individual para cada utilizador e insere-o na função PBKDF2. São usadas 1.000 iterações do algoritmo de hash com chave HMAC-SHA256 . Para obter mais detalhes, consulte o Microsoft Entra Whitepaper.
O agente de sincronização de hash de senha utiliza o hash de 32 bytes resultante, concatena o sal aleatório por utilizador e o número de iterações SHA256 ao hash (para uso pelo Microsoft Entra ID) para depois transmitir a cadeia de caracteres do Microsoft Entra Connect para o Microsoft Entra ID através de TLS.
Quando um utilizador tenta iniciar sessão no Microsoft Entra ID e introduz a sua palavra-passe, a palavra-passe é executada através do mesmo processo MD4+salt+PBKDF2+HMAC-SHA256. Se o hash resultante corresponder ao hash armazenado no ID do Microsoft Entra, isso significa que o usuário inseriu a senha correta e está autenticado.
Nota
O hash MD4 original não é transmitido para o Microsoft Entra ID. Em vez disso, é transmitido o hash SHA256 do hash MD4 original. Como resultado, se o hash armazenado no Microsoft Entra ID for obtido, ele não poderá ser usado em um ataque de passagem de hash local.
Nota
O valor de hash da senha NUNCA é armazenado em SQL. Esses valores só são processados na memória antes de serem enviados para o Microsoft Entra ID.
Considerações de segurança
Ao sincronizar senhas, a versão de texto simples da sua senha não é exposta ao recurso de sincronização de hash de senha, ao ID do Microsoft Entra ou a qualquer um dos serviços associados.
A autenticação do usuário ocorre no Microsoft Entra e não na própria instância do Active Directory da organização. Os dados de senha SHA256 armazenados no Microsoft Entra ID (um hash do hash MD4 original) são mais seguros do que os armazenados no Ative Directory. Além disso, como esse hash SHA256 não pode ser descriptografado, ele não pode ser trazido de volta ao ambiente do Ative Directory da organização e apresentado como uma senha de usuário válida em um ataque pass-the-hash.
Considerações sobre a política de senha
Existem dois tipos de políticas de palavras-passe que são afetadas ao ativar a sincronização do hash de palavras-passe:
- Política de complexidade de senha
- Política de expiração de senha
Política de complexidade de senha
Quando a sincronização do hash de palavras-passe é ativada, as políticas de complexidade de palavras-passe na instância local do Active Directory substituem as políticas de complexidade na cloud para os utilizadores sincronizados. Você pode usar qualquer senha válida de sua instância local do Ative Directory para acessar os serviços do Microsoft Entra.
Nota
As senhas para usuários criados diretamente na nuvem ainda estão sujeitas às políticas de senha, conforme definido na nuvem.
Política de expiração de senha
Se um usuário estiver no escopo da sincronização de hash de senha, por padrão, a senha na nuvem será definida como Nunca expirar.
Pode continuar a iniciar sessão nos seus serviços na nuvem utilizando uma palavra-passe sincronizada que expirou no seu ambiente local. A sua palavra-passe da nuvem é atualizada da próxima vez que alterar a palavra-passe no ambiente local.
PolíticaDeSenhaNaNuvemParaUtilizadoresComSincronizaçãoDeSenhasAtiva
O recurso Política de Senha na Nuvem para Usuários Password-Synced garante que o Microsoft Entra ID aplique suas políticas de senha nativas (como expiração e bloqueio) para usuários cujas senhas são sincronizadas a partir do Ative Directory local. Esse recurso permite alinhar a mesma política de senha do Ative Directory local com a diretiva de senha do Microsoft Entra, para usuários sincronizados.
Se houver usuários sincronizados que interagem apenas com os serviços integrados do Microsoft Entra e também devem cumprir uma política de expiração de senha, você pode forçá-los a cumprir sua política de expiração de senha do Microsoft Entra ativando o recurso CloudPasswordPolicyForPasswordSyncedUsersEnabled .
Quando CloudPasswordPolicyForPasswordSyncedUsersEnabled está desativado (que é a configuração padrão), o Microsoft Entra Connect atualiza o atributo PasswordPolicies de usuários sincronizados para "DisablePasswordExpiration". Essa atualização é feita sempre que o hash de senha de um usuário é sincronizado com a nuvem e instrui o Microsoft Entra ID a ignorar a política de expiração de senha na nuvem para esse usuário.
Você pode verificar o valor do atributo PasswordPolicies usando o módulo PowerShell do Microsoft Graph com o seguinte comando:
Connect-MgGraph -Scopes "User.ReadWrite.All"
(Get-MgUser -UserId "<UPN or Object ID>" -Property PasswordPolicies).PasswordPolicies
Para habilitar o recurso CloudPasswordPolicyForPasswordSyncedUsersEnabled , execute os seguintes comandos usando o módulo Graph PowerShell:
Connect-MgGraph -Scopes "OnPremDirectorySynchronization.ReadWrite.All"
$OnPremSync = Get-MgDirectoryOnPremiseSynchronization
$OnPremSync.Features.CloudPasswordPolicyForPasswordSyncedUsersEnabled = $true
Update-MgDirectoryOnPremiseSynchronization `
-OnPremisesDirectorySynchronizationId $OnPremSync.Id `
-Features $OnPremSync.Features
Depois que CloudPasswordPolicyForPasswordSyncedUsersEnabled estiver habilitado, o Microsoft Entra ID não remove DisablePasswordExpiration
do atributo PasswordPolicies para cada usuário sincronizado. O valor DisablePasswordExpiration
é removido apenas na próxima sincronização de hash de senha para cada usuário, após a sua próxima alteração de senha no Active Directory local. Além disso, os novos usuários sincronizados com a nuvem não terão PasswordPolicies definido.
Gorjeta
É recomendável habilitar CloudPasswordPolicyForPasswordSyncedUsersEnabled antes de habilitar a sincronização de hash de palavras-passe, para que a sincronização inicial dos hashes de palavras-passe não adicione o valor DisablePasswordExpiration
ao atributo PasswordPolicies para os utilizadores.
Você pode limpar manualmente o PasswordPolicy para um usuário com o seguinte comando usando o módulo Graph PowerShell:
Connect-MgGraph -Scopes "User.ReadWrite.All"
Update-MgUser -UserId "<UPN or Object ID>" -PasswordPolicies None
Nota
Por design, os comandos Update-MgUser e Update-MgDomain PowerShell não funcionam em domínios federados.
Se a política no Ative Directory local for diferente, você poderá atualizar a política de senha do Microsoft Entra para corresponder usando o seguinte comando do PowerShell. O Microsoft Entra suporta uma política de expiração de senha separada por domínio registrado.
Update-MgDomain -DomainId "<___domain name>" -PasswordValidityPeriodInDays <Int32> [-PasswordNotificationWindowInDays <Int32>]
Ressalva: Se houver contas sincronizadas que precisam ter senhas que não expiram no Microsoft Entra ID, por exemplo, uma conta de serviço não usada para entrada interativa, você deve adicionar explicitamente o DisablePasswordExpiration
valor ao atributo PasswordPolicies do usuário no Microsoft Entra ID. Você pode adicionar esse valor executando o seguinte comando:
Update-MgUser -UserID "<UPN or Object ID>" -PasswordPolicies "DisablePasswordExpiration"
Atenção
Quando você usa os Serviços de Domínio do Microsoft Entra, uma sincronização de hash de senha completa acionada pelo Microsoft Entra Connect impõe uma atualização de hash de senha no diretório do Microsoft Entra. Isso garante que todos os hashes de senha sejam replicados de ponta a ponta: do Active Directory local, através do Microsoft Entra ID, até os controladores de domínio hospedados nos Serviços de Domínio Microsoft Entra.
Consequentemente, quando o recurso CloudPasswordPolicyForPasswordSyncedUsersEnabled é habilitado e uma sincronização de hash de senha completa é acionada, o Microsoft Entra limpa o atributo PasswordPolicies para todos os usuários sincronizados, pois esse é o comportamento padrão quando o hash de senha é atualizado na nuvem. Nesses casos, você precisa definir manualmente a DisablePasswordExpiration
política de senha novamente para todas as contas que precisam ter senhas que não expiram no Microsoft Entra ID.
Sincronizando senhas temporárias e "Forçar alteração de senha no próximo logon"
É comum forçar um usuário a alterar sua senha durante o primeiro logon, especialmente depois que ocorre uma redefinição de senha de administrador. É frequentemente conhecido como definir uma senha "temporária" e é concluído marcando o sinalizador "O utilizador deve alterar a palavra-passe no próximo início de sessão" num objeto de utilizador no Active Directory (AD).
A funcionalidade de senha temporária ajuda a garantir que a transferência de propriedade da credencial seja concluída no primeiro uso, para minimizar a duração do tempo em que mais de uma pessoa tem conhecimento dessa credencial.
Para oferecer suporte a senhas temporárias no Microsoft Entra ID para usuários sincronizados, você pode habilitar o recurso ForcePasswordChangeOnLogOn executando os seguintes comandos usando o módulo Graph PowerShell:
$OnPremSync = Get-MgDirectoryOnPremiseSynchronization
$OnPremSync.Features.UserForcePasswordChangeOnLogonEnabled = $true
Update-MgDirectoryOnPremiseSynchronization `
-OnPremisesDirectorySynchronizationId $OnPremSync.Id `
-Features $OnPremSync.Features
Nota
Um novo utilizador criado no Active Directory com a configuração "O utilizador deve alterar a senha no próximo início de sessão" será sempre provisionado no Microsoft Entra ID com uma política de senha para "Forçar a alteração de senha no próximo início de sessão", independentemente do recurso ForcePasswordChangeOnLogOn ser verdadeiro ou falso. Esta é uma lógica interna do Microsoft Entra, uma vez que o novo usuário é provisionado sem uma senha, enquanto o recurso ForcePasswordChangeOnLogOn afeta apenas cenários de redefinição de senha de administrador.
Se um usuário foi criado no Ative Directory com "O usuário deve alterar a senha no próximo logon" antes que o recurso fosse habilitado, o usuário receberá um erro ao entrar. Para corrigir esse problema, desmarque e marque novamente o campo "O usuário deve alterar a senha no próximo logon" em Usuários e Computadores do Ative Directory. Depois de sincronizar as alterações do objeto do usuário, o usuário receberá o prompt esperado no Microsoft Entra ID para atualizar sua senha.
Atenção
Você só deve usar esse recurso quando Self-Service Redefinição de Senha e Write-back de Senha estiverem habilitados no locatário. Isso é para que, se um usuário alterar sua senha via SSPR, ela será sincronizada com o Ative Directory.
Expiração da conta
Se sua organização usa o atributo accountExpires como parte do gerenciamento de conta de usuário, esse atributo não é sincronizado com o Microsoft Entra ID. Como resultado, uma conta expirada do Ative Directory em um ambiente configurado para sincronização de hash de senha ainda estará ativa no Microsoft Entra ID. Recomendamos o uso de um script PowerShell agendado que desabilite as contas do AD dos usuários, assim que elas expirarem (use o cmdlet Set-ADUser ). Por outro lado, durante o processo de remoção da expiração de uma conta do AD, a conta deve ser reativada.
Sincronização de hash de senha e autenticação de cartão inteligente
Os clientes podem exigir que seus usuários façam login em domínios do Windows com um cartão inteligente físico CAC/PIP. Eles fazem isso definindo a propriedade de utilizador SCRIL (Cartão Inteligente Necessário para Logon Interativo) no Active Directory.
Quando o SCRIL é habilitado em um objeto de usuário, a senha do AD do usuário é randomizada pelo controlador de domínio para um valor que ninguém sabe, e o usuário precisa se inscrever e, posteriormente, autenticar no domínio do Windows via cartão inteligente.
Com a sincronização de hash de senha habilitada, esse hash de senha do AD é sincronizado com o ID do Microsoft Entra para que também possa ser usado para autenticação na nuvem.
Nota
Com o lançamento da versão 2.4.18.0 do Microsoft Entra Connect Sync, corrigimos um problema que ocorria quando o SCRIL era reativado em um objeto de usuário. A reativação do SCRIL é comum em cenários em que um usuário perde seu cartão inteligente, exigindo que o SCRIL seja desativado e o usuário receba uma senha temporária até que seja emitido um novo cartão inteligente
Anteriormente, quando o SCRIL foi reativado e uma nova senha aleatória do AD foi gerada, o usuário ainda podia usar sua senha antiga para se autenticar no ID do Microsoft Entra. Agora, o Connect Sync foi atualizado para que a nova senha aleatória do AD seja sincronizada com a ID do Microsoft Entra e a senha antiga não possa ser usada quando o login do cartão inteligente estiver habilitado.
Recomendamos que os administradores realizem qualquer uma das ações abaixo se tiverem usuários com um bit SCRIL em seu Domínio do AD
- Execute uma sincronização completa de hash de senhas seguindo este guia para garantir que as senhas de todos os usuários do SCRIL sejam criptografadas.
- Embaralhe a senha de um usuário individual desativando as definições do SCRIL e depois voltando a ativá-las, ou alterando diretamente a senha do usuário.
- Alterne periodicamente as senhas para usuários SCRIL. Eventualmente, todos esses usuários terão as suas senhas criptografadas
Substituir senhas sincronizadas
Um administrador pode redefinir manualmente sua senha diretamente no Microsoft Entra ID usando o PowerShell (a menos que o usuário esteja em um domínio federado).
Nesse caso, a nova senha substitui sua senha sincronizada e todas as políticas de senha definidas na nuvem são aplicadas à nova senha.
Se você alterar sua senha local novamente, a nova senha será sincronizada com a nuvem e substituirá a senha atualizada manualmente.
A sincronização de uma palavra-passe não tem impacto no utilizador que tem sessão iniciada no Azure. Sua sessão atual do serviço de nuvem não é afetada imediatamente por uma alteração de senha sincronizada que ocorre enquanto você está conectado a um serviço de nuvem. KMSI prolonga a duração desta diferença. Quando o serviço de nuvem exigir que você se autentique novamente, você precisará fornecer sua nova senha.
Processo de sincronização de hash de palavra-passe para os Serviços de Domínio do Microsoft Entra
Se você usar os Serviços de Domínio Microsoft Entra para fornecer autenticação herdada para aplicativos e serviços que precisam usar Kerberos, LDAP ou NTLM, alguns processos extras farão parte do fluxo de sincronização de hash de senha. O Microsoft Entra Connect usa o seguinte processo para sincronizar hashes de senha com a ID do Microsoft Entra para uso nos Serviços de Domínio do Microsoft Entra:
Importante
O Microsoft Entra Connect só deve ser instalado e configurado para sincronização com ambientes ADDS locais. Não há suporte para instalar o Microsoft Entra Connect em um domínio gerenciado pelos Serviços de Domínio Microsoft Entra para sincronizar objetos de volta ao ID do Microsoft Entra.
O Microsoft Entra Connect apenas sincroniza hashes de palavra-passe herdados quando os Serviços de Domínio do Microsoft Entra estão ativados para o respetivo inquilino do Microsoft Entra. As etapas a seguir não serão usadas se você usar apenas o Microsoft Entra Connect para sincronizar um ambiente ADDS local com o Microsoft Entra ID.
Se seus aplicativos herdados não usam autenticação NTLM ou ligações simples LDAP, recomendamos que você desabilite a sincronização de hash de senha NTLM para os Serviços de Domínio Microsoft Entra. Para obter mais informações, veja Desativar os conjuntos de cifras fracos e a sincronização do hash de credenciais NTLM.
- O Microsoft Entra Connect recupera a chave pública para a instância do cliente dos Serviços de Domínio Microsoft Entra.
- Quando um usuário altera sua senha, o controlador de domínio local armazena o resultado da alteração de senha (hashes) em dois atributos:
- unicodePwd para o hash de palavra-passe NTLM.
- supplementalCredentials para o hash da palavra-passe Kerberos.
- O Microsoft Entra Connect deteta alterações de senha por meio do canal de replicação de diretório (alterações de atributo que precisam ser replicadas para outros controladores de domínio).
- Para cada usuário cuja senha foi alterada, o Microsoft Entra Connect executa as seguintes etapas:
- Gera uma chave simétrica AES aleatória de 256 bits.
- Gera um vetor de inicialização aleatório necessário para a primeira rodada de criptografia.
- Extrai os hashes de palavras-passe Kerberos dos atributos supplementalCredentials.
- Verifica a configuração de segurança SyncNtlmPasswords dos Serviços de Domínio Microsoft Entra.
- Se esta definição estiver desativada, será gerado um hash NTLM aleatório de entropia elevada (diferente da palavra-passe do utilizador). Este hash é, em seguida, combinado com os hashes de palavra-passe Kerberos exatos do atributo supplementalCrendetials numa única estrutura de dados.
- Se ativado, combina o valor do atributo unicodePwd com os hashes de palavra-passe Kerberos extraídos do atributo supplementalCredentials numa única estrutura de dados.
- Criptografa a estrutura de dados única usando a chave simétrica AES.
- Criptografa a chave simétrica AES usando a chave pública dos Serviços de Domínio Microsoft Entra do locatário.
- O Microsoft Entra Connect transmite a chave simétrica AES encriptada, a estrutura de dados encriptados que contém os hashes de palavra-passe e o vetor de inicialização para o Microsoft Entra ID.
- O Microsoft Entra ID armazena a chave simétrica AES criptografada, a estrutura de dados criptografados e o vetor de inicialização para o usuário.
- O Microsoft Entra ID envia a chave simétrica AES criptografada, a estrutura de dados criptografados e o vetor de inicialização usando um mecanismo de sincronização interno em uma sessão HTTP criptografada para os Serviços de Domínio Microsoft Entra.
- Os Serviços de Domínio do Microsoft Entra recuperam a chave privada da instância do inquilino do Azure Key Vault.
- Para cada conjunto de dados criptografados (representando a alteração de senha de um único usuário), os Serviços de Domínio do Microsoft Entra executam as seguintes etapas:
- Usa a sua chave privada para desencriptar a chave simétrica AES.
- Utiliza a chave simétrica AES com o vetor de inicialização para desencriptar a estrutura de dados encriptada que contém os hashes de palavras-passe.
- Grava os hashes de palavras-passe Kerberos que recebe para o controlador de domínio dos Microsoft Entra Domain Services. Os hashes são salvos no atributo supplementalCredentials do objeto de utilizador, que está criptografado com a chave pública do controlador de domínios dos Serviços de Domínio Microsoft Entra.
- Os Serviços de Domínio Microsoft Entra gravam o hash de senha NTLM recebido no controlador de domínio dos Serviços de Domínio Microsoft Entra. O hash é guardado no atributo unicodePwd do objeto de utilizador, que é criptografado com a chave pública do controlador de domínio dos Serviços de Domínio Microsoft Entra.
Ativar a sincronização do hash de palavras-passe
Importante
Se você estiver migrando do AD FS (ou outras tecnologias de federação) para a Sincronização de Hash de Senha, exiba Recursos para migrar aplicativos para o Microsoft Entra ID.
Quando você instala o Microsoft Entra Connect usando a opção Configurações Expressas, a sincronização de hash de senha é habilitada automaticamente. Para obter mais informações, consulte Introdução ao Microsoft Entra Connect usando configurações expressas.
Se você usar configurações personalizadas ao instalar o Microsoft Entra Connect, a sincronização de hash de senha estará disponível na página de entrada do usuário. Para obter mais informações, consulte Instalação personalizada do Microsoft Entra Connect.
Sincronização do hash de palavras-passe e FIPS
Se o servidor estiver bloqueado de acordo com o Federal Information Processing Standard (FIPS), o MD5 será desativado.
Para ativar o MD5 para a sincronização do hash de palavras-passe, execute os seguintes passos:
- Vá para %programfiles%\Microsoft Azure AD Sync\Bin.
- Abra o miiserver.exe.config.
- Vá para o nó de configuração e runtime no final do arquivo.
- Adicione o seguinte nó:
<enforceFIPSPolicy enabled="false" />
- Guardar as suas alterações.
- Reinicialize para que as alterações entrem em vigor.
Para referência, este trecho é como deve ser:
<configuration>
<runtime>
<enforceFIPSPolicy enabled="false" />
</runtime>
</configuration>
Para obter informações sobre segurança e FIPS, consulte Sincronização de hash de senha do Microsoft Entra, criptografia e conformidade com FIPS.
Solucionar problemas de sincronização de hash de palavras-passe
Se tiver problemas com a sincronização do hash de palavras-passe, veja Resolver problemas com a sincronização do hash de palavras-passe.