O certificado VPN não protege o trecho LDAP

Um login VPN que verifica as credenciais contra um diretório envolve duas conexões de rede separadas. A conexão do utilizador com o gateway é protegida pelo próprio certificado da VPN e pela configuração do protocolo. A conexão do gateway com o diretório é outra sessão com as suas próprias definições TLS, o seu próprio armazenamento de confiança e os seus próprios modos de falha. Nada da primeira garante nada sobre a segunda.

Essa assimetria é o mecanismo por trás de um login que parece cifrado e ainda assim envia uma palavra-passe de bind em texto simples.

Duas conexões, duas decisões de confiança

A sessão externa é o que o utilizador vê: um certificado ligado ao nome de anfitrião da VPN, validado pelo cliente, que transporta a troca de autenticação. A sessão interna pertence ao cliente de diretório dentro do gateway, que abre a sua própria conexão e ou negoceia TLS ou não. Cada lado valida o par com quem fala, usando material de um ficheiro de configuração diferente. Um trecho interno mal configurado permanece invisível do lado do utilizador, porque o trecho externo funciona exatamente como previsto.

É por isso que a falha é silenciosa e não ruidosa. Um gateway que nunca verifica o certificado do diretório continua a autenticar os utilizadores corretamente; apenas os autentica através de um canal que não verificou.

StartTLS e LDAPS, escolhidos deliberadamente

O StartTLS abre como LDAP simples e é atualizado no local, convencionalmente na porta 389. O LDAPS inicia TLS com a conexão, convencionalmente na 636. Ambos são legítimos e o adaptador tem de corresponder ao que o diretório oferece. Exigir StartTLS é diferente de o experimentar e continuar quando a atualização falha, e é exatamente nessa diferença que uma palavra-passe de bind pode escapar. Configure o modo estrito e não permita uma alternativa não protegida para um bind com palavra-passe.

ldapsearch -H ldap://dc1.corp.example -ZZ -x -D "CN=VPN Bind,OU=Service Accounts,DC=corp,DC=example" -W -b "DC=corp,DC=example" "(sAMAccountName=example-user)" dn

A opção -ZZ é todo o ponto: a consulta falha em vez de continuar silenciosamente sem a atualização. Os nomes e contas nessa linha são exemplos. A documentação TLS do OpenLDAP cobre as definições de confiança por trás disso.

Que armazenamento de confiança lê o cliente LDAP?

A biblioteca cliente do OpenLDAP lê a sua própria configuração de confiança, quer do ficheiro do sistema quer de uma definição específica do plugin. A diretiva CA da VPN aplica-se aos pares VPN e não é prova de que a biblioteca LDAP leia o mesmo ficheiro. Use o nome de anfitrião do diretório que o certificado cobre realmente, mais a cadeia emissora em que a biblioteca confia. No Active Directory, implemente um certificado de serviço de diretório com o uso correto de autenticação de servidor em vez de raciocinar a partir de um nome de exibição.

Cada destino de failover tem de satisfazer a mesma política de identidade. Um ambiente em que o primário está validado e o secundário não está é pior do que um sem failover, porque o caminho mais fraco só é descoberto durante uma interrupção.

A conta de bind continua a ser um problema à parte

Proteger o transporte não reduz o que a conta de bind pode fazer. O âmbito de pesquisa no diretório, a autorização por grupos e os privilégios da conta de serviço são decisões separadas, e uma conta de bind ampla continua ampla depois de ativar TLS. Use a conta de serviço e a base de pesquisa mais estreitas de que a integração precisa, e registe o ponto final, o modo TLS, o proprietário da confiança e o processo de renovação juntamente com a configuração da VPN.

Quando aparecer uma discrepância de certificado, implemente o certificado ou a cadeia corretos. Desativar a verificação transforma uma discrepância visível numa invisível e deixa a segunda relação de confiança sem teste.

Duas conexões, dois proprietários, duas datas de renovação. Mantê-las separadas na documentação é o que mantém o login honesto.