Load balancing LDAP de um controlador de domínio via F5

Question

Eu sei que o balanceamento de carga ou failover de LDAP em um controlador de domínio do Windows geralmente não é uma boa ideia devido aos problemas de Kerberos e SPN.

MAS, eu tenho muitos aplicativos não-Windows que usam o LDAP para autenticação e autorização. Eles estão apenas apontando para um único controlador de domínio agora, seria bom ter um VIP e um pool com todos os meus DC's por trás dele.

Então, qual é o problema aqui quando vejo isso?:

link

O F5 faz algo especial? Isso apenas recorre ao NTLM? Ou apenas usa uma ligação LDAP simples ao AD? (ou ligação SLDAP).

Qual é a melhor maneira de clientes não Windows utilizarem o LDAP? Eles devem ser projetados apenas para uso dos registros SRV do localizador de DNS? O AD-LDS deve ser implantado e balancear a carga?

Há algo que estou perdendo?

    

Answer 1

Sim, os aplicativos que desejam interagir com o Active Directory realmente devem ser projetados para usar procedimentos apropriados de localização de DC (que são bem documentados); infelizmente, muitas vezes não são.

Normalmente, é possível solucionar isso apontando seu aplicativo LDAP para o nome de domínio do Active Directory em vez de um DC específico, porque cada DC registra automaticamente um registro AN para o nome de domínio apontando para seu endereço IP, portanto, isso funcionará como um DNS round robin; no entanto, isso pode e causará dois problemas significativos:

• Se um DC estiver inativo, ele ainda será incluído na resposta do DNS; isso pode causar falhas no LDAP se o aplicativo não for inteligente o suficiente para tentar outro.
• Isso não levará em conta a topologia do site do Active Directory; se você tiver um ambiente distribuído geograficamente, poderá ter um aplicativo em Londres autenticado em um DC na Austrália por meio de um link WAN lento e / ou não confiável.

Uma solução um pouco melhor é criar seu próprio registro DNS para aplicativos LDAP como um registro CNAME apontando para um DC específico, como ldap.example.com apontando para dc1.example.com e definindo um TTL lento nele (fe 60 segundos) ; Em seguida, você pode configurar seu aplicativo para usar ldap.example.com para todas as suas necessidades de LDAP. Se / quando o DC1 ficar inativo, você poderá remapear ldap.example.com para dc2.example.com e o TTL lento garantirá que o aplicativo tome conhecimento da alteração o quanto antes, minimizando o tempo de inatividade.

Em qualquer caso, é realmente melhor evitar a solução de balanceamento de carga, porque o LDAP simplesmente não foi projetado para funcionar com eles e eles poderiam ser carregados para qualquer tipo de problema.

    

Answer 2

Quase todos os produtos de autenticação LDAP que não são do Windows que vi são capazes de usar uma entrada DNS. Em vez de apontar para um servidor específico, você pode apontar para a raiz do seu domínio. Isso deve funcionar na grande maioria das situações.

Este é o caso, porque se você fizer uma pesquisa na raiz do seu domínio, por exemplo example.com deve voltar com todos os IPs dos seus controladores de domínio. Isso permite que o DNS round robin padrão assuma, sem precisar de nenhum tipo de configuração especializada.

    

Answer 3

Um desafio ao usar um balanceador de carga é, dependendo da atividade, alguns aplicativos podem solicitar um identificador para um DirectoryEntry. O DirectoryEntry inclui o nome do servidor. Isso é mais comum para atualizações, mas também pode ocorrer para leituras / consultas. Obviamente, você não está passando pelo balanceador de carga nesse caso. Seria bom o suficiente para autenticação? Talvez.

Eu aprendi que se você disponibilizar um serviço, as pessoas podem usá-lo para outro que não seja o que você pretende. Então, esse VIP "autenticação apenas" você configura? Talvez alguém decida usá-lo para outra coisa. Isso é realmente importante. O que acontece se explodir?

Outra questão é quais são as verificações de saúde? Não é incomum que um controlador de domínio esteja na porta 389/636, mas não esteja funcionando corretamente. Portanto, uma verificação de porta reta pode não ser suficiente.

Tradicionalmente, a resiliência de conexão do Active Directory (o processo do Localizador do DC) é enviada para o cliente. Quando você começa a mexer com isso para torná-lo "altamente disponível", você se apropria de problemas. E algumas dessas questões podem ser difíceis e difíceis de diagnosticar e resolver. Quem vai te apoiar? F5 Microsoft? Boa sorte com isso.

    

Answer 4

É mais sobre alta disponibilidade ou desempenho?

Para o desempenho, quero destacar isso:

I have lots of non-windows applications that use LDAP for authentication and authorization. They are just pointed to a single domain controller right now.

A solução rápida óbvia aqui é apontar alguns de seus aplicativos em seus DCs adicionais. É claro que isso não é ideal porque deixa os aplicativos vulneráveis se um DC cair, mas é uma maneira fácil de ajudar a espalhar sua carga imediatamente.

Para alta disponibilidade, você pode apontar aplicativos no nome do domínio ou (melhor ainda) um nome do domínio. Não é ótimo, porque significa um ajuste manual do DNS se algo der errado, mas facilitará a resposta.

Você pode combinar essas técnicas usando registros cname para vários DCs. A carga está espalhada e você pode ajustar facilmente um registro cname para um DC individual no caso de uma interrupção.

    

Answer 5

Eu tenho 3 servidores em um VIP para essa circunstância.

Além disso, o uso do nome de domínio costuma ser ruim, porque ele atingirá o primeiro DC da lista retornado, se o aplicativo não estiver ciente do site (a maioria não é). Isso poderia estar em qualquer lugar do país e isso seria ruim para a carga e a latência da WAN.