RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1007470 - SSSD subdomains provider does not resolve SRV records correctly when DNS name of the server is different from domain/realm name of IPA install in IPA server mode
Summary: SSSD subdomains provider does not resolve SRV records correctly when DNS name...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Jakub Hrozek
QA Contact: Kaushik Banerjee
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-12 14:37 UTC by Dmitri Pal
Modified: 2020-05-02 17:28 UTC (History)
8 users (show)

Fixed In Version: sssd-1.11.1-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 12:21:57 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 3121 0 None closed SSSD subdomains provider does not resolve SRV records correctly when DNS name of the server is different from domain/rea... 2020-11-11 08:26:20 UTC

Description Dmitri Pal 2013-09-12 14:37:16 UTC 
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/sssd/ticket/2079

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 de307ab8e390deabc5df9884a3f762bfb1581936 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]
}}}
Comment 1 Jakub Hrozek 2013-09-26 09:15:22 UTC 
Patches are on review on the upstream list -> ASSIGNED
Comment 2 Jakub Hrozek 2013-09-26 20:32:11 UTC 
master: 82d248c7e7d61dba7065a1a744823bc06c1b5b96
sssd-1-11: 419cbf2efe34f4314bb92e506df3efc041cd5600
Comment 4 Jakub Hrozek 2013-10-04 13:24:27 UTC 
Temporarily moving bugs to MODIFIED to work around errata tool bug
Comment 6 Jakub Hrozek 2014-01-30 15:31:46 UTC 
In order to test, configure the dns_discovery_domain parameter on an IPA server. 

If the IPA server in sssd.conf is set to be autodiscovered (either with explicit _srv_ or by omitting the ipa_server parameter completely), then you should see a warning in both syslog and debug logs.

If autodiscovery is not used, you should see a different warning in debug logs (no syslog this time) telling you that the discovery domain is being ignored.
Comment 7 Scott Poore 2014-01-30 20:55:40 UTC 
Verified.

Version ::

sssd-1.11.2-27.el7.x86_64

Results ::

# test with ipa_server not set

#ipa_server = rhel7-4.example.com
dns_discovery_domain = testrelm.com

[root@rhel7-4 sssd]# service sssd restart
Redirecting to /bin/systemctl restart  sssd.service

[root@rhel7-4 sssd]# grep dns_discovery_domain /var/log/messages 
Jan 30 10:40:49 rhel7-4 sssd[be[testrelm.com]]: SRV discovery is enabled on the IPA server while using custom dns_discovery_domain. DNS discovery of trusted AD domain will likely fail. It is recommended not to use SRV discovery or the dns_discovery_domain option for the IPA domain while running on the server itself

[root@rhel7-4 sssd]# grep dns_discovery_domain /var/log/sssd/sssd_testrelm.com.log 
(Thu Jan 30 10:40:49 2014) [sssd[be[testrelm.com]]] [dp_get_options] (0x0400): Option dns_discovery_domain has value testrelm.com
(Thu Jan 30 10:40:49 2014) [sssd[be[testrelm.com]]] [sssm_ipa_id_init] (0x0020): SRV discovery is enabled on IPA server while using custom dns_discovery_domain. DNS discovery of trusted AD domain will likely fail. It is recommended not to use SRV discovery or the dns_discovery_domain option for the IPA domain while running on the server itself


### Test with ipa_server set to hostname

[root@rhel7-4 sssd]# vi /etc/sssd/sssd.conf

ipa_server = rhel7-4.example.com
dns_discovery_domain = testrelm.com

[root@rhel7-4 sssd]# > /var/log/messages 

[root@rhel7-4 sssd]# > /var/log/sssd/sssd_testrelm.com.log 

[root@rhel7-4 sssd]# service sssd restart
Redirecting to /bin/systemctl restart  sssd.service

[root@rhel7-4 sssd]# grep dns_discovery_domain /var/log/messages 

[root@rhel7-4 sssd]# grep dns_discovery_domain /var/log/sssd/sssd_testrelm.com.log 
(Thu Jan 30 10:50:38 2014) [sssd[be[testrelm.com]]] [dp_get_options] (0x0400): Option dns_discovery_domain has value testrelm.com
(Thu Jan 30 10:50:38 2014) [sssd[be[testrelm.com]]] [sssm_ipa_id_init] (0x0100): The value of dns_discovery_domain will be ignored in ipa_server_mode

### Testing ipa_server set to test AD

[root@rhel7-4 sssd]# service sssd stop
Redirecting to /bin/systemctl stop  sssd.service

[root@rhel7-4 sssd]# vi /etc/sssd/sssd.conf

[root@rhel7-4 sssd]# egrep "ipa_server |dns_discovery_domain " /etc/sssd/sssd.conf
#ipa_server = _srv_
ipa_server = rhel7-4.example.com
dns_discovery_domain = testrelm.com

[root@rhel7-4 sssd]# rm -rf /var/lib/sss/{db,mc}/*

[root@rhel7-4 sssd]# service sssd start
Redirecting to /bin/systemctl start  sssd.service

[root@rhel7-4 sssd]# id aduser1.test
uid=551801125(aduser1.test) gid=551801125(aduser1.test) groups=551801125(aduser1.test),551801746(adgroup2.test),551801131(adgroup1.test),551800513(domain users.test)
Comment 8 Ludek Smid 2014-06-13 12:21:57 UTC 
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.
Note You need to log in before you can comment on or make changes to this bug.