O certificado VPN non protexe o tramo LDAP

Un inicio de sesión VPN que comproba as credenciais contra un directorio implica dúas conexións de rede separadas. A conexión do usuario coa pasarela está protexida polo propio certificado da VPN e pola configuración do protocolo. A conexión da pasarela co directorio é outra sesión cos seus propios axustes TLS, o seu propio almacén de confianza e os seus propios modos de fallo. Nada do primeiro garante nada do segundo.

Esa asimetría é o mecanismo detrás dun inicio de sesión que parece cifrado e aínda así envía un contrasinal de bind en claro.

Dúas conexións, dúas decisións de confianza

A sesión externa é o que ve o usuario: un certificado vinculado ao nome de host da VPN, validado polo cliente, que transporta o intercambio de autenticación. A sesión interna pertence ao cliente de directorio dentro da pasarela, que abre a súa propia conexión e ou negocia TLS ou non. Cada lado valida a parella coa que fala, usando material dun ficheiro de configuración distinto. Un tramo interno mal configurado permanece invisible desde o lado do usuario, porque o tramo externo funciona exactamente como estaba previsto.

Por iso o fallo é silencioso e non ruidoso. Unha pasarela que nunca comproba o certificado do directorio segue autenticando os usuarios correctamente; simplemente os autentica por unha canle que non verificou.

StartTLS e LDAPS, escollidos a propósito

StartTLS ábrese como LDAP simple e actualízase no sitio, convencionalmente no porto 389. LDAPS inicia TLS coa conexión, convencionalmente no 636. Ambos son lexítimos e o adaptador ten que coincidir co que ofrece o directorio. Esixir StartTLS é distinto de probalo e continuar cando a actualización falla, e esa diferenza é exactamente onde pode escapar un contrasinal de bind. Configure o modo estrito e non permita unha alternativa non protexida para un bind con contrasinal.

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

O parámetro -ZZ é todo o punto: a consulta falla en lugar de continuar en silencio sen a actualización. Os nomes e contas desa liña son exemplos. A documentación TLS de OpenLDAP cobre os axustes de confianza que hai detrás.

Que almacén de confianza le o cliente LDAP?

A biblioteca de cliente OpenLDAP le a súa propia configuración de confianza, xa proveña do ficheiro do sistema ou dun axuste específico do complemento. A directiva CA da VPN aplícase ás parellas da VPN e non é proba de que a biblioteca LDAP lea o mesmo ficheiro. Use o nome de host do directorio que o certificado cobre realmente, máis a cadea emisora na que confía a biblioteca. En Active Directory, implante un certificado de servizo de directorio co uso correcto de autenticación de servidor en lugar de razoar a partir dun nome para mostrar.

Cada destino de failover ten que satisfacer a mesma política de identidade. Un entorno onde o primario está validado e o secundario non o está é peor que un sen failover, porque o camiño máis feble só se descobre durante unha interrupción.

A conta de bind segue a ser un problema aparte

Protexer o transporte non reduce o que pode facer a conta de bind. O alcance de busca no directorio, a autorización por grupos e os privilexios da conta de servizo son decisións separadas, e unha conta de bind ampla segue sendo ampla despois de habilitar TLS. Use a conta de servizo e a base de busca máis estreitas que necesite a integración, e rexistre o punto final, o modo TLS, o propietario da confianza e o proceso de renovación xunto coa configuración da VPN.

Cando apareza unha discrepancia de certificado, implante o certificado ou a cadea correctos. Desactivar a verificación converte unha discrepancia visible en invisible e deixa a segunda relación de confianza sen probar.

Dúas conexións, dous propietarios, dúas datas de renovación. Mantelas separadas na documentación é o que mantén honesto o inicio de sesión.