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
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.