![]() |
Litespeed LDAP vs. mod_auth_ldap in Apache
Please confirm the following:
1) Apache supports "ldap" and "ldaps" whereas Litespeed only supports "ldap". 2) Apache uses the following authentication process: 1a> Bind to LDAP server with info configured in AuthLDAPBindDN/AuthLDAPBindPassword. 1b> Search for matching ldap record based on AuthLDAPURL and other attributes. 1c> Bind to LDAP again using the record found in 1b> and the password supplied by the user. Litespeed appears to do the following: 2a> Bind to LDAP server with info configured in LDAP Bind DN/LDAP Bind Password 2b> Search for matching ldap record based on User DB Location 2c> Compare the 'userPassword' attribute of the record fetched in 2b with the password the user entered. PROBLEMS: 1) We currently use "ldaps" to communicate with an ldap server that's on a different box from the webserver. 2) Per contract requirements, we need to 'lockout' a user login if invalid login attempts exceed a certain number. The apache process (1c) hits our ldap server with every login attempt - our ldap server will lock-out the account when a maximum number of bad logins are submitted. You're matching process (2c) won't be able to register bad login activity with our master ldap server. If I can't replicate the apache process for working with LDAP, is it possible to write a custom URL/authorization program with Litespeed where I can do the LDAP magic myself (i.e. using Perl libraries)? Thanks in advance, Ed |
You can write a FCGI authorizer using LDAP in perl.
|
Do you have a simple example of a perl script that acts as a FCGI authorizer? What values should I be looking at in $ENV? What do I have to configure to get a web-browser login dialog to display to the user?
Thanks in advance, Ed |
no sample here, please check the fastcgi web site, it is standard. Basically you need to define a FCGI authorizer external app in LSWS.
|
Please confirm the following:
1) If you have a context setup as follows: Realm: (empty) Authentication Name: (empty or non-empty) Authorizer: [VHost Level]: (program) ...then the following happens: 1a) The authorization program is invoked without any REMOTE_USER or REMOTE_PASSWORD fields. 1b) If the program returns a status other than '200', a blank page is displayed. This functions like FastCgiAuthorizer in apache's mod_fcgi. 2) If you setup a context as follows: Realm: (file-database realm) Authentication Name: (empty or non-empty) Authorizer: [VHost Level]: (program) ...then the following happens: 2a) An authentication dialog is displayed to the user until they enter credentials that match the database file. 2b) The authorization program is invoked. REMOTE_USER is set to the name of the authenticated user. The REMOTE_PASSWORD field is NOT sent. If the program returns a status other than '200', a blank page is displayed. This functions like FastCgiAuthorizer in apache's mod_fcgi. 3) There is no way to bring up a dialog and pass the contents to a fastcgi. Litespeed has no support for FastCgiAuthenticator in apache's mod_fcgi. CONCLUSION: If you want to AUTHENTICATE uses at the web-server level, your only options are Litespeed's password files or LDAP implementation. If you want to use a custom authentication procedure, you have to use Litespeed as a reverse proxy in front of apache, which supports this functionality. SUGGESTION: Create a new Realm type called 'FastCGI' (in addition to 'Password File' and 'LDAP'). When this is selected in a context, the webserver displays a login dialog and passes the REMOTE_USER and REMOTE_PASSWORD environment variables to the fastcgi. In this instance, the cgi works like a FastCgiAuthenticator in apache's mod_fastcgi. |
| All times are GMT -7. The time now is 11:43 AM. |