Tenho um ambiente AD e no ldapsearch, consigo usar registros SRV no DNS para resolver os servidores LDAP no domínio e em um site.
Isso funciona muito bem na porta ldap usual em 389, com autenticação básica e STARTTLS.
No entanto, alguns clientes horríveis não fazem STARTTLS ou o fornecedor não consegue fornecer um método para configurá-lo.[1] Portanto, precisamos fornecer uma opção para LDAPS em 636.
Em princípio, acredito que criar registros SRV ldaps e usar o ldaps:///URI deve funcionar. Criei 2 registros SRV ldaps na zona de domínio (há 3 hosts ldap), mas quando faço ldapsearche especifico ldaps:///, tudo o que está descobrindo são os hosts ldap.
Aqui está o ldapsearchcomando - aqui está retornando três DCs com _ldap SRVs na porta 389
$ ldapsearch -v -H "ldaps:///dc%3Devl%2Cdc%3Dexample%2Cdc%3Dcom" -D "user" -W -b "DC=evl,DC=example,DC=com" -b "" -s base "(objectclass=*)" -d 1
ldap_url_parse_ext(ldaps:///dc%3Devl%2Cdc%3Dexample%2Cdc%3Dcom)
ldap_initialize( ldaps://EVLADC002vs.evl.example.com:389 ldaps://EVLADC001vs.evl.example.com:389 ldaps://EVLADC006vs.evl.example.com:389 )
ldap_create
ldap_url_parse_ext(ldaps://EVLADC006vs.evl.example.com:389)
ldap_url_parse_ext(ldaps://EVLADC001vs.evl.example.com:389)
ldap_url_parse_ext(ldaps://EVLADC002vs.evl.example.com:389)
No entanto, a máquina cliente pode resolver os dois SRVs para _ldaps, com a porta 636
$ dig -t SRV _ldaps._tcp.evl.example.com +short
0 100 636 EVLADC002vs.evl.example.com.
0 100 636 EVLADC001vs.evl.example.com.
Aqui está o SRV LDAP para comparação
$ dig -t SRV _ldap._tcp.evl.example.com +short
0 100 389 EVLADC001vs.evl.example.com.
0 100 389 EVLADC006vs.evl.example.com.
0 100 389 EVLADC002vs.evl.example.com.
Se eu consultar um servidor específico no ldaps, está tudo bem
$ ldapsearch -H ldaps://evladc001vs.evl.example.com -D "user" -W -b "" -s base "(objectclass=*)"
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: ALL
#
#
dn:
currentTime: 20200213045340.0Z
subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=evl,DC=example,DC=com
dsServiceName: CN=NTDS Settings,CN=EVLADC001VS,CN=Servers,CN=Server,CN=Sites,CN=Configuration,DC=evl,DC=example,DC=com
...
Eu apreciaria qualquer conselho sobre se estou perdendo alguma opção ou outra coisa óbvia sobre esse problema.
[1]: Por favor, não comece com palestras sobre o uso de produtos diferentes. Grandes empresas têm problemas de integração, não importa o que aconteça - tente dizer aos sistemas hospitalares para comprar softwares multimilionários diferentes para seus requisitos específicos
Provavelmente não é a resposta que você queria obter:
A RFC 2782 especifica o uso de DNS SRV RRs para LDAP. Naquela época, a recomendação geral do IETF era habilitar a transmissão de dados criptografados por TLS na mesma porta, como a transmissão de texto simples. Assim, o uso de DNS SRV RRs para LDAPS (TLS anterior ao LDAP) nunca foi especificado.
Em geral, usar DNS SRV RRs para localizar servidores TLS é uma coisa ruim de se fazer.
Para evitar ataques MITM, o cliente TLS deve verificar a identidade e a chave pública do servidor TLS em relação às informações de conexão configuradas (consulte RFC 6125 ). Para a maioria das conexões TLS, o cliente TLS verifica se o certificado do servidor TLS contém o nome DNS usado para estabelecer a conexão. Nesse caso, o certificado do servidor TLS, assinado por uma CA confiável, contém uma ligação criptográficamente segura entre o nome DNS do servidor usado pelo cliente e a chave pública do servidor.
Se você procurar primeiro o nome de host do servidor TLS a ser usado para conectar via SRV RRs, então você terá que especificar quais informações devem estar no certificado do servidor TLS para ter uma ligação segura criptograficamente para o nome DNS usado para pesquisa SRV (por exemplo, o dc -style DN conforme definido na RFC 2377 ). Não conheço nenhuma especificação para isso.
Pode-se argumentar que o DNSSEC é uma solução para proteger a pesquisa SRV, mas o cliente também precisaria de um resolvedor confiável local fazendo a validação DNSSEC e o cliente TLS teria que verificar se a validação DNSSEC foi bem-sucedida (consulte também os requisitos de segurança para DANE para SMTP).