Agora que as empresas estão a adoptar a computação em nuvem como parte do seu modelo de negócio, uma grande percentagem está a optar por ligar o seu ambiente do Active Directory local à sua contraparte na nuvem, o Azure Active Directory da Microsoft. Quando estende o seu AD local ao Azure AD, tem duas opções para a forma como pretende que os utilizadores locais se autentiquem no serviço na nuvem: federação de identidades e autenticação directa com o Azure AD. Embora a autenticação directa seja tecnicamente o método mais simples dos dois, requer a activação de uma funcionalidade conhecida como sincronização de palavras-passe. E penso que a sincronização de palavras-passe é uma funcionalidade muito mal compreendida que merece mais explicações.
A Microsoft oferece duas formas de tratar a autenticação no Azure AD: federação de identidades ou autenticação directa utilizando o próprio Azure AD. A federação de identidades com um serviço de federação, como o AD FS ou o PingFederate, fornece um início de sessão único no Azure AD, redireccionando os utilizadores do serviço de nuvem para o AD local para autenticação. A outra opção, a autenticação direta no Azure AD, exige que o ID de usuário e a senha do usuário sejam armazenados localmente no serviço de nuvem. Para as empresas, isto tem de ser feito com a funcionalidade de sincronização de palavras-passe do serviço AD Connect da Microsoft; nenhum terceiro fornece uma capacidade equivalente.
O que é a sincronização de hash de palavra-passe e porquê utilizá-la?
No seu nível mais simples, a sincronização do hash da palavra-passe (uma descrição mais precisa, que explicarei abaixo) copia a palavra-passe do utilizador do AD para o Azure AD a cada dois minutos. Isto permite que os utilizadores iniciem sessão no Azure AD com o mesmo ID de utilizador e palavra-passe que utilizam para iniciar sessão no AD. A Microsoft chama a este padrão o mesmo início de sessão. É diferente do início de sessão único porque, com a sincronização do hash da palavra-passe, será pedido aos utilizadores que iniciem sessão no Azure AD, para além de qualquer início de sessão empresarial que tenham feito.
Porque é que quereria utilizar a sincronização de hash de palavra-passe? Principalmente porque é mais simples de implementar do que um serviço de federação. A Microsoft precisava de fornecer uma forma fácil de integrar utilizadores do AD no local com o Azure AD, e a sincronização de hash de palavra-passe fá-lo sem a necessidade de um serviço de federação altamente disponível de vários servidores.
E a solução mais simples provou ser popular; cerca de 50% das organizações que sincronizam com o Azure AD utilizam a sincronização de hash de palavra-passe. Desses 50%, metade são organizações de pequena e média dimensão. A sincronização de hash de palavra-passe fornece um caminho suave para que estas organizações passem para uma infra-estrutura de TI baseada na nuvem ou apenas na nuvem, porque os utilizadores já estão a autenticar directamente com o serviço do Azure AD.
Outra vantagem da sincronização de hash de palavra-passe é que, ao contrário da federação, não depende de um serviço de federação externo para processar as autenticações. De facto, a Microsoft oferece a sincronização de hash de palavra-passe para além da federação, pelo que pode ser utilizada como alternativa se o serviço de federação tiver uma falha.
Quão segura é a sincronização de hash de palavras-passe?
Note que descrevo esta funcionalidade como sincronização de hash de palavra-passe - e não sincronização de palavra-passe. É uma distinção importante. As palavras-passe de texto simples não são sincronizadas entre o AD DS e o Azure AD. Não só não é uma boa ideia, como nem sequer é tecnicamente possível, porque o Active Directory não tem as palavras-passe de texto simples. Quando um utilizador cria ou actualiza a sua palavra-passe no AD, esta é armazenada como um hash MD5 unidireccional nos DCs do domínio. Este hash é o que é sincronizado com o Azure AD e armazenado no armazenamento de credenciais do serviço.
Como funciona, exactamente? Compilei os seguintes passos a partir da publicação no blogue de Alex Simon AAD Password Sync, Encryption, and FIPS Compliance e de algumas outras fontes:
- As palavras-passe de utilizador são armazenadas como um hash não reversível nos Controladores de Domínio (DCs) do Active Directory do Windows Server. Quando o agente de sincronização de palavras-passe no AD Connect tenta sincronizar o hash da palavra-passe, o DC encripta o hash. A encriptação é efectuada com uma chave derivada da chave de sessão RPC através da salga da mesma. A derivação da chave é a seguinte [onde SaltedEncryptionKey = MD5 (chave de sessão RPC, sal aleatório de 128 bits)]. O CD também passa o sal para o agente de sincronização utilizando o protocolo de replicação.
- O hash da palavra-passe original é replicado (utilizando o protocolo de replicação do CD) do CD para o Password Sync Agent.
- O Password Sync Agent desencripta o hash encriptado derivando a chave conforme descrito acima. O agente de sincronização de palavras-passe utiliza o MD5 para efectuar a derivação da chave, uma vez que a derivação tem de ser idêntica à derivação que o DC efectuou (quando encriptou os dados). E o MD5 é o nível mais elevado disponível para esta acção no protocolo de replicação do CD das implementações existentes do Active Directory do Windows Server.
- Uma vez efectuada a desencriptação, o agente de sincronização pega no hash da palavra-passe original resultante e transforma-o num hash SHA256 utilizando o algoritmo de derivação de chaves PKDF2, tal como definido no RFC 2898.
- Em seguida, o Password Sync Agent sincroniza esse hash de palavra-passe com hash SHA256 através do cabo (um Service Bus relay encriptado dedicado ao inquilino do Azure AD) para o Azure AD.
- Quando a cópia com hash SHA256 do hash da palavra-passe original chega ao Azure AD, o Azure AD encripta o hash com o algoritmo AES antes de o armazenar na base de dados na nuvem.
A única coisa que atravessa o fio no caminho para o Azure AD é uma cópia com hash SHA256 do hash da palavra-passe original. O uso de MD5 pelo agente de sincronização de senhas é estritamente para compatibilidade do protocolo de replicação com o DC e só é usado, no local, entre o DC e o agente de sincronização de senhas.
Desvantagens da sincronização de hash de palavra-passe
Do ponto de vista do utilizador, a desvantagem mais óbvia é que o utilizador tem de introduzir as suas credenciais empresariais uma segunda vez, independentemente de estar ligado à sua rede empresarial ou fora dela, numa rede pública. No entanto, estes inícios de sessão podem ser reduzidos, marcando a caixa de verificação "Manter-me ligado" (KMSI). Esta opção define um cookie de sessão que ignora a autenticação durante um curto período de tempo. A sua equipa de segurança deverá ter em conta esta questão, e o comportamento KMSI pode ser activado ou desactivado pelo administrador do Azure AD.
Do ponto de vista do profissional de identidade, o problema com a sincronização do hash da palavra-passe é que está a distribuir a palavra-passe por mais do que um local para autenticação. Em contrapartida, a federação redirecciona todos os pedidos de autenticação para o fornecedor de identidade. A Microsoft fez um grande esforço para garantir que o processo é seguro, mas é válido fazer perguntas sobre o ciclo de vida da palavra-passe.
Quando deve utilizar a sincronização de hash de palavra-passe?
Há um caso de utilização em que tem de utilizar a sincronização de hash de palavra-passe: se optar por implementar os Serviços de Domínio do Azure AD. Esta funcionalidade cria um controlador de domínio como um serviço que as aplicações do Azure (tais como VMs que executam aplicações dependentes do AD) podem utilizar. No entanto, para que estes DCs sejam funcionalmente equivalentes aos DCs locais, têm de ter hashes de palavra-passe de utilizador e, por isso, necessitam de sincronização de hash de palavra-passe para os colocar no Azure.
A sincronização de hash de palavra-passe é uma solução popular para integrar as suas identidades no local com o Azure AD. Não é tão elegante como utilizar a federação de identidades, mas é mais simples. Como em qualquer decisão de design, certifique-se de que analisou os pontos fortes e fracos desta solução e como se aplicam à sua situação.
