Description of problem: When using mod_authz_ldap, secure communication with the ldap server (ldaps) is not possible. Version-Release number of selected component (if applicable): mod_authz_ldap-0.26-2 How reproducible: Always Steps to Reproduce: 1. open authz_ldap.conf 2. set AuthzLDAPServer to point to an ldaps address 3. set AuthzLDAPBindDN and AuthzLDAPBindPassword 4. (re)start httpd Actual results: cannot bind to [6545] LDAP Server as <user>/<password> [crit] [client xx.xx.xx.xx] [6545] no ldap connection Expected results: bind to ldaps, authenticate user, verify apache credentials or x509 certificate. Additional info: This seems to be an upstream issue although I've found very little documentation on the issue. Since you can use mod_authz_ldap to authenticate using x509 certs in ldap, it would be a logical move to support secure communication with the ldap server.
This isn't really a bug -- mod_authz_ldap simply doesn't support using SSL/TLS to communicate with the LDAP server, but the standard mod_ldap.so and mod_auth_ldap.so already packaged in the base httpd package in RHEL4 does. In other words you don't need (and shouldn't try to use) mod_authz_ldap to accomplish SSL-enabled communication with the LDAP server because it can't do it. I've submitted this information to our kbase editors and it should be published shortly, but in the meantime, here's the text of that article while we wait for it to appear in the kbase: While the mod_authz_ldap Apache LDAP authentication module is available as an optional RPM that is capable of non-SSL-enabled LDAP authentication or certificate-based client authentication, mod_authz_ldap does not support use of SSL or TLS to encrypt its communications with LDAP servers. The standard mod_ldap.so and mod_auth_ldap.so LDAP and LDAP Authentication modules which are provided in the base httpd server daemon package in Red Hat Enterprise Linux versions 3 and 4 support using SSL to communicate with the LDAP server. Therefore it is not necessary to have the mod_authz_ldap RPM installed to achieve this configuration goal. The following are excerpts from an example Apache /etc/httpd/conf/httpd.conf configuration file which show the configuration statements needed to enable Apache to communicate with the LDAP server using SSL. The example below would cause the entire /var/www/html directory structure to be protected by requiring connecting clients to authenticate: First, make sure httpd.conf still contains the two lines which instruct httpd to load the needed LDAP modules: LoadModule ldap_module modules/mod_ldap.so LoadModule auth_ldap_module modules/mod_auth_ldap.so NOTE: The two lines above already exist in the default httpd.conf configuration file provided with the httpd package and should not need to be added unless they are missing. The following two Apache configuration file statements can only be defined once per server and therefore must be located in the main section of httpd.conf, not inside a Directory or VirtualHost container or .htaccess file: # Path to the Certificate Authority (CA) certificate used to sign the LDAP # server's certificate. The file must be readable by user httpd runs as # (normally user apache): LDAPTrustedCA /etc/openldap/cacerts/my-ca.crt # The format of the file defined above. BASE64_FILE should be correct # in most cases: LDAPTrustedCAType BASE64_FILE The following statements can be used in a Directory container as shown in the example below. Other possibilities exist, such as placing the same configuration statements in an .htaccess file to protect a particular directory underneath the DocumentRoot, or within a VirtualHost container to protect the entire virtual host. Note that in the case of using an .htaccess file to configure per-directory authentication, the configuration of the immediate parent container must include AuthConfig among the AllowOverride options. <Directory "/var/www/html"> Options Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all AuthLDAPAuthoritative on AuthLDAPEnabled on AuthType Basic AuthName "Restricted Area" # The following two lines are an example of providing a username # and password of a user with read access to the LDAP directory # in case the server is configured to not allow anonymous binds, # and may be necessary for some environments: #AuthLDAPBindDN "uid=ldapauthuser,ou=People,dc=example,dc=com" #AuthLDAPBindPassword "secretpassword" # The AuthLDAPUrl statement below defines the LDAP server to use as # myldapserver.example.com, sets the search base to start searching # for users at to ou=People,dc=example,dc=com, defines the attribute # to match the username provided by the user as uid, and defines a # subtree-type search to be used to locate the user's entry in the # LDAP directory: AuthLDAPUrl "ldaps://myldapserver.example.com:636/ou=People,dc=example,dc=com?uid?sub" # This tells HTTP to only allow access if they can authenticate: require valid-user </Directory> For further information on Apache configuration syntax, refer to the Apache documentation.
This is completely correct, however mod_auth_ldap does not support x509 key based authentication via ldap like mod_authz_ldap does. This is the key feature that I need with ldap based authentication. Using mod_ssl's fake_basic_auth, and x509 verification with mod_authz_ldap it is possible to authenticate using smartcard or other x509 key based system, and still pull rights and other information from ldap. This needs to be done in a secure manner though, which is why I was hoping to get ldaps support in mod_authz_ldap. working around the situation with stunnel adds a layer of complexity that could(should) be avoided. It's a hackish solution and a patch instead of an elegant fix.
This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?".