https://issues.apache.org/bugzilla/show_bug.cgi?id=56362
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
Assignee: [email protected]
Reporter: [email protected]
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
tcpdump:
[LDAP: ldap_simple_bind_s() failed][Can't contact LDAP server]
Details below.
Background
----------
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.
CentOS5:
openssl: 0.9.8e-22.el5_8.4
openldap: 2.3.43-25.el5_8.1
httpd: 2.2.3-76.el5.centos
CentOS6:
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 "..."
AuthLDAPURL
"ldap://<serverIP1>:<port>,<serverIP2>:<port>/ou=...,dc=...,dc=...?sAMAccountName"
</AuthnProviderAlias>
However, similar configuration with SSL ignores the specified port and instead
defaults to port 636:
<AuthnProviderAlias ldap ldapservice1>
AuthLDAPBindDN "cn=...,ou=...,dc=...,dc=..."
AuthLDAPBindPassword "..."
AuthLDAPURL
"ldaps://<serverIP1>:<port>,<serverIP2>:<port>/ou=...,dc=...,dc=...?sAMAccountName"
</AuthnProviderAlias>
ldapsearch
----------
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
problems):
TLS_REQCERT never
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
AuthLDAPURL
ldaps://<server>:50001/ou=...,ou=...,dc=...,dc=...,dc=...?sAMAccountName?sub?(objectClass=person)
Require valid-user
</Directory>
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.
Regards,
Gernot Hassenpflug
--
ASAHI Net, Inc.
Tokyo, Japan
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
