LDAP User: Provisioning of LDAP accounts and LDAP Attributes

I'm having the same issue. I'm guessing that the module should create a new LDAP account if one does not exist? If this needs to be added to the module then we have some resources to help make that happen. Can you confirm if this is the case and if if so, what needs to be done?

ldap authentication does not create ldap accounts. Its functionality is to authenticate against ldap and create drupal accounts for those who are ldap authenticated. I think ldap provisioning may have played that role in the past or perhaps ldapauth in 6 did. I'm not sure.

I think a patch to do this would be acceptable. I think you are asking for this:

- when a drupal user authenticates via drupal user module (or openid module or any other external authentication module) an ldap account is automatically created for them.

Thanks John. Yes I started looking at ldap_provisioning yesterday in Drupal 6. This is the functionality that we're looking for I think.

So I guess what where looking at is a conversion of ldap_provisioning from 6 to 7 - a straight copy or perhaps a sub-module in ldap authentication. Can you confirm this and which option you would prefer? And how/if this fits into your dev plan. We're ready to start as soon as possible.

We've been working on Drupal for some time and have made quite a few commits (most changes by jdelaune).

Cheers, Ian

I definately prefer a sub module. I think what people need most is a stable ldap authentication and authorization with solid test coverage; adding more features to ldap authentication works against this.

With git as the new version control tool, I see no problem with adding it to the ldap package as a sub module if you want it here. I think from a usability point of view, sub modules are better.

Here is roughly the state of the project: http://www.gliffy.com/publish/2315088/
Ldap authentication has bug fixes, ldap authorization is nearly feature complete but needs a test grid and bug fixes.

Let me know if you need any additional hooks or functions in ldap_servers. And feel free to call or skype if you want to chat about this. I'll send you this via the contact form.

You also might get in touch with retsamedoc and see where the api part of the ldap project is headed and see if you can leverage any of his code. Essentailly everything in the ldap_servers module is slated for replacement by the api at some point. He has an outline at http://dev.digitalactionsproject.org/wiki/Drupal:LDAP_API.

and here is roughly how the classes and modules layout now:

http://www.gliffy.com/publish/2376942/

We've now got some dev resource working on the D7 port of ldap_provisioning as a submodule as discussed.

We should be able to report back on status of this in a few weeks time.

Let me know if you need any functions in ldap server in the short term. I added a couple #1111000: LDAP User: add functions for modifying ldap user entries and passwords as requested and can add them as needed until an api is written.

Hi ihamilton

This sounds great, been looking for this kind a function in D7.

Any update on this ?.

Best regards
Morten

Not sure if this belongs here or a new issue. I am also looking for a similar functionality, but in reverse. Currently have an existing fully populated LDAP that I would like to provision new drupal accounts from the LDAP accounts. LDAP gets regularly update by other sources so need those updates to automatically update the drupal profiles. So for a list of features for the provisioning sub module, I think the following would be excellent additions:

A mapping that links account fields to LDAP fields (D6 version used ldapdata module) - might be another submodule
- ldapdata utilized a textareas for users to type out exact mappings
- could utilize the test feature in ldap_servers to grab a list of possible LDAP fields to map to help make it easier to map.

Create/Update accounts in LDAP when they are created/modified in drupal.
Create/Update accounts in Drupal when they are created/modified in LDAP.

I am currently throwing together the creating drupal accounts from existing ldap accounts. I will probably use a hard coded mapping to start due to deadlines so it won't be a good idea for me to commit what I will have, but would be happy to share ideas.

For those accounts to work with ldap_authentication, the following code from ldap_authentication.inc should be executed, so the ldap data and authmaps are stored. I can move that code into a function such as

    /**
     * returns new user account if created, otherwise integer error message such
     * as LDAP_CREATE_ACCOUNT_ALREADY_EXISTS, LDAP_CREATE_ERROR
     *
     */
    function ldap_create_drupal_account($name, $mail, $dn, $sid, $loginConflictResolve = FALSE) {
     }

and put that in the ldap_servers.functions.inc file. That way it can be reused.

 $edit = array(
      'name' => $name,
      'pass' => user_password(20),
      'mail' => $ldap_user['mail'],
      'init' => $ldap_user['mail'],
      'status' => 1,
    );

    // save 'init' data to know the origin of the ldap authentication provisioned account
    $edit['data']['ldap_authentication']['init'] = array(
      'sid'  => $sid,
      'dn'   => $ldap_user['dn'],
      'mail' => $ldap_user['mail'],
    );

    if (!$account = user_save( NULL, $edit)) {
      drupal_set_message(t('User account creation failed because of system problems.'), 'error');
      return FALSE;
    }
    else {
      user_set_authmaps($account, array('authname_ldap_authentication' => $name));
    }

Also for the profile mapping, I would suggest looking into the feeds module http://drupal.org/node/622710 when you are beyond your immediate needs and writing a fetcher and parser plugin for the ldap user data. Then the existing user profile Processor can do the actual profile data synch. (or data could be processed by another processor such as node for other use cases).

Hi ihamilton

Do you have any updates on your development ?

Best regards
Morten

