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 1897566 - [RFE] support ldapi URLs
Summary: [RFE] support ldapi URLs
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: sssd
Version: 8.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.0
Assignee: SSSD Maintainers
QA Contact: sssd-qe
URL:
Whiteboard: sync-to-jira
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-11-13 13:09 UTC by Graham Leggett
Modified: 2021-08-30 20:32 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-08-30 17:52:36 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Graham Leggett 2020-11-13 13:09:42 UTC 
Description of problem:

sssd-ldap cannot connect to an LDAPI unix domain socket. Password-less access to LDAP is not available.

Version-Release number of selected component (if applicable):

sssd-ldap-2.2.3-20.el8.x86_64

How reproducible:

Always

Steps to Reproduce:
1. Configure sssd.conf as follows:

ldap_uri =  ldapi://%2fvar%2frun%2fslapd-gatekeeper.socket
ldap_sasl_mech = EXTERNAL

2.
3.

Actual results:

(Fri Nov 13 14:29:09 2020) [sssd[be[ldap]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve AAAA record of '/var/run/slapd-gatekeeper.socket' in DNS
(Fri Nov 13 14:29:09 2020) [sssd[be[ldap]]] [fo_resolve_service_done] (0x0020): Failed to resolve server '/var/run/slapd-gatekeeper.socket': Domain name not found
(Fri Nov 13 14:29:09 2020) [sssd[be[ldap]]] [set_server_common_status] (0x0100): Marking server '/var/run/slapd-gatekeeper.socket' as 'not working'
(Fri Nov 13 14:29:09 2020) [sssd[be[ldap]]] [be_resolve_server_process] (0x0080): Couldn't resolve server (/var/run/slapd-gatekeeper.socket), resolver returned [11]: Resource temporarily unavailable

Expected results:

Connection succeeded.

Additional info:
Comment 1 Sumit Bose 2020-11-13 15:33:01 UTC 
Hi,

this is currently expected since SSSD only supports ldap and ldaps URIs. The sssd-ldap man page says

           The format of the URI must match the format defined in RFC 2732:

           ldap[s]://<host>[:port]

I agree this is not very explicit about what is support and what not.

It would be possible to add ldapi support but since this is a new feature it might take some time.

bye,
Sumit
Comment 2 Alexey Tikhonov 2020-11-19 14:23:04 UTC 
In general, this is a valid RFE.

It might have some sense to implement. For example for the case of SSSD running on IPA server.

But at the moment this is not planned and we do not have ETA.
Comment 3 Alexander Bokovoy 2020-11-19 19:03:21 UTC 
I don't think we need this on IPA masters, sorry. 
This will only complicate things as SSSD is running as root and we have autobinding enabled and root mapped to cn=Directory Manager.
Comment 5 Graham Leggett 2020-11-20 08:45:08 UTC 
> I don't think we need this on IPA masters, sorry. 

To be clear, this need has nothing specifically to do with IPA.

The requirement is to get access to the file security model of unix domain sockets.
Comment 6 Alexander Bokovoy 2020-11-20 08:56:43 UTC 
As it stands, this RFE has no sufficient explanation of the use case.

'Passwordless' access over UNIX domain socket is a broad request. It needs cooperation between the LDAP client and LDAP server (configuration-wise, at least).
You are claiming it is not related to IPA -- what is the environment you are planning to use this feature in? How that can be configured and tested?

If you really need this RFE, please write up a general description of the use case and the flows you expect to have.
Comment 8 Tomas Halman 2021-03-18 13:23:05 UTC 
We evaluated this RFE and we think that it brings only little value.
Also as mentioned before use-case is not very well defined.

Considering this and our capacity we decided not to work on it.

If you disagree with the decision please reopen this BZ with more details.
However this does not guarantee that the request will not be closed during the triage
as we are currently applying much more rigor to what we actually can
accomplish in the foreseeable future.

Contributions and collaboration in the upstream community and CentOS Stream
is always welcome!

Thank you for understanding
Red Hat Enterprise Linux Identity Management Team
Comment 9 Graham Leggett 2021-03-26 12:11:07 UTC 
To clarify.

Security hardening is the practise of removing elements of a system that are open to abuse, the idea being you cannot attack what physically doesn't exist.

Unix domain sockets are a way to communicate internally on the same machine, using the same internal users and groups to secure the connection that secure both the filesystem, and the process itself. Crucially, that allows one process to communicate with another process without using passwords or other credentials.

LDAP in general, and 389ds specifically, has supported ldap-over-unix-domain-socket (ldapi scheme) for decades now. Systems like postfix, dovecot, and various milters all support unix domain sockets.

What this means is that it is very easy to deploy a single hardened "unit" of services, all running on the same machine, all communicating with each other without using passwords at all.

Except sssd.

Sssd running on a given machine needs a password to connect to an LDAP server running on the same machine. This means a) a TCP socket is exposed, which is open to be abused, and b) passwords need to be instantiated, which is open to be abused.

You cannot gain access to a unix domain socket outside a machine, you cannot steal or exploit a password that physically does not exist.

Having looked in the sssd code, what I saw was an assumption being made that all connections start with a DNS lookup. Fixing this should be simple - if the scheme is ldapi, the path points at a filesystem path and not DNS.
Comment 11 Alexey Tikhonov 2021-08-26 11:41:59 UTC 
(In reply to Graham Leggett from comment #9)
> 
> LDAP in general, and 389ds specifically, has supported
> ldap-over-unix-domain-socket (ldapi scheme) for decades now. Systems like
> postfix, dovecot, and various milters all support unix domain sockets.
> 
> What this means is that it is very easy to deploy a single hardened "unit"
> of services, all running on the same machine, all communicating with each
> other without using passwords at all.
> 
> Except sssd.
> 
> Sssd running on a given machine needs a password to connect to an LDAP
> server running on the same machine. This means a) a TCP socket is exposed,
> which is open to be abused, and b) passwords need to be instantiated, which
> is open to be abused.

What is the use case of local-only (isolated from a network) LDAP server?
If you only want to use those identities locally, why do you need LDAP server at all (instead of plain /etc/passwd, for example)?
Comment 12 Graham Leggett 2021-08-26 19:24:08 UTC 
> What is the use case of local-only (isolated from a network) LDAP server?
> If you only want to use those identities locally, why do you need LDAP server at all (instead of plain /etc/passwd, for example)?

Turning the question on it's head, when you have an IMAP daemon, a POP daemon, an SMTP daemon, a webserver exposing various services like calendars etc, and an SSH daemon, why would you try and configure these against multiple backends (/etc/passwd, ldap, etc) when you can just integrate one service (ldap) and be done with it?

LDAP gives you the option to import/export data in an interoperable format, the option to become network accessible if you so choose, all in one system, why would you make your life difficult by turning one system into N systems?

sssd-ldap is the outlier at this stage, there seems to be no good reason I could find in the code for why ldapi was excluded.
Comment 13 Alexey Tikhonov 2021-08-26 19:58:51 UTC 
It looks like opening discussion (or even better opening a PR) upstream is a best way to address this.
Comment 15 Alexey Tikhonov 2021-08-30 17:52:36 UTC 
This was re-evaluated within the team again and we are sorry but it can't make into our backlog.
Patches are welcome upstream.
Note You need to log in before you can comment on or make changes to this bug.