Implementar a sincronização de hash de senha com o Microsoft Entra Connect Sync
Este artigo fornece as informações necessárias para sincronizar suas senhas de usuário de uma instância do Active Directory local para uma instância do Microsoft Entra baseada em nuvem.
Como a sincronização de hash de senha funciona
O serviço de domínio do Active Directory armazena senhas na forma de uma representação de valor de hash da senha de usuário real. Um valor de hash é um resultado de uma função matemática unidirecional (o algoritmo de hash). Não há um método para reverter o resultado de uma função unidirecional para a versão de texto sem formatação de uma senha.
Para sincronizar sua senha, o Microsoft Entra Connect Sync extrai o hash da senha da instância do Active Directory local. Um processamento de segurança adicional é 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 de hash de senha é semelhante à sincronização de dados de usuário. Contudo, as senhas são sincronizadas com mais frequência do que a janela de sincronização de diretório padrão para outros atributos. O processo de sincronização de hash senha é executado a cada 2 minutos. Não é possível modificar a frequência desse processo. Ao sincronizar uma senha, ela substituirá a senha de nuvem existente.
Na primeira vez que você habilitar o recurso de sincronização de hash de senha, ele executará uma sincronização inicial das senhas de todos os usuários no escopo. A Distribuição em etapas permite testar seletivamente grupos de usuários com recursos de autenticação na nuvem, como a autenticação multifator do Microsoft Entra, o acesso condicional, o Microsoft Entra ID Protection para credenciais vazadas, a governança de identidade e outros, antes de transferir seus domínios. Você não pode 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 da senha para alguns conectores, mas não para outros, usando o cmdlet Set-ADSyncAADPasswordSyncConfiguration.
Quando você altera uma senha local, a senha atualizada é sincronizada, geralmente em questão de minutos. O recurso de sincronização de hash de senha repete automaticamente tentativas de sincronização com falha. Se ocorrer um erro durante uma tentativa de sincronização de senha, um erro é registrado no seu visualizador de eventos.
A sincronização de uma senha não afeta um usuário conectado atualmente. Sua sessão de serviço de nuvem atual não será afetada imediatamente por uma alteração de senha sincronizada que ocorre enquanto você está conectado a um serviço de nuvem. No entanto, quando o serviço de nuvem exigir que você se autentique novamente, será necessário fornecer a nova senha.
O usuário deve inserir suas credenciais corporativas uma segunda vez para autenticar no Microsoft Entra ID, independentemente de estar conectado à rede corporativa. Porém, esse padrão poderá ser minimizado, se o usuário marcar a caixa de seleção de KMSI (Manter-me conectado) ao entrar. Essa seleção define um cookie de sessão que ignora a autenticação por 180 dias. O comportamento KMSI pode ser habilitado ou desabilitado pelo administrador do Microsoft Entra. Além disso, é possível reduzir os prompts de senha configurando o ingresso no Microsoft Entra ou o ingresso híbrido no Microsoft Entra, o que conecta os usuários automaticamente quando estão em dispositivos corporativos conectados à rede corporativa.
Mais vantagens
- Em geral, a sincronização de hash de senha é mais simples de implementar do que um serviço de federação. Ela não exige servidores adicionais e elimina a dependência de um serviço de federação altamente disponível para autenticar usuários.
- A sincronização de hash de senha também pode ser habilitada além da federação. Ela pode ser usada como um fallback se seu serviço de federação sofrer uma interrupção.
Observação
Somente há suporte para a sincronização de senha para o usuário do tipo de objeto no Active Directory. Não há suporte para o tipo de objeto iNetOrgPerson.
Descrição detalhada de como funciona a sincronização de hash senha
A seção a seguir descreve detalhadamente como a sincronização de hash de senha funciona entre o Microsoft Entra ID e Active Directory.
A cada dois minutos, o agente de sincronização de hash de senha no servidor do AD Connect solicita hashes de senha armazenados (o atributo unicodePwd) de um DC. Essa solicitação é feita através do protocolo de replicação padrão MS-DRSR usado para sincronizar dados entre DCs. A conta do Conector AD DS deve ter as permissões do AD Replicar Alterações de Diretório e Replicar Todas as Alterações de Diretório (concedidas por padrão na instalação) para obter os hashes de senha.
Antes de enviar, o controlador de domínio criptografa o hash de senha MD4 usando uma chave que é um hash MD5 da chave de sessão RPC e um valor de sal. Em seguida, ele envia o resultado para o agente de sincronização de hash de senha por RPC. O controlador de domínio também passa o sal para o agente de sincronização usando o protocolo de replicação do controlador de domínio, para que o agente possa descriptografar o envelope.
Depois que o agente de sincronização de hash de senha tiver o envelope criptografado, ele usará MD5CryptoServiceProvider e o sal para gerar uma chave para descriptografar os dados recebidos de volta para seu formato original de MD4. O agente de sincronização de hash de senha nunca tem acesso à senha de texto não criptografado. O uso que o agente de sincronização de hash de senha faz do MD5 é estritamente para compatibilidade de protocolo de replicação com o controlador de domínio, e é usado somente no local entre o controlador de domínio e o agente de sincronização de hash de senha.
O agente de sincronização de hash de senha expande o hash de senha binária de 16 bits para 64 bytes convertendo primeiro o hash em uma cadeia hexadecimal de 32 bytes, depois convertendo essa cadeia de caracteres de volta para o binário com a codificação UTF-16.
O agente de sincronização de hash de senha adiciona um sal por usuário – que é composto por um sal de 10 bytes – ao binário de 64 bytes a fim de proteger ainda mais o hash original.
Em seguida, o agente de sincronização de hash de senha combina o hash MD4 e o sal por usuário e usa o resultado como entrada 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 Whitepaper do Microsoft Entra.
O agente de sincronização de hash de senha usa o hash resultante de 32 bytes, concatena o sal por usuário e o número de iterações SHA256 com ele (para uso pelo Microsoft Entra ID) e, em seguida, transmite a cadeia de caracteres do Microsoft Entra Connect para o Microsoft Entra ID por TLS.
Quando um usuário tenta entrar no Microsoft Entra ID e insere sua senha, a senha é executada por meio do mesmo processo de MD4 + sal + PBKDF2 + HMAC-SHA256. Se o hash resultante corresponder ao hash armazenado no Microsoft Entra ID, isso significa que o usuário digitou a senha correta e será autenticado.
Observação
O hash MD4 original não é transmitido para o Microsoft Entra ID. Em vez disso, o hash SHA256 do hash MD4 original é transmitido. Como resultado, se o hash armazenado no Microsoft Entra ID for obtido, ele não poderá ser usado em um ataque Pass-the-Hash local.
Observação
O valor de hash de senha é NUNCA armazenado no SQL. Esses valores são processados somente na memória antes de serem enviados para o Microsoft Entra ID.
Considerações de segurança
Ao sincronizar senhas, a versão da sua senha em texto sem formatação não é exposta ao recurso de sincronização de hash de senha, nem ao Microsoft Entra ID ou 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 armazenados de senha SHA256 no Microsoft Entra ID (um hash do Hash MD4 original) são mais seguros do que os armazenados no Active Directory. Além disso, como não é possível descriptografar o hash SHA256, ele não pode ser levado de volta para o ambiente do Active Directory da organização e apresentado como uma senha de usuário válida em um ataque Pass-the-Hash.
Considerações sobre política de senha
Há dois tipos de políticas de senha que são afetadas ao habilitar a sincronização de hash de senha:
- Política de complexidade de senha
- Política de expiração de senha
Política de complexidade de senha
Quando a sincronização de hash de senha é habilitada, as políticas de complexidade de senha na instância do Active Directory local substituem as políticas de complexidade na nuvem para usuários sincronizados. Você pode usar todas as senhas válidas da sua instância do Active Directory local para acessar os serviços do Microsoft Entra.
Observação
Senhas de usuários criadas diretamente na nuvem ainda estão sujeitas a políticas de senha, conforme definido na nuvem.
Política de expiração de senha
Se um usuário estiver no escopo de sincronização de hash de senha, por padrão, a senha da conta de nuvem será definida como Nunca Expirar.
Você pode continuar entrando nos serviços de nuvem usando uma senha sincronizada que expirou no seu ambiente local. A senha de nuvem será atualizada na próxima vez que você alterar a senha no ambiente local.
CloudPasswordPolicyForPasswordSyncedUsersEnabled
Se houver usuários sincronizados que interagem somente com os serviços integrados do Microsoft Entra e também precisam estar em conformidade com uma política de expiração de senha, você pode forçá-los a cumprir sua política de expiração de senhas do Microsoft Entra habilitando o recurso CloudPasswordPolicyForPasswordSyncedUsersEnabled (no módulo do PowerShell do MSOnline preterido o recurso era chamado EnforceCloudPasswordPolicyForPasswordSyncedUsers).
Quando CloudPasswordPolicyForPasswordSyncedUsersEnabled está desabilitado (que é a configuração padrão), o Microsoft Entra Connect atualiza o atributo PasswordPolicies de usuários sincronizados como “DisablePasswordExpiration”. Essa atualização é feita sempre que a senha de um usuário é sincronizada e instrui o Microsoft Entra ID a ignorar a política de expiração de senha de nuvem para aquele usuário. É possível verificar o valor do atributo usando o módulo do PowerShell do Microsoft Graph com o seguinte comando:
(Get-MgUser -UserId <User Object ID> -Property PasswordPolicies).PasswordPolicies
Para habilitar o recurso CloudPasswordPolicyForPasswordSyncedUsersEnabled, execute os comandos a seguir usando o módulo do Graph PowerShell:
$OnPremSync = Get-MgDirectoryOnPremiseSynchronization
$OnPremSync.Features.CloudPasswordPolicyForPasswordSyncedUsersEnabled = $true
Update-MgDirectoryOnPremiseSynchronization `
-OnPremisesDirectorySynchronizationId $OnPremSync.Id `
-Features $OnPremSync.Features
Observação
Você precisa instalar o módulo do MSGraph PowerShell para que o script anterior funcione. Se você receber erros relacionados a privilégios insuficientes, verifique se você consentiu corretamente com o escopo da API usando o comando a seguir ao se conectar Connect-MgGraph -Scopes "OnPremDirectorySynchronization.ReadWrite.All"
Uma vez habilitado, o Microsoft Entra ID não vai remover, para cada usuário sincronizado, o valor DisablePasswordExpiration do atributo PasswordPolicies. Em vez disso, o DisablePasswordExpiration valor é removido de PasswordPolicies durante a próxima sincronização de hash de senha para cada usuário, após a próxima alteração de senha no AD local.
Após o recurso CloudPasswordPolicyForPasswordSyncedUsersEnabled ter sido habilitado, os novos usuários serão provisionados sem um valor de PasswordPolicies.
Dica
É recomendável habilitar CloudPasswordPolicyForPasswordSyncedUsersEnabled antes de habilitar a sincronização de hash de senha, de forma que a sincronização inicial dos hashes de senha não adicione o valor DisablePasswordExpiration ao atributo PasswordPolicies dos usuários.
A política de senha padrão do Microsoft Entra exige que os usuários alterem suas senhas a cada 90 dias. Se sua política no AD também for de 90 dias, as duas políticas deverão corresponder. No entanto, se a política do AD não for de 90 dias, é possível atualizar a política de senha do Microsoft Entra para coincidir, usando o comando Update-MgDomain do PowerShell.
O Microsoft Entra ID dá suporte a uma política de expiração de senha separada por domínio registrado.
Limitação: se houver contas sincronizadas que precisam ter senhas que não expiram no Microsoft Entra ID, é necessário adicionar explicitamente o valor DisablePasswordExpiration ao atributo PasswordPolicies do objeto de usuário no Microsoft Entra ID. Você pode adicionar esse valor executando o seguinte comando:
Update-MgUser -UserID <User Object ID> -PasswordPolicies "DisablePasswordExpiration"`
Observação
Para usuários híbridos que têm um valor PasswordPolicies definido como DisablePasswordExpiration, esse valor muda para None depois que uma alteração de senha é executada localmente.
Observação
O comando PowerShell Update-MgDomain não funciona em domínios federados.
Observação
O comando PowerShell Update-MgUser não funciona em domínios federados.
Sincronizar 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 administração. Isso é conhecido como definir uma senha “temporária” e é concluído ao marcar o sinalizador “O usuário deve alterar a senha no próximo logon” em um objeto de usuário 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 o intervalo de tempo em que mais de um indivíduo tem conhecimento dessa credencial.
Para dar suporte a senhas temporárias no Microsoft Entra ID para usuários sincronizados, é possível habilitar o recurso ForcePasswordChangeOnLogOn, executando os seguintes comandos usando o módulo do Graph PowerShell:
$OnPremSync = Get-MgDirectoryOnPremiseSynchronization
$OnPremSync.Features.UserForcePasswordChangeOnLogonEnabled = $true
Update-MgDirectoryOnPremiseSynchronization `
-OnPremisesDirectorySynchronizationId $OnPremSync.Id `
-Features $OnPremSync.Features
Observação
Um novo usuário criado no Active Directory com o sinalizador "Usuário deve alterar senha no próximo logon" sempre será provisionado no Microsoft Entra ID com uma política de senha para "Forçar alteração de senha na próxima entrada", independentemente do recurso ForcePasswordChangeOnLogOn ser verdadeiro ou falso. Essa é uma lógica interna do Microsoft Entra, pois o novo usuário é provisionado sem uma senha, enquanto o recurso ForcePasswordChangeOnLogOn afeta apenas os cenários de redefinição de senha do administrador.
Se um usuário for criado no Active Directory com "O usuário deve alterar a senha no próximo logon" antes de o recurso ser habilitado, o usuário receberá um erro ao se conectar. 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 no Active Directory. Depois de sincronizar as alterações no objeto do usuário, o usuário receberá o prompt esperado no Microsoft Entra ID para atualizar sua senha.
Cuidado
Esse recurso somente deve ser usado quando SSPR e Write-back de senha estiverem habilitados no locatário. Isso é para que, se um usuário alterar sua senha por meio de SSPR, ela será sincronizada com o Active Directory.
Expiração da conta
Se a organização usar o atributo accountExpires como para do gerenciamento da conta de usuário, esse atributo não será sincronizado com o Microsoft Entra ID. Como resultado, uma conta expirada do Active Directory em um ambiente configurado para sincronização de hash de senha ainda estará ativa no Microsoft Entra ID. É recomendável usar um script agendado do PowerShell que desabilita as contas do AD dos usuários, uma vez que eles expiram (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 habilitada novamente.
Sincronização de hash de senha e autenticação com 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/PIV. Eles fazem isso definindo a configuração da propriedade de usuário 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 é criada de forma aleatória pelo controlador de domínio com um valor que ninguém sabe; o usuário precisa se registrar e, posteriormente, autenticar no domínio do Windows por meio do cartão inteligente.
Com a sincronização de hash de senha habilitada, esse hash de senha do AD é sincronizado com o Microsoft Entra ID para que também possa ser usado em autenticação na nuvem.
Observação
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 o cartão inteligente, exigindo que o SCRIL seja desabilitado e o usuário receba uma senha temporária até que consiga um novo cartão inteligente
Anteriormente, quando o SCRIL era reativado e uma nova senha aleatória do AD era gerada, o usuário ainda podia usar sua senha antiga para se autenticar no Microsoft Entra ID. Agora, o Connect Sync foi atualizado para que a nova senha aleatória do AD seja sincronizada com o Microsoft Entra ID e a senha antiga não possa ser usada depois que o login do cartão inteligente estiver habilitado.
Recomendamos que os administradores executem uma sincronização completa se você tiver usuários com um bit de SCRIL no domínio do AD. Se você executar uma sincronização completa, há uma chance de que os usuários finais sejam solicitados a fazer login novamente com a senha atualizada se a autenticação baseada em certificado não for usada.
Substituir senhas sincronizadas
Um administrador pode redefinir manualmente a 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 a senha sincronizada e todas as políticas de senha definidas na nuvem se aplicam à nova senha.
Se você alterar a senha local novamente, a nova senha será sincronizada com a nuvem e substituirá a senha atualizada manualmente.
A sincronização de uma senha não afeta um usuário do Azure que está conectado. Sua sessão de serviço de nuvem atual não será afetada imediatamente por uma alteração de senha sincronizada que ocorre enquanto você está conectado a um serviço de nuvem. KMSI ampliará a duração dessa diferença. Quando o serviço de nuvem exigir que você se autentique novamente, será necessário fornecer a nova senha.
Processo de sincronização de hash de senha para o Microsoft Entra Domain Services
Se o Microsoft Entra Domain Services for usado para fornecer autenticação herdada para aplicativos e serviços que precisam usar Kerberos, LDAP ou NTLM, alguns processos adicionais farão parte do fluxo de sincronização de hash de senha. O Microsoft Entra Connect usa os seguintes processos para sincronizar hashes de senha com o Microsoft Entra ID para uso no Microsoft Entra Domain Services:
Importante
O Microsoft Entra Connect só deve ser instalado e configurado para sincronização com ambientes do AD DS local. Não há suporte para instalar o Microsoft Entra Connect em um domínio gerenciado do Microsoft Entra Domain Services para sincronizar objetos de volta para o Microsoft Entra ID.
O Microsoft Entra Connect só sincroniza hashes de senha herdados quando você habilita o Microsoft Entra Domain Services para seu locatário do Microsoft Entra. As etapas a seguir não serão utilizadas se você usar o Microsoft Entra Connect apenas para sincronizar um ambiente do AD DS local com o Microsoft Entra ID.
Se os aplicativos herdados não usam autenticação NTLM ou associações simples LDAP, recomendamos desabilitar a sincronização de hash de senha NTLM para o Microsoft Entra Domain Services. Para obter mais informações, confira Desabilitar pacotes de codificação baixa e sincronização de hash de credencial NTLM.
- O Microsoft Entra Connect recupera a chave pública para a instância do locatário do Microsoft Entra Domain Services.
- 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 senha NTLM.
- supplementalCredentials para o hash de senha Kerberos.
- O Microsoft Entra Connect detecta 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 do AES de 256 bits aleatória.
- Gera um vetor de inicialização aleatória necessário para a primeira rodada de criptografia.
- Extrai hashes de senha Kerberos dos atributos supplementalCredentials.
- Verifica a configuração SyncNtlmPasswords da configuração de segurança do Microsoft Entra Domain Services.
- Se essa configuração estiver desabilitada, gerará um hash NTLM aleatório de alta entropia (diferente da senha do usuário). Esse hash é então combinado com os hashes de senha Kerberos exatos do atributo supplementalCrendetials em uma estrutura de dados.
- Se habilitado, combina o valor do atributo unicodePwd com os hashes de senha Kerberos extraídos do atributo supplementalCredentials em uma 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 do Microsoft Entra Domain Services do locatário.
- O Microsoft Entra Connect transmite a chave simétrica criptografada AES, a estrutura de dados criptografada que contém os hashes de senha e o vetor de inicialização para o Microsoft Entra ID.
- O Microsoft Entra ID armazena a chave simétrica criptografada AES, a estrutura de dados criptografada e o vetor de inicialização para o usuário.
- O Microsoft Entra ID envia a chave simétrica criptografada AES, a estrutura de dados criptografada e o vetor de inicialização usando um mecanismo de sincronização interno em uma sessão HTTP criptografada para o Microsoft Entra Domain Services.
- O Microsoft Entra Domain Services recupera a chave privada para a instância do locatário do Azure Key Vault.
- Para cada conjunto de dados criptografado (representando a alteração de senha de um único usuário), o Microsoft Entra Domain Services executa as seguintes etapas:
- Usa sua chave privada para descriptografar a chave simétrica AES.
- Usa a chave simétrica AES com o vetor de inicialização para descriptografar a estrutura de dados criptografada que contém os hashes de senha.
- Grava os hashes de senha Kerberos que ele recebe no controlador de domínio do Microsoft Entra Domain Services. Os hashes são salvos no atributo supplementalCredentials do objeto de usuário que é criptografado para a chave pública do controlador de domínio do Microsoft Entra Domain Services.
- O Microsoft Entra Domain Services grava o hash de senha NTLM recebido no controlador de domínio do Microsoft Entra Domain Services. Os hashes são salvos no atributo supplementalCredentials do objeto de usuário que é criptografado na chave pública do controlador de domínio do Microsoft Entra Domain Services.
Permitir a sincronização de hash de senha
Importante
Se você estiver migrando do AD FS (ou de outras tecnologias de federação) para a Sincronização de Hash de Senha, confira Recursos para migrar aplicativos para o Microsoft Entra ID.
Quando você instala o Microsoft Entra Connect usando as 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 quando instalar o Microsoft Entra Connect, a sincronização de hash de senha estará disponível na página de entrada do usuário. Para saber mais, confira Instalação personalizada do Microsoft Entra Connect.
Sincronização de hash de senha e FIPS
Se o servidor estiver bloqueado de acordo com o padrão FIPS, o MD5 será desabilitado.
Para habilitar MD5 para a sincronização de hash de senha, execute as seguintes etapas:
- Vá para %programfiles%\Microsoft Azure AD Sync\Bin.
- Abra miiserver.exe.config.
- Acesse o nó configuração/runtime no fim do arquivo.
- Adicione o seguinte nó:
<enforceFIPSPolicy enabled="false" /> - Salve suas alterações.
- Reinicialize para que as alterações entrem em vigor.
Para referência, esse snippet mostra como deve ser a aparência:
<configuration>
<runtime>
<enforceFIPSPolicy enabled="false" />
</runtime>
</configuration>
Para obter informações sobre segurança e FIPS, consulte Sincronização de hash de senha, criptografia e conformidade FIPS do Microsoft Entra.
Solução de Problemas de Sincronização de hash de Senha
Caso tenha problemas com a sincronização de hash de senha, veja Solucionar problemas de sincronização de hash de senha.