httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [Bug 56362] New: ldaps only works with port 636. Non-standard port is ignored and default port used instead.
Date Tue, 08 Apr 2014 06:48:47 GMT

            Bug ID: 56362
           Summary: ldaps only works with port 636. Non-standard port is
                    ignored and default port used instead.
           Product: Apache httpd-2
           Version: 2.5-HEAD
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: major
          Priority: P2
         Component: mod_authnz_ldap

Hello all,
This is my first bug report here, so please be kind if I am missing some simple
information I should check first, apart from searches for similar bugs.

I am trying to figure out how to force mod_authnz_ldap to use a non-standard
port for an LDAPS connection using ldaps://<server>:<port>/....

At present we simply get an Internal Error (500) in the browser and the
following type of message in the logs, with no packets at all detected with
[LDAP: ldap_simple_bind_s() failed][Can't contact LDAP server]

Details below.


At our company, we use CentOS5 and CentOS6 for LDAP gateway servers. These
servers run httpd with mod_authnz_ldap set up to connect to customers' LDAP and
AD servers.

openssl: 0.9.8e-22.el5_8.4
openldap: 2.3.43-25.el5_8.1
httpd: 2.2.3-76.el5.centos

openssl: 1.0.1e-16.el6_5.4
openldap: 2.4.23-34.el6_5.1
httpd: 2.2.15-29.el6.centos

In the past, there had been problems with mutually-exclusive mod_ldap settings
needed to get either non-SSL (standard port 389 or non-standard ports) or SSL
(on standard port 636) to work with mod_authnz_ldap (either "LDAPTrustedMode
SSL" or "LDAPTrustedMode None" required), so we have two types of setup based
on that.

We have successfully used the non-SSL URI (LDAP) with non-standard ports, as in
this snippet for an AD server connection:

<AuthnProviderAlias ldap ldapservice1>
AuthLDAPBindDN "cn=...,ou=...,dc=...,dc=..."
AuthLDAPBindPassword "..."

However, similar configuration with SSL ignores the specified port and instead
defaults to port 636:

<AuthnProviderAlias ldap ldapservice1>
AuthLDAPBindDN "cn=...,ou=...,dc=...,dc=..."
AuthLDAPBindPassword "..."


ldapsearch works perfectly well using -H ldaps://<server>:<port>... for a
non-standard port for both LDAP and LDAPS, so the /etc/openldap/ldap.conf file
seems to be in order. The only change from default is the addition of the
following line to permit connection to AD server without certificate
verification (sidenote: we did use openssl to verify that the chain has no

Problem with non-standard port for ldaps URI

When using ldaps://<server>:<port> syntax, the module still insists on using
port 636.

For my mod_ldap settings I have made sure to turn off the extension
LDAPTrustedMode, since it defaults to port 636 if set to "SSL". I also have the
local CA authority certificate available (although usually it is simple to test
that the LDAP server queries works with "LDAPVerifyServerCert off")

Use of tcpdump shows no packets at all, but as soon as port is set to 636, or
left out entirely, then packets are shown and the connection works.

Here is the complete general configuration of mod_authnz_ldap:

LDAPSharedCacheSize 500000
LDAPCacheEntries 1024
LDAPCacheTTL 600
LDAPOpCacheEntries 1024
LDAPOpCacheTTL 600

LDAPTrustedGlobalCert CA_BASE64 /etc/ssl/certs/<ADserverCAcert>.pem
LDAPVerifyServerCert on
#LDAPTrustedMode SSL
#LDAPTrustedMode NONE

LDAPConnectionTimeout 1

Here the configuration of the directory to be protected:

<Directory "/var/www/protecteddir">
  # from mod_auth_basic:
  AuthType basic
  AuthName "privateauth user authentication"
  AuthBasicProvider ldap
  # from mod_authnz_ldap:
  AuthzLDAPAuthoritative off
  AuthLDAPBindDN "cn=...,ou=...,dc=...,dc=..."
  AuthLDAPBindPassword RoSYS302
  Require valid-user

Is this a configuration bug (LDAP settings forcing a default somewhere?), a
misconfiguration of mod_authnz_ldap, or a bug?

Any hints or advice much appreciated.
Gernot Hassenpflug
ASAHI Net, Inc.
Tokyo, Japan

You are receiving this mail because:
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message