Hey guys we outsourced the development of this part of the LDAP module since we are too busy at the moment to do it in-house. We should have something back from the people developing it within a week or two. Once we have something we will post it here so hopefully it can be used by the whole community and we'll be able to bundle it back into this project going forward.

Just wanted to let people see what I had going on. I have attached two add on modules that I am using right now. One scans ldap for accounts to create/update in drupal. Currently called ldap_provision but name can change if need be. Other one is ldap_profile which allows you to map ldap fields to drupal fields for when you create/update accounts. This is still undergoing development and having features updated/created. Let me know if this is something that we want to think about including in the ldap package.

John, currently i have the create drupal account function in my ldap_provision module. This can be moved over to the ldap_servers module if you think what I have is worthwhile.

Thanks this is wonderful.

Since some of the code and user interface for creating drupal accounts from ldap accounts is in ldap_servers, I think it would be simplest to leverage whatever we can from ldap servers module. We can sort this out as we go. When you need a function already in ldap_servers or need one added, let us know. User the ldap_create_drupal_account() function to create a drupal account with ldap association.

I like having ldap_profile and ldap_provision in this package. The only drawback is versioning. If we want to have a release candidate for the package, all the modules need to be release candidates. The pluses are its more usable for users, we can work the interfaces together, and we have a larger group of committers that can keep an eye on the whole project.

How do you feel about some of the things we committed to early on in this project:
* Object Oriented; no PHP4 support.
* Stable and secure releases with strong unit and functional test coverage.
* Community of contributors for stability, reliability, innovation, and reasonable workload
* Drupal coding standards; doxygen code documentation.
* Advanced Help support and solid documentation.
* Internationalization.
* Exportables/Features Support
* Accessibility:

Should I put these in head for now while we see how people feel about these in the project?
Are you the same group as http://drupal.org/node/1089256#comment-4368914?

I took an initial look at these modules. They look good.

The one thing that sticks out is that they assume a particular ldap server instance. They should have as an option to pick an ldap server. In the ldap_servers module an ldap server instance doesn't necessarily represent a different ldap server; just a different configuration of one. So it is quite possible that someone would setup an ldap server instance for authentication and authorization with a lower level service account and another instance for ldap provisioning with a service account with more rights. I'm not sure that multiple ldap configurations is a heavily used use case, but it resolves a few edge cases in the issue queue.

Hello folks,
I am working since 6 months on solutions for a complete control of a LDAP directory server with drupal. I have now some experience in OpenLDAP including SSL connectivity and sync replication, the LDAP Integration package, the LDAP Provisioning module for Drupal 6 and some custom needs and code.

My Problem with the current Provisioning Module is reported here: #905848: Simpler LDAP Provisioning Using Core User Registration
So I just started my own project in a sandbox: http://drupal.org/sandbox/C_Logemann/1130156
I will be happy if we can cooperate to find a way for all of our targets.

If the LDAP module should "become a replacement for LDAP Integration" I hope you hold something of the structure of this? Especially to provide the major API of LDAP handling?
Because I have just started testing LDAP for Drupal 7 and the code in this issue I have only a little bit experience with it.

The code of #14 seems to be more a replacement for the ldapdate.module of the old LDAP integration package with a cron based data handling? I can't find anything of the old LDAP provisioning module in drupal 6 in it. This could be a confusion by the user and in this way a kind of naming issue. But I have a major problem with the strategy of cron based synchronization. For me it is very important to have a possibility for changing some fields all the time. If a field in LDAP is connected with security features in other applications the change have proceed when the logic in drupal (maybe a business logic) decide this. Maybe some rules actions would be nice in the future?
I am open to discuss a good provisioning module that fits all of our needs and merge our work. But we can also build different modules for different needs and all based on a common LDAP API provided by the LDAP module where I like to help. I agree with #16 that we need the possibility for different server instances.

As described in my LDAPcontrol sandbox I think LDAP is very complex and flexible. I like and always support flexible ways in drupal and I want this flexibility in this area, too.

If you only want to authenticate users with existing LDAP directory servers you have to follow the structure given by others including the software companies and LDAP administrators. So you have to keep the flexibility in authentication.

If you want to take control of LDAP you have to decide and configure your own LDAP directory server (I use openLDAP for this). By myself I decided to use the common objectClasses "person" and "inetOrgPerson" even if I don't have surnames of the users and have to fill this field e.g. with the username again. This is one of the things I handle in another way like the old provisioning module.

In all of the LDAP modules I have tested there are a lot of fields in the UI where you can put complex code in. I think we can and should put some configuration options accessible by hooks. This functionalities are not for drupal beginners I think. If you need a very special way like a custom username datatable to use there is a good API usable in custom modules the better way.

Yesterday I started my research of possibilities to use on LDAP database together with drupal 6 and drupal 7 because of the new password encryption. I try to realize at first the way of new blowfish encryption in drupal 6 (see my sandbox). But I think there should be a way to handle more encryption possibilities in LDAP authentication. I have already found some code for this direction in ldap_servers.encryption.inc. This is an example for the flexibility I mean.

