Learn more about these different git repos.
Other Git URLs
I have an IPA deployment which uses existing DNS infrastructure for the IPA servers and its own DNS infra for IPA clients, i.e. DNS domain for IPA clients is different from DNS domain for IPA server. There is also trust established between IPA realm and Active Directory domain which uses own DNS and IPA DNS has forwarders to AD DNS.
IPA server is vm-179.idm.lab.eng.brq.redhat.com, IPA domain is idm.lab. AD domain is dom2.bar.
When trust is established, SSSD correctly pulls information about it from IPA LDAP server but fools itself when resolving LDAP and KDC services -- instead of following dom2.bar DNS domain it resolves LDAP and KDC services against idm.lab DNS domain. It then goes to contact resolved LDAP server (IPA LDAP server) instead of AD DC. As result, no users from AD could be found.
The issue is reproducible with 1.11.0-0.2.beta2.fc19.x86_64 and 1.11.1-0.20130905T0943Zgit0e5758d.fc19.x86_64 from ipa-devel repo. I believe it is not fixed by git commit de307ab as Jakub suspected.
(Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=administrator] (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'dom2.bar' (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [get_port_status] (0x1000): Port status of port 0 for server '(no name)' is 'neutral' (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [resolve_srv_send] (0x0200): The status of SRV lookup is neutral (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [ad_srv_plugin_send] (0x0400): About to find domain controllers (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [ad_get_dc_servers_send] (0x0400): Looking up domain controllers in domain idm.lab (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [resolv_discover_srv_next_domain] (0x0400): SRV resolution of service 'ldap'. Will use DNS discovery domain 'idm.lab' (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [resolv_getsrv_send] (0x0100): Trying to resolve SRV record of '_ldap._tcp.idm.lab' (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [request_watch_destructor] (0x0400): Deleting request watch (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [fo_discover_srv_done] (0x0400): Got answer. Processing... (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [fo_discover_srv_done] (0x0400): Got 1 servers (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [ad_get_dc_servers_done] (0x0400): Found 1 domain controllers in domain idm.lab (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [ad_srv_plugin_dcs_done] (0x0400): About to locate suitable site (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [sdap_connect_host_send] (0x0400): Resolving host vm-179.idm.lab.eng.brq.redhat.com (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [resolv_is_address] (0x4000): [vm-179.idm.lab.eng.brq.redhat.com] does not look like an IP address (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [resolv_gethostbyname_step] (0x2000): Querying files (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'vm-179.idm.lab.eng.brq.redhat.com' in files (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [sdap_connect_host_resolv_done] (0x0400): Connecting to ldap://vm-179.idm.lab.eng.brq.redhat.com:389 (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [sss_ldap_init_send] (0x4000): Using file descriptor [24] for LDAP connection. (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [sss_ldap_init_send] (0x0400): Setting 6 seconds timeout for connecting (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://vm-179.idm.lab.eng.brq.redhat.com:389/??base] with fd [24]. (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [sdap_connect_host_done] (0x0400): Successful connection to ldap://vm-179.idm.lab.eng.brq.redhat.com:389 (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(DnsDomain=dom2.bar)(NtVer=\14\00\00\00))][]. (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [netlogon] (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 1 (Sat Sep 7 08:52:05 2013) [sssd[be[idm.lab]]] [sdap_process_result] (0x2000): Trace: sh[0x7f42caabfda0], connected[1], ops[0x7f42caa94fa0], ldap[0x7f42caab21a0]
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.11.1
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1007470
rhbz: => [https://bugzilla.redhat.com/show_bug.cgi?id=1007470 1007470]
Hi, I'm using very similar setup myself without any troubles.
Do you have dns_discovery_domain option set? Either in client's sssd.conf or on IPA server?
no dns_discovery_domain setting anywhere. The setup was obtained by simply running ipa-server-install and not redefining the hostname.
Note that when resolving domain controllers for dom2.bar, it instead tries to resolve domain controllers for idm.lab. That's the key point where wrong handling happens -- everything afterwards basically correct, just that wrong domain was used for the discovery purposes.
I know that Sumit was going to look into this issue as well, so please make sure you don't duplicate the effort.
I'm pretty sure it is dns_discovery_domain. I reproduced Alexanders setup in the Brno lab and if the DNS domain of the ipa-server is different than the IPA domain ipa-client-install will set dns_discovery_domain. But this is useless on an IPA server, since the ipa_server option is set to the local host and nothing else, i.e. no srv. So on the IPA server dns_discovery_domain is useless because it is not needed to find the IPA server via DNS SRV lookups. And on a client it would do no harm, because the client will only talk to the IPA servers and not try to resolve AD DCs.
So currently for me it looks that it should be fixed on the IPA side, but I will do some more investigations.
If you don't mind Sumit, I'll assign the ticket to you, then to prevent other developers from duplicating the effort.
owner: somebody => sbose
After Sumit patiently explained the problem to me several times, I reproduced it and have a local patch now.
owner: sbose => jhrozek status: new => assigned
patch: 0 => 1
resolution: => fixed status: assigned => closed
Metadata Update from @abbra: - Issue assigned to jhrozek - Issue set to the milestone: SSSD 1.11.1
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/3121
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.