| 84 | | Some LDAP providers require some form of authentication in order to check credentials. There are two ways of handling this. One is to put a specific username and password into the Apache configuration file (as shown in the above example). This can be problematic in certain environments (the author of this section works in a US National Lab, with some occasionally insane security rules). And it is true that burying passwords in configuration files can be a maintenance problem. The third party mm_mod_auth_ldap (http://muquit.com/muquit/software/mod_auth_ldap/mod_auth_ldap.html) |
| | 84 | Some LDAP providers require some form of authentication in order to check credentials. There are two ways of handling this. One is to put a specific username and password into the Apache configuration file (as shown in the above example). This can be problematic in certain environments (the author of this section works in a US National Lab, with some occasionally insane security rules). And it is true that burying passwords in configuration files can be a maintenance problem. The third party mm_mod_auth_ldap (http://muquit.com/muquit/software/mod_auth_ldap/mod_auth_ldap.html) provides an interesting solution, which is that it attempts to use the username/password supplied by the user to do the bind to the LDAP provider. If the bind works that's part of the authentication. If the bind doesn't work, then the user is presumed to not be real, and the authentication fails. This does, however, have a couple of unfortunate side effects. One is that if the user fat-fingers the password, the bind fails and the user sees a server configuration error (bad). The other is that since the credentials are different on each bind, there's no caching or pooling of LDAP connections possible. However, this is a useful concept, and one that can hopefully be improved. The gist of the configuration is |
