ldap_integration on Drupal 7

subscribing

I'm working on writing a more generic ldap api (project name is ldap_api) that separates the ldap configuration and core function set from other modules. The goal is to be able to define an ldap server with the api and then use it for authorization, authorization or whatever.

I'm shooting for drupal 7 for this, but am working on a drupal 6 version also. I need ldap group functionality, separate from ldap authentication so the ldap_integration suite does not work for me. LDAP Integration is the module to go with if you need ldap now. My feeling is that it simply needs to be rewritten in an API model as the authorization and authentication are too tightly coupled. I rewrote ldap groups and some patches to ldapauth to accomplish this some time ago, but the patches never made it in.

I have the api done for drupal 6, but need to write test modules that leverage the api. As well as unit tests.

ldap_api purpose/goals:

1. Provide commonly used LDAP functions beyond those built into PHP. (see ldap_api.functions.inc)

2. Provide LDAP Server class for binding, searching, etc. to LDAP

3. Provide LDAP Server data structure, web interface and caching for LDAP Server configuration(s) with:
- built in core parameters such as server address, port, binding credentials
- hooks for other ldap modules to modify/extend ldap server configuration by
- adding fields to configuration form
- adding fields to ldap_api_servers via .install files or to "data" generic storage field with module name for namespace
- flagging if a given server is enabled for that module.

4. Provide general ldap preferences to be used by other modules:
- whether to encrypt passwords
- whether to require ad user passwords are entered over ssl

5. Provide basic status and testing functions for servers with hooks available to other ldap modules
- status check for ldap extension installed
- other helper functions previously in ldap help

6. Implementation of exportables, patterns, and other export/import functionality for configuration data.

Thank God. LDAP API would be a great help. Please let us know once you have created the project (even if it is extremely alpha), I would like to contribute!

I'm working on getting the alpha. This aspect of the thread should be moved to http://drupal.org/node/793146 and this one should continue as ldap_integration on Drupal 7.

We moved this to http://drupal.org/project/ldap to keep in order with prevailing naming conventions.

I've ported our version of ldap_integration to Drupal 7, it wasn't a big job, but our version is not vanilla, I've made a bunch of changes to it over the past few months which I've provided patches for in the issue queue but none of them have been incorporated as yet.

I'll upload it here once I've ironed out the kinks.

@lambic If you don't mind, can you take a look at http://drupal.org/node/809430 and add any insight you have on the authentication workflow from porting this to 7. thanks.

@johnbarclay: I gave it a quick read and it seems to make sense, but I don't have time to look at in-depth this week. The main gotchas for me to get the existing module working were:

* user_authenticate() no longer takes an array parameter, it takes $username, $pass
* The login form now expects $form_state['uid'] to be set if login_validate was successful
* user_load() is replaced with user_load_by_name() for looking up users by username
* all db queries need to be re-written to use the DB-TNG (luckily I'd already abstracted them out to ldapauth.db.inc)
* The theme function for the server list needed lots of TLC

Also, when I said in #6 that I've ported ldap_integration, what I meant was I've ported ldapauth, I haven't finished ldapgroups or ldapdata yet.

subscribing

(LDAP support should go in core...it's too important for enterprises)

It would be really great to have one stable (D6 / D7) LDAP module, like Kafu said it is indeed important for enterprises.

+1 for http://drupal.org/project/ldap

subscribe

subscibe

If you would like to have some additional input (and it would really help us) with the new LDAP module, please check out #964226: Closed Thread: List of Wants, Features, and Fringe Cases as it will be the primary feature list we are working towards with the new module.

subscribe

subscribe

ok, here's my porting work so far on the ldapauth module. There's significant rewriting of the database stuff but the ldap code is fairly similar to the original. The admin interface needs work still but authentication works.

The attached file includes only the files I've changed or added to the original.

Er, that tgz seems to be 0 bytes. Care to try it again?

Strange, let's try that again

Looks like a good start. Had a couple of questions.

- hook_user is not implemented in d7. use hook_user_update etc. replaces them
- i didn't see user_get_authmaps or user_set_authmaps in the code. how are you tieng into the authmap table?

I didn't look it over too closely as we're doing the same thing in project/ldap

I do have some notes at: http://drupal.org/node/809430 that may be useful.

Once ldap has done it's thing, Drupal takes over and handles everything else. I'm expecting ldapgroups to be more tricky though as it was implemented in a slightly flaky way to begin with.

subscribe

The file: includes/LDAPInterface.inc is missing from the tarball.

On the "Add server" page, "Parameter 1 to ldapauth_admin_form() expected to be a reference, value given in drupal_retrieve_form().
I am not sure what the correct fix here is because I am not sure why an argument is being passed to the add page in the first place. (And then the function has a few extra parameters that default to NULL)

The database query code works differently in drupal 7.
See: http://drupal.org/update/modules/6/7#dbtng
See: http://api.drupal.org/api/drupal/includes--database--database.inc/group/...

Where you have ldapgroups_in_dn = '%s' will now have to be something like ldapgroups_in_dn = :ldapgroups_in_dn
The passed arguments will need to be an array like: array(':ldapgroups_in_dn' => $values['ldapgroups_in_dn'])

I was about to provide a more detailed example, but the ldapgroups_update_server function does a manual update.
I think the practice is to use drupal_write_record() instead of db_query("UPDATE ..

EDIT:
also, ldapauth_admin_form() is somehody setting sid to 'add'. which causes the add server to attempt to do an update server instead of an add server, sending an invalid query.

Moving groups to drupal 7 is not so tricky. Its actually easier once you separate the authentication from authorization and move the user to ldap server configuration into the server part of the code. #968578: LDAP Authorization: Separate Authentication from Authorization

In the ldap project, I ended up overcomplicating it so other authorization modules could hook into the ldap authorization/group mappings for the user. http://www.gliffy.com/publish/2318063/

By treating drupal roles, og groups, civicrm memberships etc. as the same class of objects, other modules will be able to leverage ldap authorization more easily.

Let me know if you want any of this ldap groups/ldap authorization code before I check it in.

Pulling data from the ldap and storing it into custom profile settings fields has been needed in some cases.
I am not sure if this is part of the "groups" from this old code.

And if one is pulling data from ldap and populating user profiles, then the ""When user logs in, On each page load, etc." options are still quite important.

I have not used the Mapping of ldap groups to drupal roles, but it does make some sense.
This functionality is probably a good idea.
It does not have to be the old code, but this functionality is important for large websites.

+1 for #24: Pulling data from the LDAP and storing it into custom profile settings fields is very much needed feature!

One use case scenario: use profile fields (pulled from LDAP) for populating fields in Webform module "nodes".

AFAICS in UI this is part of the LDAP > DATA (module).

Also it is important to be able to choose between the read only and read / write mapping.

ldap_integration has the ldapdata module which handles profile population. That's the least important module for us so I won't be doing it until ldapauth and ldapgroups are done.

thekevinday: the tarball only contains the files I've modified or added.

Thanks, i read #18 without paying attention to #16.

Is anyone using lambic's effort successfully? I am advocating Drupal within an Enterprise ( not a spaceship) but IT has put a hold on the whole ekkfort till there is a solid D7 upgrade path.

I'm also interested to see how this is progressing, and how it compares with the LDAP API module.

I've installed the code from #18 on d7-rc1 and when I try to set up a server I get "Warning: Parameter 1 to ldapauth_admin_form() expected to be a reference, value given in drupal_retrieve_form() (line 766 of /drupal7/includes/form.inc)." and I get no interface to define a server.

I changed

ldapauth.admin.inc:function ldapauth_admin_form(&$form_state, $op = NULL, $sid = NULL) {
to
ldapauth.admin.inc:function ldapauth_admin_form($form, &$form_state, $op = NULL, $sid = NULL) {

and it now works. I managed to login as an LDAP user. Thanks for your efforts Iambic.

Is it worth adding a DRUPAL-7--1 branch and building from there?

thanks jzornig, I'll add that change to my version. I expect there are other small issues with the admin interface thanks to changes in forms api, I'm trying to schedule some time to work on this and another module I need to port to D7.

DamienMcKenna: Seems reasonable. My version contains a significant rewrite of the database management so I don't know if the maintainers want to use that, but it's there if they want it.

subscribing

I'm working on the ldap_authentication module part of the ldap project and had some feedback and questions. My workflow is at: http://www.gliffy.com/publish/2362004/ and attached is the bulk of the code (though I haven't even tested it, so its just to show how I am approaching it.

I looked over lambics d7 authentication code in ldapauth.module, particularly the validation function. Here are my thoughts.

Suggestion. There are some functions that might shorten some of your code and allow ldapauth to work with other autentication modules besides drupal built in authentication:
user_get_authmaps()
user_external_login_register()

Suggestion. If you are careful about where in the order of validation functions ldapauth_login_validate is placed, you can remove all your code that callse user_authenticate and let the drupal authentication workflow take care of drupal authenticated users. That is use the condition LDAPAUTH_LOGIN_PROCESS == LDAPAUTH_AUTH_MIXED to determine where ldapauth_login_validate is inserted, rather than overwriting user_login_authenticate_validate in the validation array.

Suggestion. Remove check on blocked account. this is taken care of in user_login_name_validate()

Suggestion. Lose the cleartext storage of the ldap password in the session until the UI has a way of opting into that.

Question. I think checking for blocked status isn't needed, as its called in bootstrap. Do authentication modules need to call drupal_is_denied()

Question? How are you dealing with multiple authentication ldap servers?

Question? Shouldn't ldap authentication modules use some sort of language such as prohibit drupal user accounts except user 1 instead of "LDAP exclusive" terminology. We aren't really forcing out other external authentication modules, but we may force out built in drupal authentication.

Question? Do you think there is a use case for letting all drupal 7 built in admin role members login with drupal authentication instead of just user 1?

johnbarclay: Most of the code you're talking about was from the original ldapauth module, so the module maintainers would probably be better placed to answer your questions. I've resisted the temptation to rewrite or change more than I needed to.

With regard to the cleartext storage of the password, there is an option for that in the UI already.

We don't have a use case for allowing all admin role members to use drupal auth, as our admin roles are controlled by LDAP, but it's possible that other people might want to do that.

thanks. then I guess your code just needs a test to see if they have selected to not store the password in clear text.

In response to the last sentence on #36 & #37:
I have a use case where we have users who are in ldap use the system and configure content on a system.
We then have 3rd party users who are not and cannot be in the ldap.
Therefore, not every drupal user will be in ldap and "mixed mode" must be supported.

Given that this case exists, then the opposite probably exists.
Example:
If I were a service provider who provided drupal websites to third parties.
These third parties want the drupal system to integrate with their ldap.
The service provider may need admin accounts on that system to do administrative tasks or assistive tasks.
These users might have admin role and probably will not be in the ldap of the 3rd party customer.

It will be common for people to need simultaneous non-ldap + ldap accounts on their drupal system.

This is all something most people here probably have an awareness of, but I wanted to emphasize its importance.

Yes. the mixed mode takes care of this use case. Allowing admins to use drupal authentication in an ldap exclusive scenario doens't see terribly useful since its a fallback for when ldap fails. In that case user 1 would be the one to be used anyway.

subscribing

subscribe

subscribe

subscribe

subscribe

subscribe

subscribe

Looks like my changes don't work so well with the official D7 release. I'll try to investigate further next week.

subscribe

I'm with DamienMcKenna in #33. It'd be nice to develop and test patches incrementally against a DRUPAL-7--1 CVS branch. If there's a plan to use http://drupal.org/project/ldap to re-implement this in D7, then maybe a new 2.x branch (DRUPAL-7--2) would be more appropriate.

In relation to #39, mixed mode also needed. Thanks.

Here's how the mixed authentication works in http://drupal.org/project/ldap

- http://drupal.org/node/1053748

the tests and desired results are in the "User Logon Tests (ULT) " section of
http://drupalcode.org/viewvc/drupal/contributions/modules/ldap/ldap_auth...

subscribe

Where can I find the missing file includes/LDAPInterface.inc?

RE: #48 - lambic, any progress in your investigation?

subscribe

+1 ldap integration for drupal7

subscribing

andrabr: sadly not, it got pushed back by other priorities. I don't know if the ldap project is progressing any faster, but either way I think the two projects need to merge somehow, especially as ldap_integration seems a little rudderless right now.

subscribing

subscribing

I was using lambic's patch successfully for some time, but now it doesn't work anymore, and we didn't notice early on because Drupal caches the password hash after the first successful access. This is very bad news for us, but hopefully we can make it work again. Hopefully won't have to resort to git bisect on Drupal core... subscribing

subscribing

subscribe

subscribing

subscribing

subscribing

We released a 7.x-1.0-beta1 of ldap. It needs more simpletest coverage, documentation, and testing if anyone wants to help move it forward to release candidate stage.

Subscribing...

I hope the developers of LDAP_Integration join LDAP (API). Not only for D7, but already make a transition for D6 that it has all LDAP_Integration functionality.

Sometimes developers focus on the new core (D7) and forget about the many present users that like the new developments in D6 too, before upgrading to D7 when all modules for their site have been ported. Not only like, but would make such a transition smoother if part of it can be done on beforehand (like switching from ldap_integration to ldap). Also for new sites that need D6 modules that haven't been ported yet (somewhere next year), the favorable option is to have the new LDAP(API) instead of LDAP_Integration.

I work on ldap api. I agree the following are desireable:

1. backporting of specific functionality to ldap_integration
2. upgrade path/automated upgrade patch for d6 ldap_integration to d7 ldap
3. including all ldap_integration features in ldap_api

But there aren't a lot of people following through with their offers to work on ldap api, so the project still lacks documentation and full simpletest coverage. These are the highest priorities as they both make maintenance of the module easier. And then there are several other priorities that I believe are higher than the 3 above. My guess is #1 above won't happen. #2 will be done by site admins by hand, though hopefully someone will write an upgrade/cross grade patch. No one has even requested this yet. #3 is a little late; ldap api 7.x-1.x is trying to get from beta to release candidate and the best way to do that is push new feature requests into the 7.x-2.x issue queue.

The minimum that ldap users can do to make the ldap 7 project what they want is make sure their feature requests are in the code or the issue queue. So give it a whirl and make sure the functionality you need is in it.

The next step up is actively testing and giving feedback on the module; writing/improving documentation; and helping others in the issue queue. Code reviewing, code writing, figuring out where functionality from ldap synch, ldap provision, ldap og, etc are also important.

Thanks for your work on this module! Is the code in #36 still the latest reference point? Our team is hoping to get some LDAP related work which we would want to contribute back to this project.

We haven't had a client that's needed this at this point, but interested in trying to find ways to help move this project ahead & contribute where we can. Has the module been run through Coder yet? That's another good way to look over missing pieces with a large code base.

No. the latest code is at:

http://drupal.org/project/ldap

The module goes through coder before each release, but not it the dev snapshots. Please take a look through the issue queue and see how close current code and issues are to what you are looking for. Would love to have some code contributed back and can help get you started if thats useful.

The closest thing to a status report is http://www.gliffy.com/publish/2315088/ but basically the 7.x-1.x version is in beta with only one feature missing, additional simpletest coverage, and at least one bug. I think new features are fine if they don't break thinks and have simpletest coverage.

So if you need something in the 1.0 branch, please take a look soon.

I just read "LDAP is intended to become a replacement for LDAP Integration." -- this makes sense!

Thanks John. At this stage I'm not sure what we'd need. However, we can try to write up some tests to contribute.