O SSSD falha na descoberta de serviço do Catálogo Global do AD, apesar de URIs explicitamente definidos

Question

Estou com problemas com a integração do SSSD e do Active Directory. Meu AD é configurado com uma configuração de 9 controladores de domínio, alguns dos quais são protegidos por firewall e inacessíveis por vários motivos de segurança. Portanto, a descoberta de serviço não funcionará com o SSSD. Isso deve ser bom, pois eu deveria ser capaz de definir explicitamente os URIs conforme necessário.

Eu tenho as seções relevantes do meu sssd.conf que definem esses URIs, assim:

[domain/ad.utah.edu]
ldap_uri = ldap://myserver.domain
ldap_backup_uri = ldap://backup-server.domain
krb5_server = myserver.domain

No entanto, ao tentar testar essa configuração com um grupo getent [email protected], vejo essas mensagens no início da atividade relacionada a essa pesquisa nos logs de domínio sssd (debuglevel = 9):

(Tue Nov  7 17:20:26 2017) [sssd[be[mydomain]]] [sdap_id_op_connect_step] (0x4000): beginning to connect
(Tue Nov  7 17:20:26 2017) [sssd[be[mydomain]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'AD_GC'
...
(Tue Nov  7 17:20:26 2017) [sssd[be[mydomain]]] [ad_get_dc_servers_send] (0x0400): Looking up domain controllers in domain mydomain
(Tue Nov  7 17:20:26 2017) [sssd[be[mydomain]]] [resolv_discover_srv_next_domain] (0x0400): SRV resolution of service 'ldap'. Will use DNS discovery domain 'mydomain'

Ele finalmente encontra um CD inacessível e falha na resolução do serviço:

(Tue Nov  7 17:20:26 2017) [sssd[be[mydomain]]] [sdap_connect_host_resolv_done] (0x0400): Connecting to ldap://inaccessible-host.mydomain:389
....
(Tue Nov  7 17:20:56 2017) [sssd[be[mydomain]]] [fo_resolve_service_timeout] (0x0080): Service resolving timeout reached
(Tue Nov  7 17:20:56 2017) [sssd[be[mydomain]]] [sss_ldap_init_state_destructor] (0x0400): closing socket [26]
(Tue Nov  7 17:20:56 2017) [sssd[be[mydomain]]] [sdap_handle_release] (0x2000): Trace: sh[0xc861f0], connected[0], ops[(nil)], ldap[(nil)], destructor_lock[0], release_memory[0]
(Tue Nov  7 17:20:56 2017) [sssd[be[mydomain]]] [be_resolve_server_done] (0x1000): Server resolution failed: 14
(Tue Nov  7 17:20:56 2017) [sssd[be[mydomain]]] [sdap_id_op_connect_done] (0x0400): Failed to connect to server, but ignore mark offline is enabled.
(Tue Nov  7 17:20:56 2017) [sssd[be[mydomain]]] [sdap_id_op_connect_done] (0x4000): notify error to op #1: 5 [Input/output error]
(Tue Nov  7 17:20:56 2017) [sssd[be[mydomain]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,5,Group lookup failed

Eu vasculhei as páginas do manual procurando uma opção para desabilitar a descoberta de serviço (parece que deveria ser feito especificando os URIs que eu defini em minha configuração), ou alguma opção para controlar o comportamento deste serviço 'AD_GC' ( que eu deduzi é o serviço AD Global Catalog deste artigo: link ).

Estou perplexo, no entanto, sobre como controlar esse comportamento e desativá-lo ou apontá-lo para o servidor apropriado.

Estou executando o SSSD versão 1.13.4 no Ubuntu 16.04.3 se isso ajudar em tudo.

    

Answer 1

Depois de algumas sugestões perguntando por que havia registros DNS SRV para servidores inacessíveis, percebi que todos os controladores de domínio tinham informações de "site" descrevendo quais sites eles deveriam servir. Acontece que o SSSD pode ser direcionado para usar sites específicos ao descobrir serviços com esta opção de configuração:

dns_discovery_domain = SiteName._sites.example.com

Especificar esta informação não foi totalmente suportada (a descoberta do keberos não respeitou a especificação do site) até que a versão 1.12 se pareça ( link ).

Tanto quanto eu posso dizer, o SSSD não deve fazer nenhuma descoberta de serviço se eu tiver definido explicitamente o LDAP e o URI do kerberos, mas pelo menos eu tenho uma solução para o meu problema original.

    

Answer 2

Eu não sei sobre o SSSD - no entanto, sei a relação entre o AD e o DNS. Esta linha SRV resolution of service 'ldap' combinada com o fato de que você isolou propositalmente Controladores de Domínio, leva-me a acreditar que está ocorrendo um erro ao tentar consultar um DC isolado a partir da lista de registros SRV do LDAP no domínio. Se esse for o caso, impedir que os DCs registrem seus registros SRV no DNS .

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
Value name: DnsAvoidRegisterRecords
Data type: REG_MULTI_SZ 
Data value: Ldap