LeeM's questions

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

Descobrimos que a conta de administrador do domínio - que não usamos, exceto no caso de um cenário de recuperação de desastre - tem uma data recente no atributo LastLogonTimeStamp. Tanto quanto sei, ninguém deveria ter usado esta conta no período em questão (e vários meses além), mas talvez algum idiota a tenha configurado para executar uma tarefa agendada.

Devido à quantidade de eventos de log de segurança (e falta de ferramenta SIEM para análise), eu queria determinar qual DC tinha o tempo lastLogon real (ou seja, não o atributo replicado) para a conta, mas consultei todos os DC no domínio, e cada um deles tem um lastLogon de "nenhum" para Administrador.

Este é um domínio filho na floresta, portanto, é possível que alguém tenha usado essa conta de administrador do domínio filho para executar algo no domínio pai.

Alguém pode pensar em uma maneira de determinar qual controlador de domínio está fazendo o logon, além de examinar os 20 milhões de eventos potenciais de 16 controladores de domínio da floresta por volta do tempo registrado em LastLogonTimestamp? Suponho que poderia direcionar os DCs de domínio pai primeiro (já que os DCs filhos parecem não ter feito a autenticação).

Explicação

[Adicionado após zerar a causa após repadmino uso conforme abaixo]

O motivo original dessa solicitação foi devido à nossa equipe de segurança de TI, que estava se perguntando por que aparentemente estávamos fazendo logon com a conta de administrador de domínio padrão com frequência.

Sabíamos que não estávamos logando. Acontece que existe um mecanismo chamado "Kerberos S4u2Self" que ocorre quando um processo de chamada em execução como Sistema Local está fazendo algum escalonamento de privilégios. Ele faz um logon de rede (não interativo) como administrador em um controlador de domínio. Como não é interativo, é por isso que não há lastLogonconta em nenhum DC (essa conta nunca foi conectada a nenhum controlador de domínio atual).

Este artigo explica por que a coisa executa pings em seus logs e faz com que sua equipe de segurança tenha gatinhos (as máquinas de origem são Server 2003, para piorar as coisas). E como rastreá-lo. https://blogs.technet.microsoft.com/askpfeplat/2014/04/13/how-lastlogontimestamp-is-updated-with-kerberos-s4u2self/

Lição aprendida - apenas forneça relatórios sobre lastLogonatributos às equipes de segurança de TI quando se tratar de logons de administrador.