Como tornar o AD altamente disponível para aplicativos que o usam como um serviço LDAP

Question

Nossa situação

Atualmente, temos muitos aplicativos da web que usam LDAP para autenticação. Para isso, apontamos o aplicativo da web para um de nossos controladores de domínio do AD usando a porta LDAPS ( 636 ).

Quando temos que atualizar o controlador de domínio, isso nos causou problemas porque mais um aplicativo da Web pode depender de qualquer controlador de domínio.

O que queremos

Gostaríamos de apontar nossos aplicativos da web para um IP "virtual" de cluster. Esse cluster consistirá em pelo menos dois servidores (para que cada servidor de cluster possa ser rotacionado e atualizado). Os servidores de cluster, em seguida, proxy conexões LDAPS para os DCs e ser capaz de descobrir qual deles está disponível.

Perguntas

Para quem já teve experiência com a criação de um cluster de alta disponibilidade para a interface LDAP do AD:

1. Qual software você usou para o cluster?
2. Alguma advertência?
3. Ou talvez uma arquitetura completamente diferente para realizar algo semelhante?

Atualizar

Talvez a minha pergunta não tenha sido inicialmente clara o suficiente. Minhas desculpas por isso.

Estas aplicações web não são desenvolvidas por nós e não são compatíveis com AD. Eles apenas solicitam o nome de host / endereço IP de um servidor LDAP. Infelizmente, temos que trabalhar com essa restrição. Eu entendo como o SRV records funciona mas, sendo estes não são nossos aplicativos, não nos ajuda neste caso.

Também não é realista para nós forçar os desenvolvedores a modificar seus aplicativos para serem conscientes do AD.

A única opção é resolver esse problema dentro da infraestrutura, em oposição ao software. Minhas perguntas são direcionadas a qualquer um que tenha feito isso especificamente.

    

Answer 1

Nós usamos o Balanceador de carga de servidor (SLB) do Cisco IOS para isso contra nossos servidores OpenLDAP.
LDAP sendo LDAP, deve funcionar também para o Active Directory da Microsoft.
Outros fabricantes oferecem produtos / capacidades similares. O balanceamento do tcp 389/636 é o mesmo que balancear o tcp 80/443 (ou qualquer outro tcp).

Você pode ter alguns problemas de certificado para funcionar. Você pode ser capaz de dizer ao aplicativo para ser menos vigilante. (Pode já ser, não tenho certeza de como os certificados do seu AD estão assinados ou de quais CAs você confia.) Ou faça com que seus servidores AD usem certificados com os campos subjectAlternativeName apropriados.

    

Answer 2

Você deve conseguir apenas apontar seus servidores de aplicativos da web para o FQDN do domínio do Active Directory. Isso deve conectá-los a um DC disponível.

Por exemplo, seu domínio pode ter alguns CDs:

dc1.example.com

dc2.example.com

Em vez de apontar seus servidores da Web em dc1 ou dc2 explicitamente, basta apontá-los em example.com (tente telnetar para example.com na porta 636 - você terá uma conexão com um DC). Eu acho que é basicamente round robin DNS.

Devo admitir que não sei o que aconteceria se um DC estivesse offline. Pode demorar um pouco para os registros do DNS refletirem isso, se é que de fato ocorreriam. Pode valer a pena testar em vez de colocar um balanceador de carga no meio.

    

Answer 3

A maneira correta de fazer isso é usar os registros DNS SRV para procurar os nomes e portas do controlador de domínio, bem como verificar quais servidores usar em qual ordem. Infelizmente, não são muitos os aplicativos LDAP que oferecem suporte a pesquisas de registros SRV.

O registro SRV para os controladores de domínio do Active Directory é _ldap._tcp.domain.tld . Isso retornará uma lista de hosts e portas, bem como uma prioridade e um peso para cada um (esses valores podem ser definidos usando a Diretiva de Grupo) que juntos indicam qual servidor usar.

    

Answer 4

O aplicativo precisa ser robusto o suficiente para fazer o que os clientes Windows fazem internamente se um controlador de domínio não estiver disponível - ele tenta se conectar a outro controlador de domínio.

A maneira como isso funcionaria é quando o aplicativo é iniciado, o componente de acesso ao Serviço de Diretório do aplicativo faria o seguinte:

• Crie uma lista de todos os controladores de domínio no site (e em sites adjacentes, se preferir)
• Execute uma série de testes para validar a conectividade (ping, teste 389/3268/636). Isso também confirmaria se é um DC, GC ou RODC.
• Realize uma consulta simples para validar se o serviço de diretório está funcionando e se a autenticação está funcionando.
• Salve uma lista dos controladores de domínio bons conhecidos e também uma lista dos controladores de domínio offline.

Em seguida, você usa esses servidores bons conhecidos ao executar uma ligação, incorporando o servidor no caminho de ligação. Se ocorrer uma exceção e for um dos tipos que indicaria um problema com o dc (servidor não operacional, ocupado, tempo limite, etc), inclua esse dc na lista off-line e tente a operação usando um dos outros dc's.

    

Answer 5

Uma possível solução é um servidor proxy LDAP. Não há muitos por aí, mas definitivamente vai fazer o truque. Aqui está um, um pouco exagerado - link . Tenho certeza de que existem alternativas de código aberto muito mais baratas para esse servidor proxy LDAP.

EDIT: apenas um pensamento, dentro de sua aplicação, você tem um local para inserir o URI do LDAP? Em caso afirmativo, você não pode inserir uma seqüência de servidores separados por espaço como: ldap: //123..456.789.111 ldap: //123.456.789.222 ldap: //123.456.789.444

    

Answer 6

Como os certificados se tornarão o maior problema depois que você decidir usar um balanceador de carga ou confiar no round-robin do DNS (ou seja, ldap.contoso.com resolverá vários IPs), Russell Tomkins (MSFT) publicou um guia para esses casos de uso aqui: Criando certificados LDAP seguros personalizados para controladores de domínio com Renovação Automática

Ele também observa que esta não é uma configuração suportada. Como outras respostas notam, os aplicativos devem usar os registros SRV, mas geralmente não são.

Você basicamente precisa adicionar um novo modelo para emitir certificados, no qual você alterna para "Fornecer em solicitação" na guia de propriedades "Nome do assunto". Você terá que emitir o primeiro certificado fornecendo o nome do seu balanceador de carga (ldap.contoso.com) como um SN adicional e, a partir daí, o registro automático assumirá.