Balanceamento de carga e failover de autenticação do Active Directory

Question

Para aplicativos que autenticam em um DC do Active Directory, obviamente seria melhor apenas apontá-los para o registro DNS do domínio principal em vez de um DC específico para failover, balanceamento de carga, etc.

Quais são as práticas recomendadas para esses aplicativos que forçam você a codificar um IP de DC? Poderíamos codificar com firmeza o endereço IP de um balanceador de carga, portanto, se um DC caísse, o aplicativo ainda seria capaz de autenticar. Existem alternativas melhores?

    

Answer 1

O Active Directory já possui técnicas de balanceamento de carga incorporadas. Seu cliente Windows sabe como localizar os controladores de domínio redundantes em seu próprio site e como usar outro se o primeiro não estiver disponível. Não há necessidade de realizar balanceamento de carga adicional, como DCs "em cluster", etc., desde que você tenha DCs redundantes.

De certa forma, você pode pensar em um site do Active Directory como um "balanceador de carga", porque os clientes desse site escolherão aleatoriamente um dos DCs no mesmo site. Se todos os DCs em um site falharem ou se o site não tiver DCs, os clientes escolherão outro site (o site mais próximo ou aleatório).

Você pode fazer o balanceamento de carga do serviço DNS fornecido pelo Active Directory para clientes ingressados no domínio, colocando um VIP em um balanceador de carga de hardware e tendo esse equilíbrio de carga VIP entre vários dos controladores de domínio. Em seguida, em seus clientes, coloque esse VIP como o servidor DNS preferencial na configuração TCP / IP.

Estou fazendo isso agora para uma infraestrutura global e está funcionando muito bem.

Mas isso somente se aplica ao serviço DNS.

Não tente fazer o balanceamento de carga de seus controladores de domínio para autenticação. Está pedindo por problemas. Você teria pelo menos de fazer um monte de trabalho complexo de SPN personalizado e estaria se jogando fora dos limites de suporte da Microsoft. De este blog, que você deve ler , vou citá-lo:

Go back to the vendors and tell them you don’t consider them to be AD Integrated and you will find a different solution.

Agora, no caso de aplicativos que solicitam o endereço IP de um controlador de domínio? Bem, vou apenas reiterar meu comentário:

Whoever wrote an application that forces you to hardcode the IP address of a domain controller into it doesn't know what he or she is doing.

    

Answer 2

nunca houve um bom motivo para codificar um IP ou usar um IP para resolver consultas do AD. Não há práticas recomendadas para práticas ruins.

    

Answer 3

Uma necessidade real de AD "Balanceamento de carga" externo é rara e é difícil de ser feita corretamente. A necessidade de consultas típicas pode funcionar bem, no entanto, um cliente e aplicativos típicos do Windows precisam executar atualizações. Um cliente Windows tenta estabelecer uma afinidade com um determinado dc, de modo que, se ele atualizar alguma coisa e tentar imediatamente uma operação subsequente, ela atinge o mesmo dc. Os desenvolvedores de aplicativos fazem a mesma coisa. Se você escrever um código que crie uma conta de usuário e, em seguida, tentar alterar a senha dessa conta em 1 ms mais tarde, será necessário pressionar o mesmo dc.

Se você fosse o front-end do AD com alguma solução de balanceador de carga, você se apropriar de garantir que essas abordagens e afinidades não se quebrem.

Se a necessidade for a disponibilidade, ao contrário do balanceamento de carga, o agrupamento pode ser mais apropriado (cluster worms de lado).

Em grandes implementações de AD, uma abordagem mais tradicional é identificar os consumidores majoritários e colocá-los em um site com seus próprios dc's. Por exemplo, se você tiver cinco servidores Exchange, crie um site para as sub-redes desses servidores e coloque os GCs dedicados nesse site. O mesmo se aplica a outros servidores, como o SharePoint.

    

Answer 4

Várias das outras respostas a essa pergunta parecem supor que não existe outro mundo além dos aplicativos da Microsoft. Infelizmente este não é o caso, como evidência pela pergunta original:

What are best practices for those applications that force you to hardcode a DC's IP?

Embora a Microsoft não suporte ou recomende o uso de uma solução NLB na frente do Active Directory, de fato, parece haver algumas opções para a autenticação de aplicativos não compatíveis com o Microsoft AD.

• Noções Básicas Sobre Autenticação de Proxy no AD LDS
• F5 Certified iApp para carga balanceamento de LDAP
• Autenticação Pass-Trough com SASL