Bug 694444 - Unable to resolve SRV record when called with _srv_,<fixed ldap uri> in ldap_uri
Unable to resolve SRV record when called with _srv_,<fixed ldap uri> in ldap_uri
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd (Show other bugs)
6.1
Unspecified Linux
unspecified Severity unspecified
: rc
: ---
Assigned To: Stephen Gallagher
Chandrasekar Kannan
:
Depends On:
Blocks: 695476
  Show dependency treegraph
 
Reported: 2011-04-07 07:29 EDT by Kaushik Banerjee
Modified: 2015-01-04 18:47 EST (History)
8 users (show)

See Also:
Fixed In Version: sssd-1.5.1-26.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 695476 (view as bug list)
Environment:
Last Closed: 2011-05-19 07:39:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Kaushik Banerjee 2011-04-07 07:29:28 EDT
Description of problem:
Unable to resolve SRV record when called with _srv_,<fixed ldap uri> in ldap_uri

Version-Release number of selected component (if applicable):
sssd-1.5.1-24.el6.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Create an approrpiate SRV record entry in DNS Server for domain sssdad.com "_ldap._tcp IN SRV 0 0 389 pluto".
2. Verify that lookup happens with the command "dig SRV _ldap._tcp.sssdad.com"
3. Configure sssd to use both SRV and fixed ldap_uri. Use dns_discovery_domain for appropriate domain name for the SRV query. See additional info for relevant sssd.conf.
  
Actual results:
sssd fails to resolve the SRV record. 

/var/log/sssd/sssd_AD.log
<snip>
(Thu Apr  7 16:51:31 2011) [sssd[be[AD]]] [fo_resolve_service_send] (4): Trying to resolve service 'LDAP'
(Thu Apr  7 16:51:31 2011) [sssd[be[AD]]] [get_port_status] (7): Port status of port 0 for server '(no name)' is 'neutral'
(Thu Apr  7 16:51:31 2011) [sssd[be[AD]]] [resolve_srv_send] (6): The status of SRV lookup is neutral
(Thu Apr  7 16:51:31 2011) [sssd[be[AD]]] [resolve_srv_cont] (4): Searching for servers via SRV query '_ldap._tcp.sssdad.com'
(Thu Apr  7 16:51:31 2011) [sssd[be[AD]]] [resolv_getsrv_send] (4): Trying to resolve SRV record of '_ldap._tcp.sssdad.com'
(Thu Apr  7 16:51:31 2011) [sssd[be[AD]]] [schedule_timeout_watcher] (9): Scheduling DNS timeout watcher
(Thu Apr  7 16:51:31 2011) [sssd[be[AD]]] [unschedule_timeout_watcher] (9): Unscheduling DNS timeout watcher
(Thu Apr  7 16:51:31 2011) [sssd[be[AD]]] [set_srv_data_status] (4): Marking SRV lookup of service 'LDAP' as 'not resolved'
(Thu Apr  7 16:51:31 2011) [sssd[be[AD]]] [be_resolve_server_done] (6): Couldn't resolve server (SRV lookup meta-server), resolver returned (5)
(Thu Apr  7 16:51:31 2011) [sssd[be[AD]]] [be_resolve_server_done] (6): Trying with the next one!
(Thu Apr  7 16:51:31 2011) [sssd[be[AD]]] [fo_resolve_service_send] (4): Trying to resolve service 'LDAP'
</snip>

Expected results:
sssd should resolve the SRV record.

Additional info:
# cat /etc/sssd/sssd.conf
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = AD
debug_level = 9

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
debug_level = 9

[pam]
reconnection_retries = 3
debug_level = 9

[domain/AD]
description = LDAP domain with AD server
debug_level = 9
enumerate = false
cache_credentials = False
id_provider = ldap
ldap_id_use_start_tls = true
auth_provider = ldap
ldap_uri = _srv_,ldap://pluto.sssdad.com
dns_discovery_domain = sssdad.com
ldap_schema = rfc2307bis
ldap_default_bind_dn = cn=Administrator,cn=Users,dc=sssdad,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = redhat_123
ldap_search_base = dc=sssdad,dc=com
ldap_user_object_class = person
ldap_user_name = uid
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_user_home_directory = unixHomeDirectory
ldap_user_shell = loginShell
ldap_user_principal = userPrincipalName
ldap_group_object_class = group
ldap_group_name = cn
ldap_force_upper_case_realm = True
Comment 3 RHEL Product and Program Management 2011-04-07 07:43:52 EDT
Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.
Comment 4 Jakub Hrozek 2011-04-07 08:04:21 EDT
Upstream bug:
https://fedorahosted.org/sssd/ticket/839
Comment 8 Kaushik Banerjee 2011-04-12 10:51:05 EDT
Verified that SRV record is appropriately resolved when called with _srv_,<fixed ldap uri> in ldap_uri.

