#2361 sssd creates bad ldap filter if ldap_id_mapping is set true
Closed: Invalid None Opened 7 years ago by jhrozek.

Ticket was cloned from Red Hat Bugzilla (product Fedora): Bug 1105561

Description of problem:

Setting ldap_id_mapping true in the sssd.conf sssd generates a bad ldap-filter:

(Thu Jun  5 11:13:33 2014) [sssd[be[ldap]]] [sdap_get_generic_ext_step]
(0x0400): calling ldap_search_ext with [(&(sAMAccountName=test)(objectclass=use

With the version of 1.11.3. it worked fine:
(Thu Jun  5 11:10:25 2014) [sssd[be[ldap]]] [sdap_get_generic_ext_step]
(0x0400): calling ldap_search_ext with [(&(sAMAccountName=test)(objectclass=use

The same configuration with ldap_id_mapping= false works fine.
Version-Release number of selected component (if applicable): sssd

How reproducible:

Set ldap_id_mapping true in sssd.conf when id provider is ldap.

Steps to Reproduce:

Actual results:
sssd can not find the ldap user.

Expected results:
sssd must find the user.

Additional info:

We should only improve documentation and list that you need to use either id_provider=ad or ldap_schema=ad, currently the docs are a bit ambiguous and maybe add a warning if ID mapping is on, but the SID attributes are not defined.

At the very least, using "NULL" in the filter is ugly and with some libc implementations might be dangerous. But the ticket is much lower priority now.

blockedby: =>
blocking: =>
changelog: =>
coverity: =>
design: =>
design_review: => 0
feature_milestone: =>
fedora_test_page: =>
priority: major => minor
review: True => 0
selected: =>
testsupdated: => 0

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.12.1

Fields changed

owner: somebody => mzidek

Mass-moving all tickets that didn't make 1.12.1 into 1.12.2

milestone: SSSD 1.12.1 => SSSD 1.12.2

We need to do a release as requested by downstream. Moving tickets that are not fixed already or very close to acking to 1.12.3

milestone: SSSD 1.12.2 => SSSD 1.12.3

Fields changed

mark: => 0
patch: 0 => 1

resolution: => fixed
status: new => closed

Replying to [comment:7 jhrozek]:

This patch caused critical regression with OpenLDAP server and thus
it was reverted in upstream (master and 1-11).

resolution: fixed =>
status: closed => reopened

Fields changed

resolution: => invalid
status: reopened => closed

Metadata Update from @jhrozek:
- Issue assigned to mzidek
- Issue set to the milestone: SSSD 1.12.3

4 years ago

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/3403

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.