#609 SSSD LDAP provider should support ldapi:// for optimized lookups on a local LDAP server
Closed: wontfix by pbrezina. Opened by jhrozek.

This issue was originaly reported in Red Hat Bugzilla

Currently the LDAP provider treats all URIs as network-resolvable. That is not true for ldapi:// as the path points to a UNIX socket.

We might create a very thin layer atop be_resolve_server_* in the ldap provider that would just return and call the specified callback when ldapi:// is found and descend to regular resolving otherwise. This may be a little over engineering as someone who uses ldapi:// is extremely unlikely to have another (remote) server configured, but should cover all cases, even with failover.


This ticket has a few other considerations that we need to make.

For example, should we waive the encryption requirement for authentication if we're talking only to a local socket? If so, we also need to coordinate with authconfig to adjust the UI to understand that.

component: SSSD => LDAP Provider
doc: 0 => 1
tests: 0 => 1

Similar issue has been recently discussed for nss_ldap. OpenLDAP using ldapi:// doesn't support TLS encryption using STARTTLS function and upstream decided that it will remain this way (NSS used in new versions of OpenLDAP doesn't even support local sockets). They suggested using starttls URL extension in RHEL5, but I guess that's not an option for new OpenLDAP either.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.6.0
summary: SSSD LDAP provider should support ldapi:// => SSSD LDAP provider should support ldapi:// for optimized lookups on a local LDAP server
type: defect => enhancement

Fields changed

coverity: =>
milestone: SSSD 1.6.0 => SSSD 1.7.0
upgrade: => 0

Fields changed

milestone: SSSD 1.8.0 => SSSD 1.9.0
patch: => 0

Fields changed

rhbz: => [https://bugzilla.redhat.com/show_bug.cgi?id=627763 627763]

Fields changed

blockedby: =>
blocking: =>
milestone: SSSD 1.9.0 => SSSD Deferred

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD Patches welcome

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)

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

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.

Metadata