Webauth LDAP

This actually isn't one of the features of this module. I'm not sure how you have Drupal configured to retrieve LDAP information on a normal login, but all this module does is trust Apache authentication, and do automatic login and user creation when it exists. It doesn't automatically identify LDAP authentication or do any further processing.

However, I have had success retrieving LDAP data for users created by webserver_auth... see http://drupal.org/node/206223#comment-911611

Please mark this 'fixed' if that sort of solution solves your problem.

Erik,

I get the exact same errors as you've noted above. As you say, the user does login and everything works. I finally settled on suppressing the error reporting to the screen instead of logging to both screen and logfile. Not ideal, but these are warnings and at least the user doesn't see them now. I would be interested in the correct solution to this as well.

Regards.

@#2: Please see this #165642: error in SQL syntax in user.module on line 368 (or 378), which has just been fixed by the core developers (i.e. will be in the 6.4 release). The error messages seem to be the same, and comment #2 on that issue is from someone also running LDAP Integration + Webserver Auth.

I don't have any way to test the LDAP Integration module, so I can't theorize what's going on there. However, webserver_auth calls the user_external_login_register() function that was patched, it may also need updating.

I've never coded to IIS, so I'm not too familiar with it, but I'm trying to figure out what's going on here. I downloaded this LDAP integration module and had a look at the code—that's the one you were referring to, right?

When you say "Turns out, the strip prefix thing only works for creating users, not for logging in." that's precisely the intended behaviour. The users are logged in by matching $_SERVER['REMOTE_USER'] with {authmap}.authname; the strip prefix only affects the value of {users}.name. Because {users}.name is only used for display, it can contain absolutely anything (the user can even change it) and webserver_auth should still work.

As far as I can tell from reading the code, ldap_authentication connects to the LDAP server and tries to get an LDAP distinguished name (dn) that matches {users}.name, as entered on the login form. Then it tries to connect to the LDAP server a second time, using that dn. If this works, the user is considered authenticated, and logged into Drupal. Perhaps some other processing for user details is done; I haven't read the code too closely;

So ldap_integration and webserver_auth do different things. ldap_integration handles both authentication and login. webserver_auth only handles login; it assumes the web server has already authenticated (against LDAP or something else) the user—hence the name.

Does this seem correct, and make sense? If so, then I think maybe you are trying to do the same thing (LDAP-based login) two ways. If you can get IIS to do HTTP authentication (the user's browser shows a login prompt or dialog, e.g. https://engsci.utoronto.ca/orientation) against the LDAP server, why do you also need the Drupal login form? You could use webserver_auth only; optionally you can use the extra processing setting of webserver_auth to connect to the LDAP server and get or process any extra information (like a full name). This is exactly what I do in http://drupal.org/node/206223#comment-911611 (already linked in #1 above).

If I've misunderstood what you're trying to do, please clarify!

From my experience webserver_auth and ldap_integration don't work well together. I haven't nailed down exactly why, but I think it has to do with the entries in the authmap table.

I had the same problem that the original poster had and I thought that the ldap_integration module had a lot of overlap with the webserver_auth.

I made a module that is a trimmed down version of the ldap_integration module that works well with the webserver_auth module. There is a little more detail about this module in this post http://groups.drupal.org/node/14614.

Since this is a specialized case of webserver_auth, I didn't write this as a patch to webserver_auth. I am not sure if this should be a "sub-module" of webserver_auth (similar to text module of CCK) or a separate module with webserver_auth as a dependency (similar to the link_field module for CCK).

The module is attached.

great module!!

do you wanna continue working on it? and perhaps add the ability to have 2 or more ad servers?

@cybertron1: Thank you for the comment.

This version is a good starting point, but the module needs some work. I have made additional changes that are specialized to my use case. Please feel free to do what you want with the code.

I don't have time to maintain this as a d.o project, but if someone wants to maintain it I would love to contribute.

I haven't figured out a good method to trigger profile updates. The code above uses hook_user($op == load) which seems to be fired on every page load. For my implementation I changed it to hook_user($op == view). Probably the best case would be to use a hook that is fired only when webserver_auth creates a new user plus a cron task.

Your suggestion to support multiple AD servers is good, but adds quite a bit of complexity.

actually implementing multiple ad servers shoudl be too hard, unfortunatly I am not good enought at coding (yet) but my idea is like this:..

Create a db-table with all the values stored, add ad servers one after another, when a user logs in check in the first ad-server, if no match continue to the next and so on until it reaches the end of the table. if no match is found then create a user.

but I have been trying to make the module to create the db but don't quite gotten there yet.

if anyone in here, wanna give me a hand in implementing the above I would be very grateful....

cybertron1: Take a look at the code in http://drupal.org/project/ldap_integration. That module has setup you are describing.

thanks, will take a look

Is there documentation on how to use this module?

Tnx - Nestor

If you are looking on documentation on how to install modules that is available here:
http://drupal.org/getting-started/install-contrib

If you are looking on how this module works you need to have some sort of authentication occurring on your web server. I personally am using mod_auth_kerb ( http://modauthkerb.sourceforge.net/ ). Once the module is installed and the webserver is authenticating users it will automatically add a drupal user for each user the web server authenticates.

Hope this helps,
boilermaker.jb1

Closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.