output from /var/log/sssd/sssd_AD.log:
<snip>
(Tue Apr 12 20:13:33 2011) [sssd[be[AD]]] [fo_resolve_service_send] (4): Trying to resolve service 'LDAP'
(Tue Apr 12 20:13:33 2011) [sssd[be[AD]]] [get_port_status] (7): Port status of port 0 for server '(no name)' is 'neutral'
(Tue Apr 12 20:13:33 2011) [sssd[be[AD]]] [resolve_srv_send] (6): The status of SRV lookup is neutral
(Tue Apr 12 20:13:33 2011) [sssd[be[AD]]] [resolve_srv_cont] (4): Searching for servers via SRV query '_ldap._tcp.sssdad.com'
(Tue Apr 12 20:13:33 2011) [sssd[be[AD]]] [resolv_getsrv_send] (4): Trying to resolve SRV record of '_ldap._tcp.sssdad.com'
(Tue Apr 12 20:13:33 2011) [sssd[be[AD]]] [schedule_timeout_watcher] (9): Scheduling DNS timeout watcher
(Tue Apr 12 20:13:33 2011) [sssd[be[AD]]] [unschedule_timeout_watcher] (9): Unscheduling DNS timeout watcher
(Tue Apr 12 20:13:33 2011) [sssd[be[AD]]] [resolve_srv_done] (6): Inserted server 'pluto.sssdad.com:389' for service LDAP
(Tue Apr 12 20:13:33 2011) [sssd[be[AD]]] [set_srv_data_status] (4): Marking SRV lookup of service 'LDAP' as 'resolved'
(Tue Apr 12 20:13:33 2011) [sssd[be[AD]]] [get_server_status] (7): Status of server 'pluto.sssdad.com' is 'name not resolved'
(Tue Apr 12 20:13:33 2011) [sssd[be[AD]]] [get_server_status] (4): Hostname resolution expired, reseting the server status of 'pluto.sssdad.com'
(Tue Apr 12 20:13:33 2011) [sssd[be[AD]]] [set_server_common_status] (4): Marking server 'pluto.sssdad.com' as 'name not resolved'
(Tue Apr 12 20:13:33 2011) [sssd[be[AD]]] [resolv_gethostbyname_send] (4): Trying to resolve A record of 'pluto.sssdad.com'
(Tue Apr 12 20:13:33 2011) [sssd[be[AD]]] [schedule_timeout_watcher] (9): Scheduling DNS timeout watcher
(Tue Apr 12 20:13:33 2011) [sssd[be[AD]]] [set_server_common_status] (4): Marking server 'pluto.sssdad.com' as 'resolving name'
(Tue Apr 12 20:13:33 2011) [sssd[be[AD]]] [unschedule_timeout_watcher] (9): Unscheduling DNS timeout watcher
(Tue Apr 12 20:13:33 2011) [sssd[be[AD]]] [set_server_common_status] (4): Marking server 'pluto.sssdad.com' as 'name resolved'
</snip>

Verified in version:
# rpm -qi sssd | head
Name        : sssd                         Relocations: (not relocatable)
Version     : 1.5.1                             Vendor: Red Hat, Inc.
Release     : 27.el6                        Build Date: Tue 12 Apr 2011 07:10:31 PM IST
Install Date: Tue 12 Apr 2011 07:43:30 PM IST      Build Host: hs20-bc2-3.build.redhat.com
Group       : Applications/System           Source RPM: sssd-1.5.1-27.el6.src.rpm
Size        : 3462773                          License: GPLv3+
Signature   : (none)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://fedorahosted.org/sssd/
Summary     : System Security Services Daemon
Comment 9 errata-xmlrpc 2011-05-19 07:39:22 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0560.html
Comment 10 errata-xmlrpc 2011-05-19 09:03:58 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0560.html

Note You need to log in before you can comment on or make changes to this bug.