freeipa ssl ldap e round robin dns

Question

Estou tentando fazer essa pergunta de uma maneira responsável, mas parte da questão é saber as implicações da minha situação atual e se há um problema ou uma dívida técnica que me afetará ainda mais.

Eu configurei alguns servidores IPA em um master & configuração de réplicas.

server1: dns Um registro (e fqdn hostname): srv1.mydomain.com

server2: dns Um registro (e fqdn hostname): srv2.mydomain.com

server3: dns Um registro (e fqdn hostname): srv3.mydomain.com

os servidores têm um cname de auth-a, auth-b, auth-c, respectivamente, e usam um certificado autoassinado conforme uma instalação normal do IPA.

Isso funcionou bem por meses para conexões ssh, e sssd e assim por diante. O problema chegou ao tentar ligar em aplicativos que permitem apenas que um servidor ldap seja especificado. Há configuração de registros de DNS SRV para failover, mas em uma tentativa de fazer com que esses aplicativos funcionem, eu também coloco um registro de round robin do dns.

O problema é que este round robin funciona apenas para pesquisas normais do ldap, não para o ldap ssl. Eu posso fazer o ssl funcionar, no entanto, se eu desabilitar a verificação no certificado ssl.

Então ... as perguntas!

a) realisticamente, quão ruim é desabilitar a verificação do certificado em um serviço interno? Este servidor ldap será consultado a partir da LAN, sempre. Acredito que estou aberto a um possível ataque MITM, mas não tenho certeza de como eu estou preocupado com isso. Quero dizer, agora minha outra opção não é usar SSL, e isso é um molho assustador. Para realizar o ataque MITM eles já precisariam estar na minha rede e ter controle do DNS, não? Qualquer conselho que pudesse quantificar essa preocupação em termos reais seria útil.

b) pelo que entendi para corrigir isso, eu preciso dar a entrada do RR dns como um nome de assunto no certificado auto-assinado do (s) servidor (es). Isso significa re-digitar o servidor, certo? que, no caso do IPA, significa reunir o todos os clientes ao IPA para o novo certificado. Isso é um não-inicial eu acho.

c) dada a situação atual eo resultado de (a) e (b), o que você recomendaria como o melhor curso de ação para permitir aplicativos que permitissem apenas um servidor ldap ser especificado (e não usasse o SRV dns? registros de qualquer forma) para failover para o outro servidor deve ir para baixo, e ainda permitir o ldap sobre SSL dando meus certificados?

    

Answer 1

Você deve emitir novos certificados com subjectAlternitiveNames e apontar o registro do DNS para esse nome em um balanceador de carga.

• A) Desativar a verificação de certificados abre você para o MITM. A vantagem é que um canal criptografado não pode ser passado passivamente. É mais trabalho para o MITM um canal criptografado, mas não é muito mais. Se você não é de alto valor e não opera através da Internet sem fio ou aberta (em oposição a um link de VPN), desligar a verificação de certificado não é muito arriscado, mas não o faça. Fazer as coisas da maneira certa é quase tão fácil.
• B) Sim, os servidores precisarão de um subjectAlternitiveName ou (e não faça isso) um subjectName curinga. No entanto , o FreeIPA faz sua própria PublicKeyInfrastucture (PKI), ou seja, você tem sua própria Autoridade de Certificação (CA) autoassinada, em vez de uma coleta de certificados auto-assinados. Isso significa que você só precisa gerar e substituir os certificados dos servidores FreeIPA (aqueles usados pelo LDAP). O certificado da CA usado para assinatura (que é o certificado implantado em todas as suas máquinas) permanece o mesmo, portanto, não há necessidade de tocar em nenhuma outra máquina. Além disso, você não precisa das chaves privadas dos servidores, apenas dos certificados públicos.
• C) Veja o topo, A e B são justificação.

Answer 2

O round robin dns não necessariamente dará mais disponibilidade no caso de falha do servidor, a menos que você esteja puxando o registro A / AAAA do dns, pois o cliente tentará aleatoriamente conectar-se a um dos servidores, incluindo o que falhou. . Se o aplicativo não tentar se reconectar, ou tiver azar e obtiver o mesmo registro em quantidade suficiente, ele falhará. Adicionar um balanceador de carga na frente adiciona complexidade extra, mas significa que essa possibilidade é diminuída. Se você estiver satisfeito com o round robin para compartilhamento de carga, eu verificaria se a inserção de um subjectaltname no certificado satisfaria os clientes a ldaps ou se um curinga não seria adequado. Impedir o homem nos meios também pode ser alcançado executando sua própria PKI interna e implantando isso como uma CA confiável em suas máquinas cliente. Isto tem a vantagem adicional de ser um local central, você pode ver certificados expirados ou expirados em vez de ter que gerenciar isso em cada host / serviço que tenha seu próprio certificado.

    

Answer 3

Se tudo o que você procura é HA, eu faria algo um pouco simplista, mas útil:

Configure um cluster de HA para IPA (para evitar problemas - basta executá-lo em uma VM, onde o serviço libvirt é o processo protegido) e usar essa instância do IPA para todos os aplicativos limitados, enquanto os outros IPAs tendem a autenticação do usuário . O IPA funciona muito bem no KVM, executei algumas instâncias com zero problemas ao longo de anos