If you compare the usage of ldap integration with the usage of ldap provisioning module it is clear that LDAP controlling like I want (see my description in the LDAPcontrol sandbox) is a minor thing. Because this it is possibly better if the LDAPcontrol module is stand alone?

greetings,
Carsten

regarding #17:

I would not suggest building anything on top of any module that does not have:
- an api foundation
- solid automated testing
- good documentation
- support for internationalization
- 2 or more consistent contributors

ldap 7.x-1.x lacks all of these. The best way to get to ldap data or ldap provision or ldap synch functionality is to have a solid base in the ldap_api part of the ldap project with good automated testing and documentation; otherwise you are building on top of a house of cards. the issue queue will be choked with bugs and support requests like ldap_integration and no progress will be made on new functionality.

I would put your efforts into solidifying ldap before building on top of it.

retsamedoc has a good plan for the ldap_api part of the project and ldap 7.x-2.x branch is there and waiting for it to be taken up. We have one person committed to documentation and another committed to automated testing.

I would start by:
- breaking comment #17 into individual issues.
- submitting some patches as a gesture of your commitment. Some simple ones include #1023366: Switching to Encryption does not excrypt current passwords, #1029940: Clarifying service account encryption, #807402: LDAP API: Allow user to set Encryption type in ldap api interface

Personally I think ldap synch, ldap data, and ldap provision should all be feeds plugins. Feeds has a provider/consumer agnostic approach such that plugins can target users, nodes, ldap etc. Conversely the data can be harvested from any of these. Building such synching and mapping tools specifically for ldap use case seems like a splintering of efforts and requires excessive code and documenation to maintain.

Regarding #15-16 I agree that we should leverage the ldap_servers (or api when it is built). I also agree that versioning could be an issue including this in the package. I am currently very busy so am likely not able to respond and update as quickly as the ldap package has so far. I worked with the previous versions in d6 and do like the way this module is heading design wise. I think we can hold off putting this in head until we see if more people like #1139196: Ldap Provision: LDAP data pre populate are asking for this type of functionality.

I understand this module should prepare for the multiple ldap server configurations. I am not familiar with this type of scenario so wasn't programming to support it initially for my needs. I think it could be a big benefit I could see a scenario of where this is used. It will help me understand it so I can put this in for supporting it.

has provision and profile mapping been added in the latest dev or will the version posted here still work with the current beta?

I only need to map some ldap values (Name, address, department, etc) to my drupal user profile fields.

thxs

Another approach to provisioning drupal accounts from ldap is this:

• Modules: ldap_query, ldap_server, ldap_query, ldap_feeds, feeds
• Configure an ldap_server.
• Create an ldap query (or more) in ldap_query module. The query should return one user entry for every drupal user to create.
• Create a feeds importer that uses ldap query fetcher, ldap entry parser, and user processor

I would like to have seen this entry before developing ldap_provision2 (see #1115704: Drupal 7 Status Updates #22). I don't know if I would done the same way or with this new interesting approach. Anyway I post this entry to unify all efforts for doing an unique module.

Hi,

I would like to know how is going the progress on making LDAP accounts from drupal7, since in the specification of my project i will need when a users is getting a registration from drupal filling a form, "automatically"(after administrator approval) to get LDAP account . LDAP is my "shared" DB between drupal7 and moodle2, and i would like to make it an automatic procedure and not populating manually every LDAP account. This part is crucial to my project and i was wondering what is the best solution to this problem and what choices do i have, any help will be more than appreciate.

Thanks in advance.
P.S. i'm sorry that i'm not capable on helping on the submodule, thanks for your work. Hope i wrote this in right place.

I see the following methods of provisioning and updating drupal ldap identified accounts:

1. cron that queries ldap
2. ldap feeds user provisioning feeds processor. Would be coupled with FeedsDrupalUserLdapEntryFetcher.
3. rest and/or soap interface for pushed changes such at ETLs like talend. This gets outside the scope of the ldap modules since such provisioning could create drupal accounts, which are ldap authentified on logon. A feeds fetcher and parser for each ETL that provisioned users would probably be ideal. Moving discrete ldap attributes to user fields rather than $user->data would make feeds more useable for this and other feeds use cases.

1 and 2 are really the same thing, but 2 requires the ability to configure feeds. However its more flexible and extensible. 1 is already in ldap provision. 2 is somewhat in ldap feeds. Both likely need some work.

I'm going to take a look at test coverage for 1 and 2 and what it would take to use user fields for ldap storage (cn, uid, permanent uid, server id, etc.) is such a way that they weren't editable by the user, but could be utilized by feeds. I'm also going to look at what it would take to have the following configuration options in ldap provision and ldap feeds if they aren't already there.

• - how often to run
• - [] create drupal accounts
• - [] update drupal accounts (profile and ldap data)
• - what to do when account disappears in ldap (block, delete, etc.)

in 7.x-2.0 provision, profile, and synch will all be in the ldap_user module which will have ldap_server as its dependency.

Making some progress on this. See http://drupal.org/node/1115704#comment-5849562

I'm closing this since its in ldap_user module in 7.x-2.x and its too broad of an issue. From here on out issues related to provisioning to ldap should be more specific.