[SSSD-users] SSSD with AD provider - can't obtain group information in subdomain

Jakub Hrozek jhrozek at redhat.com
Tue Aug 5 19:17:03 UTC 2014


On Tue, Aug 05, 2014 at 05:07:00PM +0900, 杉山昌治 wrote:
> Hello,
> 
> Thank you for your kind help.
> 
> I could not see it (successfully subdomains discovering) in the logs.
> It seems the subdmains forced set null.
> 
> << log part 1 >>
> [sssd[be[labsso]]] [client_registration] (0x0100): Cancel DP ID
> timeout [0x1acb120]
> [sssd[be[labsso]]] [client_registration] (0x0100): Added Frontend client [PAM]
> [sssd[be[labsso]]] [be_get_subdomains] (0x0400): Got get subdomains [forced][]
> [sssd[be[labsso]]] [fo_resolve_service_send] (0x0100): Trying to
> resolve service 'AD'
> [sssd[be[labsso]]] [get_server_status] (0x1000): Status of server
> 'jpbw0-in00-is82.labsso.labroot.isops.example.com' is 'name not
> resolved'
> [sssd[be[labsso]]] [get_port_status] (0x1000): Port status of port 0
> for server 'jpbw0-in00-is82.labsso.labroot.isops.example.com' is
> 'neutral'
> [sssd[be[labsso]]] [get_server_status] (0x1000): Status of server
> 'jpbw0-in00-is82.labsso.labroot.isops.example.com' is 'name not
> resolved'
> [sssd[be[labsso]]] [resolv_gethostbyname_files_send] (0x0100): Trying
> to resolve A record of
> 'jpbw0-in00-is82.labsso.labroot.isops.example.com' in files
> [sssd[be[labsso]]] [set_server_common_status] (0x0100): Marking server
> 'jpbw0-in00-is82.labsso.labroot.isops.example.com' as 'resolving name'
> [sssd[be[labsso]]] [resolv_gethostbyname_files_send] (0x0100): Trying
> to resolve AAAA record of
> 'jpbw0-in00-is82.labsso.labroot.isops.example.com' in files
> [sssd[be[labsso]]] [resolv_gethostbyname_next] (0x0200): No more
> address families to retry
> [sssd[be[labsso]]] [resolv_gethostbyname_dns_query] (0x0100): Trying
> to resolve A record of
> 'jpbw0-in00-is82.labsso.labroot.isops.example.com' in DNS
> << end log part 1 >>
> 
> I also found an error (malformed search filter) when searching
> trustedDomain with "cn=(null)".

This shouldn't happen -- we have a bug in SSSD.

> 
> << log part 2 >>
> [sssd[be[labsso]]] [fo_set_port_status] (0x0400): Marking port 0 of
> duplicate server 'jpbw0-in00-is82.labsso.labroot.isops.example.com' as
> 'working'
> [sssd[be[labsso]]] [sdap_get_generic_ext_step] (0x0400): calling
> ldap_search_ext with
> [objectclass=domain][DC=labsso,DC=labroot,DC=isops,DC=example,DC=com].
> [sssd[be[labsso]]] [sdap_get_generic_ext_step] (0x1000): Requesting
> attrs: [objectSID]
> [sssd[be[labsso]]] [be_run_online_cb] (0x0080): Going online. Running callbacks.
> [sssd[be[labsso]]] [sdap_get_generic_ext_done] (0x0400): Search
> result: Success(0), no errmsg set
> [sssd[be[labsso]]] [ad_master_domain_next_done] (0x0400): Found SID
> [S-1-5-21-1401708884-2744904820-804000056].
> [sssd[be[labsso]]] [sdap_get_generic_ext_step] (0x0400): calling
> ldap_search_ext with [(&(DnsDomain=LABSSO)(NtVer=\14\00\00\00))][].
> [sssd[be[labsso]]] [sdap_get_generic_ext_step] (0x1000): Requesting
> attrs: [netlogon]
> [sssd[be[labsso]]] [sdap_get_generic_ext_done] (0x0400): Search
> result: Success(0), no errmsg set
> [sssd[be[labsso]]] [ad_master_domain_netlogon_done] (0x0080): No

Here is where things start to go south. We're not able to retrieve the
netlogon data, which means we're not able to retrieve the forest we're
part of. Later we hit the SSSD bug where we continue searching despite
the forest being NULL.

Because we can't find the forest root, we're not able to see all trusted
domains, which I think is the reason for your trouble. Thank you very
much for your persistence, I'm glad we found the issue.

But before I send a patch to abort the request when we can't determine
the forest, I'd like to debug why we can't see the forest data.. 

Can you try this ldapsearch?

ldapsearch -Y GSSAPI -H
ldap://jpbw0-in00-is82.labsso.labroot.isops.example.com -b '' -s base
'(&(DnsDomain=LABSSO)(NtVer=\14\00\00\00))' netlogon

The attribute would not be human-readable if found.

Are you aware of any non-standard access control on your server?

Can you run the same search against a different server, maybe the forest
root?

Thank you very much for your help


More information about the sssd-users mailing list