Bug 44302 - AuthLDAPURL does not accept ldapi:// urls
Summary: AuthLDAPURL does not accept ldapi:// urls
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_authz_ldap (show other bugs)
Version: 2.2.22
Hardware: Other All
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: MassUpdate
Depends on:
Reported: 2008-01-27 07:31 UTC by Nikos
Modified: 2018-11-07 21:09 UTC (History)
2 users (show)

httpd patch to implement ldapi and ldap_initialize api (3.96 KB, patch)
2013-05-05 17:52 UTC, Simone Caruso
Details | Diff
Changes to apr-util 1.5.x branch (3.79 KB, patch)
2013-05-05 17:53 UTC, Simone Caruso
Details | Diff
Changes to apr-util 1.5.x branch (3.79 KB, patch)
2013-05-05 22:37 UTC, Simone Caruso
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nikos 2008-01-27 07:31:46 UTC
When using an ldapi:// (local socket) url apache issues the error [LDAP:
ldap_simple_bind_s() failed][Can't contact LDAP server]. I'm not familiar with
libldap API, but it seems ldap_simple_bind_s cannot accept a filename as hostname.

PS. The output of the URL parsing is (and it doesn't work even if %2f were
replaced with '/'):
[Sun Jan 27 17:17:18 2008] [debug] mod_authnz_ldap.c(870): [28272] auth_ldap url
parse: `ldapi://%2fvar%2frun%2fldapi/ou=Users,dc=lan'
[Sun Jan 27 17:17:18 2008] [debug] mod_authnz_ldap.c(879): [28272] auth_ldap url
parse: Host: /var/run/ldapi
[Sun Jan 27 17:17:18 2008] [debug] mod_authnz_ldap.c(881): [28272] auth_ldap url
parse: Port: 389
[Sun Jan 27 17:17:18 2008] [debug] mod_authnz_ldap.c(883): [28272] auth_ldap url
parse: DN: ou=Users,dc=lan
[Sun Jan 27 17:17:18 2008] [debug] mod_authnz_ldap.c(885): [28272] auth_ldap url
parse: attrib: (null)
[Sun Jan 27 17:17:18 2008] [debug] mod_authnz_ldap.c(887): [28272] auth_ldap url
parse: scope: base
[Sun Jan 27 17:17:18 2008] [debug] mod_authnz_ldap.c(892): [28272] auth_ldap url
parse: filter: (null)
[Sun Jan 27 17:17:18 2008] [debug] mod_authnz_ldap.c(972): LDAP: auth_ldap not
using SSL connections
Comment 1 Mark A. Ziesemer 2010-12-28 16:15:00 UTC
I'm not sure that this is still an issue.  Using Apache HTTPD 2.2.16 under Ubuntu 10.10, ldapi:/// URLs are working for me.  However, even if this is also working for everyone else, the documentation should be updated to reflect this before this bug is closed, as I can't find any references to this either way in the documentation.

Otherwise, per some of the comments in bug 48505, it seems that maybe the various LDAP URL support is provided by the OS rather than Apache, which could explain why this is working for me but not the original reporter, while we're both using an Apache 2.2 release.  (If it is a function of the OS rather than Apache, please document this as well.)
Comment 2 Stephane Chazelas 2013-02-12 19:11:33 UTC
Confirmed with apache 2.22 and apr-util 1.3.12 (from ubuntu 12.04). ldapi:// URLs don't work. Worse, if you enter ldapi:///, it is (silently) treated as ldap://localhost:389, that is, the connection is still done over TCP to localhost.

You can't use "EXTERNAL" type authentication (whereby the ldap server can verify the user name that contacts it from the unix domain socket).

To verify, enter a ldapi://%2fvar%2frun%2fslapd%2dldapi/... URL and see the wrong debug output as in Nikos' case, or enter ldapi:/// and see (with a network capture or looking at netstat) that it's doing a TCP connection to port 389. You could also disable TCP in slapd to verify that it stops working.
Comment 3 Stephane Chazelas 2013-02-12 20:59:47 UTC
I've checked the code of various versions of apache and apr-util including the latest ones (2.4.3 / 1.5.1).

While the newer apr-util has a new apr_ldap_is_ldapi_url function, it is not used by mod_authnz_ldap.

apr_ldap_url_parse_ext, which is called by mod_auth_ldap_parse_url, does extract the URL scheme (and explicitely cares for ldapi, though parses the socket path as a host:port and stores it in a field called lud_host), however mod_authnz_ldap doesn't make use of it. It just compares the start of the URL by itself with "ldaps" and assumes "ldap" if it doesn't match which explains why ldapi:// URLs are treated as ldap://localhost ones (default host is "localhost" for "ldap").
Comment 4 Simone Caruso 2013-05-05 17:52:13 UTC
Created attachment 30254 [details]
httpd patch to implement ldapi and ldap_initialize api

I had to implement ldapi in my installation, i see ldap_initialize is not supported in apr-util.
Comment 5 Simone Caruso 2013-05-05 17:53:06 UTC
Created attachment 30255 [details]
Changes to apr-util 1.5.x branch

Changes i made to apr-util 1.5.x branch
Comment 6 Simone Caruso 2013-05-05 22:37:30 UTC
Created attachment 30256 [details]
Changes to apr-util 1.5.x branch
Comment 7 Christophe JAILLET 2013-12-23 13:16:40 UTC
Comment on attachment 30254 [details]
httpd patch to implement ldapi and ldap_initialize api

>diff --git a/include/util_ldap.h b/include/util_ldap.h
>index 3d5faed..ede304f 100644
>--- a/include/util_ldap.h
>+++ b/include/util_ldap.h
>@@ -106,7 +106,7 @@ typedef struct util_ldap_connection_t {
>     apr_thread_mutex_t *lock;           /* Lock to indicate this connection is in use */
> #endif
>+    const char *url;
>     const char *host;                   /* Name of the LDAP server (or space separated list) */
>     int port;                           /* Port of the LDAP server */
>     deref_options deref;                /* how to handle alias dereferening */
>@@ -237,7 +237,7 @@ APR_DECLARE_OPTIONAL_FN(apr_status_t,uldap_connection_unbind,(void *param));
>  *                                                           const char *binddn, const char *bindpw, deref_options deref,
>  *                                                           int netscapessl, int starttls)
>  */
>-APR_DECLARE_OPTIONAL_FN(util_ldap_connection_t *,uldap_connection_find,(request_rec *r, const char *host, int port,
>+APR_DECLARE_OPTIONAL_FN(util_ldap_connection_t *,uldap_connection_find,(request_rec *r, const char *url, const char *host, int port,
>                                                   const char *binddn, const char *bindpw, deref_options deref,
>                                                   int secure));
>diff --git a/modules/aaa/mod_authnz_ldap.c b/modules/aaa/mod_authnz_ldap.c
>index b7b132e..fc35993 100644
>--- a/modules/aaa/mod_authnz_ldap.c
>+++ b/modules/aaa/mod_authnz_ldap.c
>@@ -434,7 +434,7 @@ static util_ldap_connection_t *get_connection_for_authz(request_rec *r, enum aut
>             bindpw = req->password;
>     }
>-    return util_ldap_connection_find(r, sec->host, sec->port,
>+    return util_ldap_connection_find(r, (const char *)sec->url, sec->host, sec->port,
>                                      binddn, bindpw,
>                                      sec->deref, sec->secure);
> }
>@@ -487,7 +487,7 @@ static authn_status authn_ldap_check_password(request_rec *r, const char *user,
>             binddn = ldap_determine_binddn(r, user);
>         }
>-        ldc = util_ldap_connection_find(r, sec->host, sec->port,
>+        ldc = util_ldap_connection_find(r, (const char *)sec->url, sec->host, sec->port,
>                                        binddn, bindpw,
>                                        sec->deref, sec->secure);
>     }
>@@ -1406,6 +1406,8 @@ static const char *mod_auth_ldap_parse_url(cmd_parms *cmd,
>         sec->port = urld->lud_port? urld->lud_port : LDAP_PORT;
>     }
>+    sec->url = apr_pstrndup(cmd->pool, sec->url, strrchr((char *)url, '/') - url);
>     sec->have_ldap_url = 1;
>     ap_log_error(APLOG_MARK, APLOG_TRACE1, 0, cmd->server,
>diff --git a/modules/ldap/util_ldap.c b/modules/ldap/util_ldap.c
>index dc08dd4..f0f099f 100644
>--- a/modules/ldap/util_ldap.c
>+++ b/modules/ldap/util_ldap.c
>@@ -291,7 +291,8 @@ static int uldap_connection_init(request_rec *r,
>      * some hosts with ports and some without. All hosts which do not
>      * specify a port will use the default port.
>      */
>-    apr_ldap_init(r->pool, &(ldc->ldap),
>+    apr_ldap_init(r->pool, &(ldc->ldap), ldc->url,
>                   ldc->host,
>                   APR_LDAP_SSL == ldc->secure ? LDAPS_PORT : LDAP_PORT,
>                   secure, &(result));
>@@ -686,7 +687,7 @@ static int compare_client_certs(apr_array_header_t *srcs,
>  * a pointer to the existing ldc structure will be returned.
>  */
> static util_ldap_connection_t *
>-            uldap_connection_find(request_rec *r,
>+            uldap_connection_find(request_rec *r, const char *url,
>                                   const char *host, int port,
>                                   const char *binddn, const char *bindpw,
>                                   deref_options deref, int secure)
>@@ -828,6 +829,7 @@ static util_ldap_connection_t *
>         apr_thread_mutex_lock(l->lock);
> #endif
>         l->bound = 0;
>+        l->url = url;
>         l->host = apr_pstrdup(l->pool, host);
>         l->port = port;
>         l->deref = deref;
Comment 8 William A. Rowe Jr. 2018-11-07 21:09:52 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.