LDAPS de alta disponibilidade com o Fedora Directory Server

Question

Fui solicitado a configurar uma arquitetura LDAP HA usando o Fedora Directory Server - a empresa usa curiosamente o Sun DS, mas quer se afastar da Sun.

Eu quero usar um loadbalancer de hardware de rede (Cisco) para que os clientes possam usar apenas 'ldap.business.com' como o nome do servidor LDAP, com os IPs reais dos 4 servidores ocultos.

Para LDAP simples, isso funciona bem, mas agora quero adicionar LDAPS usando TLS. O processo de instalação do certificado parece bem documentado no site do Fedora, mas não tenho certeza de como configurar o LDAPS para ser altamente disponível, já que certificado estrela não é permitido.

O DNS Round-robin não será robusto o suficiente, pois depende do TTL - ainda é possível ter uma interrupção do LDAP.

    

Answer 1

Tratamos os HA LDAPS no Novell eDirectory, mas o problema é semelhante. Conseguimos resolver o problema com nomes alternativos de assunto nos certificados. Sujeito-alternativo-nomes são, simplesmente, Sujeitos alternativos você pode pôr em um certificado para dar isto mais que um nome. É assim que você pode (teoricamente) ter um único certificado válido para pop3.organisation.org, imap.organisation.org e webmail.organisation.org. Eles são relativamente novos, mas não tão novos quanto os certificados de Validação Estendida.

A maioria dos clientes LDAP modernos é inteligente o suficiente para tratar corretamente os SANs. Além disso, gerenciamos a autoridade de certificação que cunhou os certificados, de modo que obter uma SAN é simples para nós. Não é tão simples se você vai acabar pagando por um certificado, o CA prefere comprar vários certificados. Infelizmente para muitas pessoas, alguns pacotes de software só podem carregar um certificado. É aqui que entra o SAN.

Usamos um balanceador de carga de hardware (F5 BiP) e três servidores LDAPS. Quando o configuramos pela primeira vez, criamos certificados apenas com o nome da rede do IP / DNS do balanceador de carga. Os clientes que se conectavam diretamente aos servidores LDAP recebiam erros de certificado, o que provou ser um incentivo para levar as pessoas a usar o endereço IP do balanceador de carga, como deveriam ter feito o tempo todo.

Desde então, passamos a usar os nomes alternativos de assunto, pois estava tendo alguns efeitos colaterais negativos com o software da Novell em execução nesses servidores. Mas conseguimos executá-lo sem SAN por um tempo. Cada certificado tem três nomes:

• Endereço IP do IP do balanceador de carga
• nome DNS do IP do balanceador de carga
• nome DNS do host direto

Isso expõe o nome do host de back-end para aqueles que bisbilhotam, mas não consideramos isso uma vulnerabilidade. Outros podem.

É o que fazemos e funciona para nós.

    

Answer 2

Você pode fazer o carregamento sem SSL no seu balanceador de carga. Você pode usar hardware, mas muitas vezes você tem que pagar por uma licença para o descarregamento. Ou você pode experimentar o haproxy, que é um loadbalancer gratuito, que suporta o descarregamento de SSL (versão dev) & gt ;. Outra opção é de fato usar nomes de alt de assunto em certificados, mas se você quiser aumentar a escala, será necessário reemitir todos os certificados.

Então, eu optaria pela opção de descarregamento de SSL com balanceamento de carga. Seja de hardware (você deve investigar os custos de licença) ou de software. Em seguida, verifique se o LB se conecta ao HTTP normal e coloque-o em um segmento de rede ao qual os usuários não podem se conectar. Talvez o haproxy não suporte o carregamento do ldap ssl e você precisa de outra solução. Você também pode usar o corosync / pacemaker e usar certificados.