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