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 745513 - Unable to lookup users with suffix referral configured.
Summary: Unable to lookup users with suffix referral configured.
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: pre-dev-freeze
: ---
Assignee: SSSD Maintainers
QA Contact: Namita Soman
URL:
Whiteboard:
: 735090 (view as bug list)
Depends On:
Blocks: 756082
TreeView+ depends on / blocked
 
Reported: 2011-10-12 14:46 UTC by Kaushik Banerjee
Modified: 2020-05-04 10:24 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-01-18 20:50:06 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 1902 0 None closed [RFE] SSSD should chase referrals explicitly 2020-05-04 10:24:07 UTC

Description Kaushik Banerjee 2011-10-12 14:46:20 UTC 
Description of problem:
Unable to lookup users with suffix referral configured.

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

How reproducible:
Always

Steps to Reproduce:
1. Create suffix referral on Server 1 (http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Configuring_Directory_Databases-Using_Referrals.html#Using_Referrals-Creating_Suffix_Referrals):

Created via 389-console. The referral entry in dse.ldif is as follows:

dn: cn=ou\3Dtesting\2Cdc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config
objectClass: top
objectClass: extensibleObject
objectClass: nsMappingTree
nsslapd-state: Referral
cn: ou=testing,dc=example,dc=com
nsslapd-parent-suffix: dc=example,dc=com
creatorsName: uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot
modifiersName: uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoo
 t
createTimestamp: 20111012142308Z
modifyTimestamp: 20111012142346Z
nsslapd-referral: ldap://cobra.lab.eng.pnq.redhat.com:389


Diagramatically Server 1 (kungfupanda.lab.eng.pnq.redhat.com):
   dc=example,dc=com
          |
          |
ou=testing,dc=example,dc=com (referred to Server 2)


2. On Server 2:

Diagramatically Server 2 (cobra.lab.eng.pnq.redhat.com):
     dc=example,dc=com
		|
		|
   ou=testing,dc=example,dc=com
		|
		|
uid=user88,ou=testing,dc=example,dc=com

3. Verify if you are able to follow referral from Server 1:

# ldapsearch -v -h kungfupanda.lab.eng.pnq.redhat.com -D "cn=Directory Manager" -w Secret123 -b "dc=example,dc=com" -C uid=user88
ldap_initialize( ldap://kungfupanda.lab.eng.pnq.redhat.com )
filter: uid=user88
requesting: All userApplication attributes
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter: uid=user88
# requesting: ALL
#

# search reference
ref: ldap://cobra.lab.eng.pnq.redhat.com:389/ou=testing,dc=example,dc=com

# user88, testing, example.com
dn: uid=user88,ou=testing,dc=example,dc=com
uidNumber: 9876588
gidNumber: 9876588
objectClass: top
objectClass: posixAccount
objectClass: person
uid: user88
cn: user88
homeDirectory: /home/user88
sn: user88

# search result
search: 2
result: 0 Success

# numResponses: 3
# numEntries: 1
# numReferences: 1

4. Configure sssd with domain section as:

[domain/NewLDAP]
ldap_search_base = dc=example,dc=com
id_provider = ldap
debug_level = 9
ldap_uri = ldap://kungfupanda.lab.eng.pnq.redhat.com
ldap_tls_cacert = /etc/openldap/cacerts/cacert.asc
ldap_referrals = true
ldap_default_bind_dn = cn=Directory Manager
ldap_default_authtok = Secret123

5. Perform lookup of the user.

# getent -s sss passwd user88
# 
  
Actual results:
Lookup fails.

sssd_NewLDAP.log shows:

(Wed Oct 12 10:39:42 2011) [sssd[be[NewLDAP]]] [sbus_dispatch] (9): dbus conn: 1541970
(Wed Oct 12 10:39:42 2011) [sssd[be[NewLDAP]]] [sbus_dispatch] (9): Dispatching.
(Wed Oct 12 10:39:42 2011) [sssd[be[NewLDAP]]] [sbus_message_handler] (9): Received SBUS method [getAccountInfo]
(Wed Oct 12 10:39:42 2011) [sssd[be[NewLDAP]]] [be_get_account_info] (4): Got request for [4097][1][name=user88]
(Wed Oct 12 10:39:42 2011) [sssd[be[NewLDAP]]] [sdap_id_op_connect_step] (9): beginning to connect
(Wed Oct 12 10:39:42 2011) [sssd[be[NewLDAP]]] [fo_resolve_service_send] (4): Trying to resolve service 'LDAP'
(Wed Oct 12 10:39:42 2011) [sssd[be[NewLDAP]]] [get_server_status] (7): Status of server 'kungfupanda.lab.eng.pnq.redhat.com' is 'name not resolved'
(Wed Oct 12 10:39:42 2011) [sssd[be[NewLDAP]]] [get_port_status] (7): Port status of port 389 for server 'kungfupanda.lab.eng.pnq.redhat.com' is 'neutral'
(Wed Oct 12 10:39:42 2011) [sssd[be[NewLDAP]]] [get_server_status] (7): Status of server 'kungfupanda.lab.eng.pnq.redhat.com' is 'name not resolved'
(Wed Oct 12 10:39:42 2011) [sssd[be[NewLDAP]]] [resolv_is_address] (9): [kungfupanda.lab.eng.pnq.redhat.com] does not look like an IP address
(Wed Oct 12 10:39:42 2011) [sssd[be[NewLDAP]]] [resolv_gethostbyname_step] (8): Querying files
(Wed Oct 12 10:39:42 2011) [sssd[be[NewLDAP]]] [resolv_gethostbyname_files_send] (4): Trying to resolve A record of 'kungfupanda.lab.eng.pnq.redhat.com' in files
(Wed Oct 12 10:39:42 2011) [sssd[be[NewLDAP]]] [set_server_common_status] (4): Marking server 'kungfupanda.lab.eng.pnq.redhat.com' as 'resolving name'
(Wed Oct 12 10:39:42 2011) [sssd[be[NewLDAP]]] [resolv_gethostbyname_step] (8): Querying files
(Wed Oct 12 10:39:42 2011) [sssd[be[NewLDAP]]] [resolv_gethostbyname_files_send] (4): Trying to resolve AAAA record of 'kungfupanda.lab.eng.pnq.redhat.com' in files
(Wed Oct 12 10:39:42 2011) [sssd[be[NewLDAP]]] [resolv_gethostbyname_next] (5): No more address families to retry
(Wed Oct 12 10:39:42 2011) [sssd[be[NewLDAP]]] [resolv_gethostbyname_step] (8): Querying DNS
(Wed Oct 12 10:39:42 2011) [sssd[be[NewLDAP]]] [schedule_timeout_watcher] (9): Scheduling DNS timeout watcher
(Wed Oct 12 10:39:42 2011) [sssd[be[NewLDAP]]] [resolv_gethostbyname_dns_query] (4): Trying to resolve A record of 'kungfupanda.lab.eng.pnq.redhat.com' in DNS
(Wed Oct 12 10:39:42 2011) [sssd[be[NewLDAP]]] [unschedule_timeout_watcher] (9): Unscheduling DNS timeout watcher
(Wed Oct 12 10:39:42 2011) [sssd[be[NewLDAP]]] [resolv_gethostbyname_dns_parse] (7): Parsing an A reply
(Wed Oct 12 10:39:42 2011) [sssd[be[NewLDAP]]] [set_server_common_status] (4): Marking server 'kungfupanda.lab.eng.pnq.redhat.com' as 'name resolved'
(Wed Oct 12 10:39:42 2011) [sssd[be[NewLDAP]]] [be_resolve_server_done] (4): Found address for server kungfupanda.lab.eng.pnq.redhat.com: [10.65.201.78] TTL 12
(Wed Oct 12 10:39:42 2011) [sssd[be[NewLDAP]]] [sdap_uri_callback] (6): Constructed uri 'ldap://kungfupanda.lab.eng.pnq.redhat.com'
(Wed Oct 12 10:39:42 2011) [sssd[be[NewLDAP]]] [sss_ldap_init_send] (9): Using file descriptor [26] for LDAP connection.
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_ldap_connect_callback_add] (9): New LDAP connection to [ldap://kungfupanda.lab.eng.pnq.redhat.com:389/??base] with fd [26].
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_rootdse_send] (9): Getting rootdse
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (6): calling ldap_search_ext with [(objectclass=*)][].
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [*]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [altServer]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [namingContexts]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [supportedControl]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [supportedExtension]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [supportedFeatures]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [supportedLDAPVersion]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [supportedSASLMechanisms]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [defaultNamingContext]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [lastUSN]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [highestCommittedUSN]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (8): ldap_search_ext called, msgid = 1
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_process_result] (8): Trace: sh[0x1549ff0], connected[1], ops[0x1553980], ldap[0x154a520]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_parse_entry] (9): OriginalDN: [].
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_process_result] (8): Trace: sh[0x1549ff0], connected[1], ops[0x1553980], ldap[0x154a520]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_done] (6): Search result: Success(0), (null)
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_rootdse_done] (9): Got rootdse
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_server_opts_from_rootdse] (5): No known USN scheme is supported by this server!
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_server_opts_from_rootdse] (5): Will use modification timestamp as usn!
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [simple_bind_send] (4): Executing simple bind as: cn=Directory Manager
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [simple_bind_send] (8): ldap simple bind sent, msgid = 2
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_process_result] (8): Trace: sh[0x1549ff0], connected[1], ops[0x1555380], ldap[0x154a520]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_process_result] (8): Trace: ldap_result found nothing!
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_process_result] (8): Trace: sh[0x1549ff0], connected[1], ops[0x1555380], ldap[0x154a520]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [simple_bind_done] (5): Server returned no controls.
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [simple_bind_done] (3): Bind result: Success(0), (null)
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [fo_set_port_status] (4): Marking port 389 of server 'kungfupanda.lab.eng.pnq.redhat.com' as 'working'
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [set_server_common_status] (4): Marking server 'kungfupanda.lab.eng.pnq.redhat.com' as 'working'
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_id_op_connect_done] (9): notify connected to op #1
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (6): calling ldap_search_ext with [(&(uid=user88)(objectclass=posixAccount))][dc=example,dc=com].
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [objectClass]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [uid]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [userPassword]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [uidNumber]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [gidNumber]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [gecos]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [homeDirectory]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [loginShell]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [krbPrincipalName]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [cn]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [modifyTimestamp]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [shadowLastChange]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [shadowMin]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [shadowMax]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [shadowWarning]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [shadowInactive]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [shadowExpire]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [shadowFlag]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [krbLastPwdChange]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [krbPasswordExpiration]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [pwdAttribute]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [authorizedService]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [accountExpires]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [userAccountControl]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (7): Requesting attrs: [nsAccountLock]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_step] (8): ldap_search_ext called, msgid = 3
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_id_op_connect_done] (9): caching successful connection after 1 notifies
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_process_result] (8): Trace: sh[0x1549ff0], connected[1], ops[0x1556410], ldap[0x154a520]
(Wed Oct 12 10:39:43 2011) [sssd[be[NewLDAP]]] [sdap_process_result] (8): Trace: ldap_result found nothing!
(Wed Oct 12 10:39:44 2011) [sssd[be[NewLDAP]]] [sdap_process_result] (8): Trace: sh[0x1549ff0], connected[1], ops[0x1556410], ldap[0x154a520]
(Wed Oct 12 10:39:44 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_done] (6): Search result: Success(0), (null)
(Wed Oct 12 10:39:44 2011) [sssd[be[NewLDAP]]] [sdap_get_generic_done] (7): Total count [0]
(Wed Oct 12 10:39:44 2011) [sssd[be[NewLDAP]]] [sdap_get_users_process] (6): Search for users, returned 0 results.
(Wed Oct 12 10:39:44 2011) [sssd[be[NewLDAP]]] [sdap_id_op_done] (9): releasing operation connection
(Wed Oct 12 10:39:44 2011) [sssd[be[NewLDAP]]] [ldb] (9): tevent: Added timed event "ltdb_callback": 0x1553630

