#2434 Expose ldap filter for users as configuration item
Closed: wontfix 4 years ago by pbrezina. Opened 9 years ago by bnordgren.

Certain deployment scenarios may call for granting end users (system administrators) control over the ldap query used to locate users in an ldap backend. Scenarios mentioned on the discussion list include:

  1. Heavy use of fine-grained ACLs
  2. Use in an environment where a local ldap server proxies (and may locally override) user attributes from a remote identity store.

The current base filter is:

(&(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))

When searching for a uid given a uidNumber, the query becomes:

(&(uidNumber=$key)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0))))

Where the first term makes the last two terms moot. In addition, with certain configurations of an ldap proxy, the (uid=*) term can cause the proxy to request all user records from the proxied server.

Suggest exposing this filter to the local system administrator. Code will need to check the returned entry for the presence of required attributes and apply any necessary constraints to the attribute values.

Email threads

This has come up in the discussion list at least twice:

  1. https://lists.fedorahosted.org/pipermail/sssd-users/2014-May/001630.html
  2. https://lists.fedorahosted.org/pipermail/sssd-users/2014-September/002181.html

This might make sense in the context of #2038

milestone: NEEDS_TRIAGE => SSSD 1.13 beta

Fields changed

blocking: => 2038

Fields changed

mark: => 0

Fields changed

rhbz: => todo

Nice to have.

milestone: SSSD 1.13 beta => SSSD 1.13 backlog

Mass-moving tickets not planned for the 1.13 release to 1.14

milestone: SSSD 1.13 backlog => SSSD 1.14 beta

Fields changed

priority: major => minor
sensitive: => 0

This makes sense, but the 1.14 milestone is too big. I'm moving the ticket to 1.15, in the meantime, patches are welcome.

milestone: SSSD 1.14 beta => SSSD 1.15 beta

Metadata Update from @bnordgren:
- Issue marked as blocked by: #2038
- Issue set to the milestone: SSSD Future releases (no date set yet)

7 years ago

Metadata Update from @thalman:
- Custom field blocking reset (from 2038)
- Custom field design_review reset (from 0)
- Custom field mark reset (from 0)
- Custom field patch reset (from 0)
- Custom field review reset (from 0)
- Custom field sensitive reset (from 0)
- Custom field testsupdated reset (from 0)
- Issue close_status updated to: None
- Issue tagged with: Canditate to close

4 years ago

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

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

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.

Metadata