Bug 56362 - ldaps only works with port 636. Non-standard port is ignored and default port used instead.
Summary: ldaps only works with port 636. Non-standard port is ignored and default port...
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_authnz_ldap (show other bugs)
Version: 2.2.15
Hardware: All Linux
: P2 major (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate
Depends on:
Blocks:
 
Reported: 2014-04-08 06:48 UTC by Gernot HASSENPFLUG
Modified: 2018-11-07 21:08 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gernot HASSENPFLUG 2014-04-08 06:48:47 UTC
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
Comment 1 William A. Rowe Jr. 2018-11-07 21:08:15 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.