(Wed Oct 12 10:39:44 2011) [sssd[be[NewLDAP]]] [ldb] (9): tevent: Added timed event "ltdb_timeout": 0x1553750

(Wed Oct 12 10:39:44 2011) [sssd[be[NewLDAP]]] [ldb] (9): tevent: Destroying timer event 0x1553750 "ltdb_timeout"

(Wed Oct 12 10:39:44 2011) [sssd[be[NewLDAP]]] [ldb] (9): tevent: Ending timer event 0x1553630 "ltdb_callback"

(Wed Oct 12 10:39:44 2011) [sssd[be[NewLDAP]]] [sysdb_search_user_by_name] (6): Error: 2 (No such file or directory)
(Wed Oct 12 10:39:44 2011) [sssd[be[NewLDAP]]] [sysdb_delete_user] (6): Error: 2 (No such file or directory)
(Wed Oct 12 10:39:44 2011) [sssd[be[NewLDAP]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success
(Wed Oct 12 10:39:44 2011) [sssd[be[NewLDAP]]] [sdap_process_result] (8): Trace: sh[0x1549ff0], connected[1], ops[(nil)], ldap[0x154a520]
(Wed Oct 12 10:39:44 2011) [sssd[be[NewLDAP]]] [sdap_process_result] (8): Trace: ldap_result found nothing!


Expected results:
Lookup should return appropriate values.

Additional info:
Comment 2 Jakub Hrozek 2011-10-12 14:58:38 UTC 
We've been poking at this issue with Kaushik today. It should be noted that "smart referrals" that map one entry from a directory tree work fine.

Command-line ldapsearch is able to follow both smart and suffix referrals.
Comment 3 Stephen Gallagher 2011-10-13 11:29:39 UTC 
Upstream ticket:
https://fedorahosted.org/sssd/ticket/860
Comment 10 Jakub Hrozek 2013-03-18 09:00:20 UTC 
*** Bug 735090 has been marked as a duplicate of this bug. ***
Comment 12 Jakub Hrozek 2016-01-18 20:50:06 UTC 
Thank you taking your time and submitting this request for Red Hat Enterprise
Linux. Unfortunately, this bug was not given a priority and was deferred both
in the upstream project and in Red Hat Enterprise Linux.

Given that we are unable to fulfill this request in following Red Hat
Enterprise Linux releases, I am closing the Bugzilla as DEFERRED. To request
that Red Hat re-considers the decision, please re-open the Bugzilla via
appropriate support channels and provide additional business and/or technical
details about its importance to you.

Note that you can still track this request or even contribute patches in the
referred upstream Trac ticket.
Note You need to log in before you can comment on or make changes to this bug.