This is a general thread for progress updates on the LDAP Drupal 7 project. Specific bugs, feature requests, and support requests should go elsewhere. Please subscribe to this for project updates.

Comments

Thanks for clarifying this, John. I was looking through the git repo today and was having a really hard time figuring out the differences since the branch.

I'd like to do what I can to help get this module stable. I have numerous projects that rely on it, since all of my D6 sites for my day job used ldap_integration, which appears to be dead. I'm testing now and will update or add issues as I encounter things.

Do you think you could start using issue numbers in commit messages? It would help figure out what the patches fix. http://drupal.org/node/52287 gives a good reference on the new syntax.

It also looks like there's both a 7.x-2.x branch and tag in the repo. I assume that any patches I create should be against the 7.x-1.x branch for now?

Thanks again,
Micah

yes. 7.x.-1.x is where patches go. thanks and any help would be appreciated. Ldap authorization needs some cleanup, but ldap authentication is strictly bug fixes at this point. Given the level of activity on this module, I think its important to stop new features and work toward stability, automated testing, and usability so there is a useable drupal 7 ldap module.

Please focus patches on ldap servers, ldap authentication, and ldap help for now. I should have my last pass through ldap authorization in a day or 2; before that bug fixes may not be useful.

I'm doing better at getting the issue #s in; the module isn't even feature complete/alpha so I haven't been worried about it. Thanks for the documentation. The mess in git is just me getting used to it. I still don't have the correct code in 7.x-1.x and the 7.x-2.x tag is still not available in the issue queue forms so I need to look at how automation of rolling .x-dev releases is working in the post cvs phase of drupal.

If you are good with git, it would be helpful if whats in head could be tagged as 7.x-1.x and put in a -dev release; 7.x-2.x tag could be made available in the issue forms, even if we just need a dummy version tagged as 2.x. I can give you git access if you are interested in this. I'd like to focus on getting ldap authorization done.

John,

Cool! I just added some more detailed comments in #806068: Call for Co-Maintainers and Developers.

Micah

micahw156, Thanks for working with the testing grid. Feel free to edit the wiki if you can make it any more usable, but don't put too much thought into it; No one has used it yet. Finished ldap authorization last night. Need to test through a clean install and will push it to head in the next couple of days.

I'm plowing through email and some other non-related issues today, but will get back to the test grid this afternoon or on Monday. Authentication testing is going well, but I haven't gotten all that far through the list and need to research what the testing codes mean before I can test some of the combinations.

It sounds like you're planning on dropping one huge commit onto 7.x-1.x soon, which makes sense in terms of keeping the commit history a bit more succinct. Are you doing incremental commits locally as you go? If so, would you have any interest in pushing your working branch? If you would, I'd be happy to pull and test against that. It would probably cut down on the duplicate issues getting filed for stuff you've already fixed but haven't committed to HEAD yet. You could then kill the working branch after it's all committed back to into the main stream. Just a thought.

Category:support» task
Priority:Major» Normal

I created a 7.x-2.x-dev branch. Its an empty placeholder for future development. Please tag additional feature requests for 7.x-2.x-dev unless they are small enough to get into 7.x-1.x.

The required work in ldap_servers, ldap_authentication, and ldap_authorization for 7.x-1.x release candidate is:
- bug fixes and tests
- documentation (Andrew)
- I18n and accessibility tweaks (Need someone to take the lead on this)
- drupal coding standards (Need someone to take the lead on this)

The desired tasks are:
- automated functional test coverage (Need someone to take the lead on this)
- caching/performance review/tweaks (Need someone to take the lead on this)
- testing exportables (Need someone to take the lead on this)
- drush integration. (Need someone to take the lead on this) this is very helpful to those using drush make and script based builds

Don't respond to this thread when commenting on existing or adding additional tasks to the queue is more appropriate. I'm adding the above tasks to the issue que as placeholders for discussion and tasking.

7.x-2.x has the following in it so far:
- replace all or part of ldap_servers with an ldap api model
- deal with nested/recursive groups in ldap_authorization

I committed 7.x-1.0-unstable6. I'll try to push out a new release every week or so. Hopefully the next one will be a beta.

Now that the bulk of the code is done in all three modules, I'll push patches and commits to head (7.x-1.x-dev) as I make changes.

Sorry for the long time between commits and thanks to everyone for the improved issue queue activity.

Marked #966762: LDAP: Progress Updates as a duplicate of this thread.

I fixed a couple of bugs in ldap authentication and ldap servers and put the results in head. they should roll out at 7.x-1.x-dev with a 4/16 or 4/17 datestamp. I want to go through ldap authorization testing before and unstable7; it seems broken on first look. Here are the changes in head:

Issue #1119774: Cannot add new server with Service Account Bind by micahw156, weboide: fixed issues with storing and removing service account password
Issue #1126600: Numerous WSOD failures testing latest LDAP Authentication Build. by micahw156: fixed logging errors from "detailed logging" option that caused WSOD fixed.
Issue #1119330: No such object en LdapServer->search() by alvmarveg: fixed untrapped error when bad basedn is used

Title:Version and Releases Status UpdateVersion and Releases Status Updates

I pushed a new version of ldap to head. Fixes were largely with ldap authorization. This will be helpful to those struggling with ldap authorization in unstable 6 which was very broken. After some more testing, this will be unstable7.

Here are the changes thus far:
Issue #1119774 by micahw156, weboide: fixed issues with storing and removing service account password
Issue #1126600 by micahw156: fixed logging errors from detailed logging option that caused WSOD fixed.
Issue #1119330 by alvmarveg: fixed untrapped error when bad basedn is used"
Ldap Authorization: fix role saving bug introduced in 7.x-1.0-unstable6
Ldap Authorization: fix $user->data['ldap_authorizations'] saving bug introduced in 7.x-1.0-unstable6
Ldap Authoirzation: removed option to remove non ldap granted authorizations since it wasn't implemented
Ldap Authorization and Ldap Authorization Drupal Roles: made distinct functionality in each as far
as storing $user->data['ldap_authorizations'] data. Only gave drupal role class access to
$user->data['ldap_authorizations'][$consumer->consumerType] array; not entire user data array
and made saving of $user->data in ldap_authorization.inc
Ldap Authorization: simplified case sensitivity in drupal role names in LdapAuthorizationConsumerDrupalRole::createConsumers method

I'll carve out some time this week to pull the latest version and repeat the testing I've done so far, then try to get farther through the rest of the test matrix.

I pushed out more simpletest functionality. As bugs and support requests come in, I'll try to add more simpletests to recreate the bugs and test that they are resolved.

I'll try to finish up any open bugs this week and hopefully we can start pushing out betas soon.

Version:7.x-1.x-dev» 7.x-1.0-beta1

I tagged a release beta1. It has more or less complete ldap authorization simpletest coverage; and some ldap_authentication simpletest coverage. I also got the feeds fetcher and parser to work, but thats in dev, not the beta1 release. My feeling is that the following are needed for a release candidate, in order of priority:

- full ldap authentication test coverage
- common use cases documentation
- at least one other consistent contributor
- ldap_profile, ldap_provision, and ldap_feeds simpletest coverage and documentation.
- i18n review
- see also: http://www.gliffy.com/publish/2315088/

If anyone can step forward on any of these, or sees other higher priorities, it would be great to hear from you. I can help get anyone started on simpletests as I've become quite familiar with the apis.

Please note that in LdapServer.class.php the search function arguments are now:

search($base_dn = NULL, $filter, $attributes = array(), $attrsonly = 0, $sizelimit = 0, $timelimit = 0, $deref = LDAP_DEREF_NEVER)

I switched the order of $base_dn and $filter to match the order in the ldap_search() function and added the other parameters it takes as optional.

Version:7.x-1.0-beta1» 7.x-1.x-dev
Assigned:johnbarclay» Unassigned
Status:Active» Needs review

I finished the code base for #1170034: Ability to limit which LDAP Groups can Log On and it is in head. Also made progress on ldap authentication simpletest coverage. The summary is in changelog.txt and pasted below.

I'll leave this is 7.x-1.x-dev for a few days so testing can work through any bugs and I'd like to get 7.x-1.x-beta2 out thereafter.

#1172486: LDAP Authorization: II.C. Need support for groupOfUniqueNames objectClass looks like the last important feature for 7.x-1.0 branch. I think ldap provision and ldap profile should probably go in the 7x-2.x branch as they haven't had a lot of feedback and have not simpletests. An upgrade path for ldap_integration would be nice also. If anyone needs a start on that I can point them in the right direction. Anyone who doesn't clear out their autmap tables will have issues such as #1183192: Authentication: Duplicate entry in modules/user/user.module when upgrading ldap_auth to ldap_authentication. If anyone has been through this updrade, at least some directions in install.txt would be a step in the right direction.

Issue #1174332 by endiku: error thrown when trying to add the same drupal role twice. Added simpletest and applied array_unique().
Issue #1192356 by bfroehle: ldap_servers_get_servers returning null instead of empty array. 1192356-Fix-warnings-when-iterating-through-en.patch
Issue #1030404 by ankur: Fixed issue with ldap authentication with multiple servers. 1030404 comment #6
Simpletests by johnbarclay: fixed fake ldap server arrays for simpletests to work with #1030404 patch.
Issue #1170034 by pumpkinkid: Added functionality for limiting who can authenticate based on whether ldap authorizations exist. U.I. was already in, just not functionality.
Fixed whitelist php eval code by johnbarclay. Did not check for php.module enabled, documentation showed wrong variables and return values.
Additonal Ldap Authentication whitelist section simpletests added by johnbarclay: LDAP_authen.WL.php.php disabled, LDAP_authen.WL.php.true, LDAP_authen.WL.php.false, LDAP_authen.WL.exclude.miss, LDAP_authen.WL.exclude.match, LDAP_authen.WL.allow.miss, LDAP_authen.WL.allow.match

I did a coder review cleanup and released a beta2.

I'm going to switch my focus to the 7.x-2.x branch, with an eye toward the api and data integration. I'm looking for feedback and api functionality and what should go in which modules. If you are developing ldap modules, please take a look at the brainstorm I started at http://groups.drupal.org/node/159604 and give feedback.

I think the main work left before a 7.x-1.0 release candidate (besides bug fixes) is:

  • documentation
  • at least one additional maintainer
  • upgrade code and/or documentation for ldap integration 6 users
  • fuller ldap authentication test coverage

Please let me know if I'm missing anything in this list. Bugs should be in the issue queue tagged as 7.x-1.x-dev

7.x-1.0-beta3 has two important bug fixes #1206146: Still not working as expected. and #1213228: Server: Drupal username to ldap username php not called.

The first is applicable if you are using ldap authorization and ending up with group names in the form cn=dsfsdf,ou=dsfdsf,...

The second is applicable if you are using php code to transform the drupal username to in the ldap server configuration.

If you haven't done a clean install since beta1, you should use the "schema" module to compare your db and the module's desired schema.

Issue #1209576 thekevinday: install shows error of undefined constant fixed
Added simpletests for drupal authentication and ldap authorization, and the following 2 issues (#1206146, #1213228)
filtered on array_unique for drupal role mapping to avoid redundant role names
Issue #1206146 danharper (and likely several other issues): allow mapping of cn or other first attribute instead of dn in ldap authorization and check for long drupal role names.
Issue #1213228 johnbarclay: drupal user name to ldap php never implemented in ldap servers. php format has changed.

Alot of patches have been committed to 7.x-1.x dev. I'm rolling this out as beta 4.

LDAP Data Modules
I started to clean up the drupal 6 ldap_integration issue queue. In the process I did a survey of what the various ldap data modules were doing (ldap data, ldap synch, ldap provision, ldap profile, etc.).

Seems like they are all basically synching accounts and user attributes between drupal and ldap, one direction or both. LDAP Profile and LDAP Data synch profile data. LDAP Provision and LDAP Synch synch accounts.

I propose putting all this into a single module called LDAP User, LDAP User Synch or some such. I think this approach will be much more usable and easier to support: Both from the point of view of figuring out which modules to use and developing a good mapping user interface. LDAP User gives a sense of the scope of the module. LDAP Provision, LDAP Synch, LDAP Data etc. all imply a broader role than just user and account data.

Here are my notes.

http://groups.drupal.org/node/167304
http://groups.drupal.org/node/159604

I just committed a new LDAP Authorization Consumer for Organic Groups.

You'll need to setup Organic Groups correctly first, it may be handy to watch this video for that. The new consumer should create a group when necessary and, of course, assign new users to groups based on mappings in configuration. You can also use a configuration page to specify the Node type that is created and the role assigned for new group members.

Please test!

The 7.1 Release Candidate has been slow in coming because I've been very busy and waffling on what to keep in and out of the release. Below is a final release plan.

I want to take a couple weeks off in early December and wrap up the 7.1 Release Candidate. http://drupalldap.chipin.com/drupal-ldap-71-release. If chipin doesn't work for your company or organization, email me and we can work out other methods of payment or where your developers might fit in.

Here is what I want to get done for a release candidate:

- 20 hours. Documentation and User Interface.
- 20 hours. Complete Simpletest Coverage
- 20 hours. Basic Data integration. LDAP Query + LDAP Feeds + Documentation and recipes.
- 15 hours. Support for Nested Groups for Active Directory.
- 10 hours. Upgrade path for ldap intgration (auth and groups)
- 10 hours. I18n and Coder run through

Documentation and User Interface. A priority because most issue queue traffic is usability user documentation related. I've had 7 different people offer to do the documentation, each of which I took the time to explain what was needed to. None of them followed through. This part I will likely hire out to one of the UI specialists I work with.

Complete Simpletest Coverage. This is a must for any module, but LDAP in particular. The history of the ldap module is one thing breaking another and continual beta releases. Simpletest coverage limits this breakage and speeds up development of new features because testing is automated. The remaining work for test coverage are recent features to authentication and authorization and the ldap query and feeds modules.

Basic Data Integration. I think LDAP Query that slerby did and ldap feeds can power any data integration going from ldap into drupal. The query builder can generate the data. The ldap feeds fetcher and parser can get it into feeds importer format. And existing feeds taxonomy, node, user, etc processors can do the drupal integration. Aside from getting simpletests for these two modules, this would require some recipes and Features/Exportables. I think this is the best approach for 7.1. More user friendly and use case specific modules can be built on top of this architecture or separately for LDAP 7.2.

Support for Nested Groups. This is a common use case. I need it for Active Directory and can articulate what a nested group means in Active Directory.

Upgrate Path for LDAP Integratation authentication and groups modules. I think this would be fairly easy to do as a separate module. The configuration and user data migration would be the main task. Warnings about what was lost in the upgrade would be required also.

I18n and coder run through. Just good practice.

I fixed all the ldap query issues and added scope to the ldap server query parameters. This means LDAP views can add scope to its settings. LDAP feeds can now leverage ldap_query. As I mentioned in #19, I'm working toward ldap_query, ldap_feeds, and ldap_veiws as the first ldap data foundation modules. User profile, user synch, provision etc. can build off these or not, but won't be in 7.x-1.0.

I fixed/improved the ldap feeds module in a number of ways. This is all in head of 7.x-1.x and the best documentation is in the readme.txt

  • FeedsLdapQueryFetcher uses ldap_query queries instead of own query configuration.
  • FeedsLdapEntryParser works with both FeedsLdapQueryFetcher and FeedsDrupalUserLdapEntryFetcher now. It was broken.
  • User interface is clearer and mapping examples better. Still lacks good documentation.
  • Updated the readme.
  • Simplified configuration options
  • Still alot I'd like to do, there is a todo.txt file, but feature requests in the issue queue are a better way to go.

This is part of the push to get ldap_query, ldap_feeds, and ldap_views into the 7.x-1.x. These 3 modules should cover alot of the ldap data use cases.

I'm guessing ldap_views needs some tweaking to work with recent changes in ldap_query.

StatusFileSize
new24.26 KB
new16.63 KB

Hi, John:

First, sorry for not responding earlier. I've been working on other modules and I had this unatended... #1202744: LDAP: Integration with views been closed I hope this is the correct place to reply.

For our client we have implement ldap_profile and ldap_provision for profile2, so I've renamed them to ldap_profile2 and ldap_provision2. They haven been only prooved with Active Directory but they'd work with other LDAP flavours too. This modules have TODO tasks (like documentation, simpletests, more proves....) so any help (not from you John, from any other) would be appreciated. Multivalued attributes are not supported and not dates too (because of their special format on AD).

CAVEAT: This ldap_provision2 is a little different from ldap_profile. Like the original profiles are created/updated when an user logins, but now the fields based on ldap attributes are created/updated when the profile is being viewed by any user, so the displayed data are always taken from ldap. This could create a growing network traffic in some installations, so be careful with it. Maybe a boolean configuration parameter could be created to control this behavior. Ideas are welcome.

Maybe this new modules could be aggregated to 7.x-2.x branch (though they work for me with 7.x-1.x-dev) if there's some interest on them.

Thanks slerby. I've given you commit rights to the project for patches to ldap_views. I appreciate you keeping an eye on patches/bugs for it.

As far as ldap provision and ldap profile go, I don't use them so I can't really have them in this project unless there is some commitment to maintain them or at least write simpletests for them so we can make sure patches don't break them. The various drupal 7 ldap provision and ldap profile patches/modules are a great start and much appreciated. Without more commitment, the issue queue for them will look like the old ldap integration issue queue, a lot of people asking which set of patches to use with which ldap_integration version.

I understand/agree it.

Thanks John.

Did a beta 5 release. Release contains a number of bug fixes, see changelog.txt. LDAP Feeds, LDAP Query, and LDAP Views are all in much better shape.

I was at a talk on shib and ldap for drupal yesterday. Afterwards we came up with some good ideas on how to implement nested groups as well as solve the common issue of supporting different ldap implementations.

Here is the approach I'm working with. It basically follows the feeds and views pattern where a hook is used to register an ldap type and its implemented in a class inheriting from a base class.

- add a hook_ldap_server_type(). Implement some types in ldap_servers module:

/**
* Implements hook_ldap_server_type().
*/
function ldap_servers_ldap_servers_type() {
  $path = drupal_get_path('module', 'ldap_servers') . '/ldap_types';
  $types['default'] =  array(
    'class' => t('LdapTypeDefault'),
    'directory_path' => $path,
  );
  $types['ad'] =  array(
    'class' => t('LdapTypeActiveDirectory'),
    'directory_path' => $path,
  );
  $types['novell_edir'] =  array(
    'class' => t('LdapTypeNovell'),
    'directory_path' => $path,
  );
  $types['openldap'] =  array(
    'class' => t('LdapTypeOpenLdap'),
    'directory_path' => $path,
  );
  return $types;
}

Then each ldap implementation specific properties and methods would be stored here.

class LdapTypeActiveDirectory extends LdapTypeAbstract {
  public $name = 'Active Directory LDAP';
  public $typeId = 'ActiveDirectory';
  public $description = 'Microsoft Active Directory';
  public $port = 389;
  public $tls = 1;
  public $encrypted = 0;
  public $user_attr = 'sAMAccountName';
  public $mail_attr = 'mail';
  public $supportsNestGroups = FALSE;
  // other ldap implementation specific properties and their default values
  public function getNestedGroupMemberships($user_ldap_entry, $nested = FALSE) {
    if (!$this->supportsNestedGroups) {
      return FALSE;
    }
    // code for nested membership would go here
  }
  // other ldap implementation specific methods
}

This would allow accommodation of specific ldaps types for nested groups and other implementation specific structures.

It would also allow for custom modules to further extend implementations. For example illinois__ad_ldap module could provide its own class to override nested groups.

These implementation classes could also help cut down on the complexity of the user interface by negating/disabling options that aren't viable in a given ldap implementation.

Organization specific implementations such as illinois_ad_ldap could negate options that fit into the Active Directory, but conflict with organizational policies.

this is in head.

I moved ldap profile from 7.x-2.x to 7.x-1.x. cmurph has been making progress on it and I wanted to make sure it was in the main branch since the 2.x one isn't being maintained. When cmurph has all his uncommitted stuff in 1.x, we can empty out the 2.x branch.

Version:7.x-1.x-dev» 7.x-1.0-beta5

My LDAP auth is working like a charm, but I researching a small issue.
If the ldap_query table is supposed to exsist, it does not.
Any insight is greatly appreciated.

Drupal 7.10 w/ldap-7.x-1.0-beta5
Version string PostgreSQL 9.1.1, compiled by Visual C++ build 1500, 64-bit

An AJAX HTTP error occurred.
HTTP Result Code: 500 Debugging information follows.
Path: /drupal710/admin/structure/views/view/ad_users_example/preview/page/ajax
StatusText: Service unavailable (with message) ResponseText:
PDOException: SQLSTATE[42P01]:
Undefined table: 7
ERROR: relation "ldap_query" does not exist
LINE 3: ldap_query t_0
^: SELECT t_0.*
FROM
{Idap_query} t_0
WHERE (qid IN (:db_conditionplaceholder_0)); Array
([:db_condition_placeholder_0] => ad users )
in ctools_export_load_object()
(line 427 of C:\Apache2\htdocs\drupal710\sites\all\modules\ctools\includes\export.inc).

Best, Paul

Please start an issue labelled with category of "support". This is a completely different thread. There should be a table for ldap query. You can see what tables a module installs by looking at the modulename.install file such as ldap_query.install. In this case, the table ldap_query should exist. Uninstalling and installing ldap query should create the table, otherwise mark this as a bug.

Version:7.x-1.0-beta5» 7.x-1.x-dev

I tagged all the features I thought should be in a stable release. See:

http://drupal.org/project/issues/search/ldap?text=&assigned=&submitted=&...

May have some funding to wrap this release candidate up.

I seem to remember something somewhere about modifying/creating LDAP accounts from drupal (full integration, not just the API) would be put off until 7.x-2.x. Is this still the stance because myself and I'm sure plenty of others could really do with this feature?

Many thanks

I'm certainly not opposed to it. Anything that makes sense to be in the ldap modules could be in the 7-x.1.0 release at this point if it has decent code and test coverage. A stable 7.x-1.0 release is my highest priority with good test coverage. I may have some funding for a push toward this and I just finished a long project so have some time also. I've tagged the issues I think need to be in 1.0 as "D7 stable release blocker" in the issue queue.

Here's what it would take to get drupal to ldap provisioning in 7.x-1.0:

1. Figure out where it would go. See http://groups.drupal.org/node/167304 and http://groups.drupal.org/node/159604. I like the Feeds module architecture and an LDAP processor for it would be the most generic way to provisioning and synching to LDAP. So a feeds processor plugin in the ldap_feeds module is one possibility. An LDAP User module is another possibility: Put integration between LDAP data and Drupal User object in a single module "LDAP User." There are too many Drupal 6 and 7 modules for ldap data to drupal user data. The drawback to the feeds method is it takes an understanding of feeds to configure them. The advantage to feeds is that its fairly flexible and extensible.

2. Writing the code. There are a number of threads in the LDAP Issue queue on this so some fairly refined code is likely out there. I don't really have time for this; I'm trying to catch up on the test coverage of code that has been contributed without test coverage (profile, feeds, og integration, ldap sso) before adding functionality. The trick to making this module maintainable is good regression testing so we don't end up with the way ldap integration was for drupal 6; an issue queue full of bugs that test coverage would show and full of patches. So the code should have some test coverage.

I am happy to help move this forward in anyway I can. But someone else would need to fund, find funding, or follow through on the code, testing, and issue queue side of it. I am willing to help mentor anyone in this also.

May have some funding to wrap up the 7.x-1.0 branch. Below is the general approach I'm thinking, but the specifics may change. Definately need more outside eyes for user interface, documentation, and testing.

LDAP Organic Groups
- finish test coverage
- rework UI

LDAP SSO
- finish test coverage
- improve boot process
- implement additional NTLM features
- rename/refactor to support multiple SSO methods, but retain LDAP integration

Fix outstanding bugs

Release 7.x-1.0-beta6

Identity and Multiple LDAP Issues
- Permanent Identitfier #986806: LDAP User: Use Case: ldap attribute for deriving email or username is not unique, unalterable user attribute
- finish implemementing
- add test coverage

Fix outstanding bugs

Release 7.x-1.0-beta7

Nested Groups
Fix outstanding bugs
Release 7.x-1.0-beta8

Provisioning Improvements
- api functions, batch, feeds, manual, and push interfaces for provisioning accounts
- test coverage

Fix outstanding bugs

Release 7.x-1.0-beta9

User Interface Improvments and Test Coverage
- accessibility, I18N
- Documentation

Fix outstanding bugs

This round of funding was officially approved. Its being funded by the Oxfordshire County Council (http://www.oxfordshire.gov.uk). Many thanks to them! And also thanks to Pixo Tech http://pixotech.com/ for helping manage this phase.

The 7.x-1.x-dev branch will be rough for a couple of weeks as I work through things. The first goal is to get a beta out so those currently using the module will have something stable. In the meantime, keep using whatever you have working. I'm roughly following the timeline above.

Today I pushed out a reworking of LDAP Authorization OG with test coverage. If anyone is using this module, please give it a try. This also involved a little reworking of the user interface for ldap authorization drupal roles.

Next I'm going to push out the simpletest coverage of ldap sso amd any outstanding bugs. This will be when the next beta is available.

I committed alot of bug fixes, in preparation for a beta6. The general idea is to have a beta around while -dev is very turbulent over the next couple months. I'll give dev a couple days for people to try it out and I'm running simpletests now. Then beta6. Below is the current order. It has dates on it now that the project is funded!

LDAP Organic Groups
X finish test coverage
X rework UI
X Fix outstanding bugs, mostly.

Release 7.x-1.0-beta6

Identity and Multiple LDAP Issues
- Permanent Identitfier #986806: Use Case: ldap attribute for deriving email or username is not unique, unalterable user attribute
- finish implemementing
- add test coverage

Release 7.x-1.0-beta7. March 7.

LDAP SSO
- finish test coverage
- improve boot process
- implement additional NTLM features
- rename/refactor to support multiple SSO methods, but retain LDAP integration

Fix outstanding bugs

Release 7.x-1.0-beta8 March 15.

Nested Groups
Fix outstanding bugs
Release 7.x-1.0-beta9 April 1

Provisioning Improvements
- api functions, batch, feeds, manual, and push interfaces for provisioning accounts
- test coverage

Fix outstanding bugs

Release 7.x-1.0-beta10 May 1

User Interface Improvments and Test Coverage
- accessibility, I18N
- Documentation

Fix outstanding bugs

Release 7.x-1.0-beta11
...
7.x-1.0 Release Candidate. May 15.

Version:7.x-1.x-dev» 7.x-2.x-dev

Active development is now on 7.x-2.x-dev. 7.x-1.x will be stable over the short term (2 months) with bug fixes only. Rationale follows.

In order to best implement the permanent unique identifier (PUID) and provisioning functionality, I attached fields to the user entity instead of using the $user->data array. This allows for querying on the PUID so if a user's cname changes, the can retain their existing account. It has a number of other advantages that I'm starting to realise on the 2.0 branch:

  • better feeds integration because an ldap query can directly provision ldap identified users without needing an ldap processor.
  • interdependency of ldap modules is via user and user entity hooks rather that special ldap specific hooks and function, leading to less code and easier long term maintenance.
  • I can call the alphas alphas instead of betas

This is a big enough refactoring that I wanted to get off the 7.x-1.0 branch that many were actively using.

Here's the adjusted timeline.

Identity and Multiple LDAP Issues. Release 7.x-2.0-alpha1. March 7.
- Permanent Identitfier #986806: Use Case: ldap attribute for deriving email or username is not unique, unalterable user attribute

Nested Groups. Release 7.x-2.0-alpha2 March 15th
- nested groups implemented for generic ldap and active directory

LDAP SSO. 7.x-2.0-alpha3 March 30th
- finish test coverage
- improve boot process
- implement additional NTLM features
- rename/refactor to support multiple SSO methods, but retain LDAP integration

Provisioning Improvements: Release 7.x-2.0-alpha4 May 1
- api functions, batch, feeds, manual, and push interfaces for provisioning accounts
- test coverage

User Interface Improvments and Test Coverage: 7.x-2.0 Release Candidate. May 15.
- accessibility, I18N
- Documentation

StatusFileSize
new56.2 KB

7.2 is going well. I haven't committed the most recent changes, but wanted to share some progress. Hoping to get to a point where I can commit something and apply some patches to the 7.x-1.x version if there are any issues that need addressing.

In the 7.2 version, all the profile, synch, and provision and other mappings will be in one interface. Attached is a working image. This should help with usability. At the bottom of the form will be a legend with example attributes from the test user configured in ldap server. In the top it will say something like "LDAP Attribute" or tokens (see http://drupal.org/node/1245736). This will support user fields, properties, $user->data array, and profile2 fields.

The ldap_user module will replace ldap_provision, profile, synch etc. and simplify this functionality and move it to the drupal 7 model to support fields, feeds, exportables, and all the hooks associated with the user entity. The top rows will show data that is not configurable or configurable elsewhere, and all modules will have access to a hook "hook_ldap_user_targets_list_alter" to provide "user targets" and rows in the table.

The following fields have been added to the user entity: ldap_user_puid, ldap_user_puid_sid, ldap_user_puid_property, and ldap_user_current_dn to deal with changing cns and other identification issues.

The queries now only return the attributes needed. hook_ldap_attributes_needed_alter(&$attributes, $op, $ldap_server) allows modules to add attributes.

All in all, a lot of code is dropping out and core drupal 7 hooks are providing more functionality since moving to the user entity and fields model over the $user->data model. The user->data array always scared me since its just a serialized array shared by all modules.

Wednesday 11:45am-1:00pm Drupalcon Denver LDAP Birds of a Feather

http://denver2012.drupal.org/bof/ldap-integration-and-ldap-module-users
- answering questions and getting feedback on the module
- meeting fellow LDAP developers and module users
- getting a sense of what ldap module functionality others are using.
- look at 7.x-2.0 design decisions.

If anyone not at the conference wants to attend, they should set up a skype conference room for others to join and someone at the conference can join the skype conference.

Version:7.x-2.x-dev» 7.x-1.x-dev

I committed the code for nested groups and fixing the issues with “Strategy IIC” for authorization. It needs some feedback and testing. Its in 7.x-1.0-dev.

Here are the two issues: #1016728: LDAP Authorization: Nested group recognition for authorization in group strategy IIB and IIC and #1066608: module is not checking the OU roles object by looking for a member that is the DN

It fails the unit test for adding authorizations on logon, but this may simply be because of some renaming within the tests. The authorization test form is better for checking desired behavior for nested groups and option IIC.

I still haven’t set up a test environment for IIC either, so the automated tests on the mock server are driving the code.

I committed ldap pagination functionality to the ldap_servers module. It has limited usefulness at this point unless you are using PHP 5.4 and have custom code calling ldap query or ldap server methods. A more than full description of limitiations and use cases is in the issue summary of #1446758: LDAP *: LDAP Query Pagination Limits, Max Counts, Active Directory, Page Limits.

It will be more meaningful when provisioning and synching are implemented in the 7.x-2.0 branch and it helps solve the 1000 or what have you query limit in certain ldaps such as Active Directory.

StatusFileSize
new77.66 KB
new62.47 KB
new74.86 KB

Making progress on ldap_user module in the 7.x-2.0 branch the replacement to ldap synch, ldap provision, ldap profile, etc. Its a generic synch/provision tool with lots of hooks and can be configured for both directions (drupal to ldap and ldap to drupal). The 7.2 branch is not functional now. It also has a rest webservice in it for some push use cases. I haven't started the batch process part yet where it checks N entries every cron (the pull use case).

Attached are some UI images to illustrate where this is going.

Thanks for all the updates. There aren't a lot of comments but yours but the frequent posts help us know where things are.

I'm excited about the provisioning work being done as we'll be needing it soon. Keep up the good work!

Hi,

We started to use the 7.x-1.x at our office and it works great.

Thanks you very much for your work. Really exciting for testing the 7.x-2.x version !

It would be nice to have a stable release to provide site builders more certainty that the module will get an SA for any security issues.

As of this post, there are 2 critical bugs in the queue for 7.x, and only 1 for the 7.x-1.x branch.

It seems you're actively using the D7 stable release blocker to help others identify issues that are blocking a stable release. Currently there are three issues with that tag for 7.x-1.x.

Thanks for all the great work, John.

Developement Update.

Another project and server migration grabbed my attention the last couple weeks. I still have the May 15 deadline for the 7.2 version. The 7.1 version is just bugs fixes and something for current implementers to use.

So for the next couple weeks, the plan is:

- keep applying patches to 7.x-1.x branch. Finish the 7.x-2.0 branch. It needs permanent uid and ldap_user module work primarily and a refactoring of the simpletests to use ldiffs for the fake data.

When picking a branch to use,

If you are using 7.x-1 branch in production, stick with what is working for you. If you are doing a new install, use 7.x-1.x-dev report any bugs and be careful applying updates. Patches will be accepted to 7.x-1, but its not worth alot of effort because 7.x-2 will have an upgrade path from 7.x-1. 7.x-2.0-dev will not have an upgrade path to 7.x-2.

If you are using the 7.x-2.0 branch, you should just be trying to help out with development. Your help will be more useful after ldap_user module if farther along, but feedback on functionality, design decisions, and configuration outside ldap_user, etc is useful.

Reminder about Using LDAP Authentication

Also keep in mind that LDAP Authentication has been decoupled from other LDAP package functionality in the 7.x version. From a security perspective, its much better to use a single sign on provider such as CAS, Shib, LDAP SSO than LDAP Authentication. This doesn't mean we aren't trying to make ldap authentication as secure as possible, it just means its best to have as few web applications as possible where people are entering their credentials.

Current Timeline.

Release 7.x-2.0-alpha1. May 15.
Most everything is done in the 2.0 branch exept LDAP User and Permanent User IDs.
- Permanent Identitfier #986806: Use Case: ldap attribute for deriving email or username is not unique, unalterable user attribute
- nested groups implemented for generic ldap and active directory
- api functions, batch, feeds, manual, and push interfaces for provisioning accounts
- ldap user module to replace ldap synch, profile, provision
- dealing with binary fields
- test coverage driven by ldap_diff files and live pixotech ldap servers
- Documentation

StatusFileSize
new361.24 KB

Attached is the current LDAP User module (7.x-2.0-dev) config screenshot. The configuration user interface is close to complete, but all the features configurable in it are not implemented. For those of you who used ldap synch, provision, profile, etc in Drupal 6, feedback on how well this covers your use cases would be appreciated.

The mapping data at the bottom is provided by other modules such as ldap_server via a hook named hook_ldap_user_targets_list($available_user_targets, $ldap_server) which is called for each enabled ldap server.

Issue summary:View changes

redid summary

On the 7.x-1.x-dev branch I committed a number of bug fixes, simpletest fixes, and support for organic groups 7.x-2.x in ldap_authorization_og. I'd like to get some feedback on the current LDAP 7.x-1.x-dev and get another beta out quickly. If anyone has the time to install it and test the basic functionality out, please do so; otherwise we can all just test the -beta together.

Hi john..

is 7.x-2.0-alpha1. releasing tomorrow..? (as per your #46 comment).

I am currently looking for provisioning and data module for drupal 7. is there any dev code that I can test..?

No. The 7.x-2.0 branch is going to take a little longer. I'm pushing some of the critical 2.0 functionality (puid, ldap entry conflict code, fields attached to user instead of $user->data array) back to 1.0 for a beta so these useful features are available and implementers adopting 1.0 have a simple migration path. I have to go off to my daughters graduation next week and want to get that done before I take off thursday.

The 7.x-2.0 alpha code will hopefully come by the end of the month. 7.x-2.x-dev may be worth taking a look at. It depends if the data and provisioning is going toward drupal (may be implemented) or toward ldap (not implemented). It would be great to get some eyes on that code if you are synching toward drupal. The UI is implemented, so at least you can see what its designed to do.

Also feeds may meet your use case if you are familiar with feeds configuration.

@john, Thanks for the info.

I tried 7.x-2.x-dev. It has provisioning , but accounts are created in drupal from LDAP . I want to create accounts in LDAP and as well as in drupal. using drupal user registration. just like ldap_provisioning module for D6.

so is there any idea of implementing this..? or any alternative for this..?

The design is to have ldap_user in 7.x-2.x do all the provisioning work in both directions. In some cases it will leverage the UI of other modules such as ldap_authentication to configure how the provisioning occurs. For most fields, it will use the ldap_user module mapping user interface. The general idea is to consolidate ldap profile, sycnh, provision, etc into one module and a simplified UI since they are just pushing fields/attributes and drupal users/ldap entries in two directions.

The next step in the 2.0 and 1.0 branch of ldap user is to get the unique identifier and account name and email conflict working. After that is provisioning to drupal (ldap profile) and then provisioning to ldap. The provisioning to ldap is not a use case I need or have funding for so any help in this area is greatly appreciated.

Version:7.x-1.x-dev» 7.x-2.x-dev
StatusFileSize
new859 bytes

The provisioning to ldap is not a use case I need or have funding for so any help in this area is greatly appreciated.

This is something that our business requires and I will spend some development time on it. However, I am new to GIT and developing on drupal.org. I'm going through the GIT tutorials and learning this code base simultaneously. Found one bug so far in ldap authentication.

In ldap_authentication.inc around line 450 call to 'provisionDrupalAccount' passes arguments in the wrong order. This will prevent a new ldap user from being provisioned in Drupal. I made a patch (attached), but I don't think i'm privileged to commit changes to GIT.drupal.org.

Apologies for the 7.x-1.x-beta10. It was quite buggy. Appreciate all the patches while I was off to my daughter's graduation for the week.

Current 7.x-1.x-dev has a number of these patches in addition to some fixes for case sensitivity. The simpletests are all working again also so regression testing should be easier. Features support is broken for ldap_authorization; it was breaking saving of ldap authorization configuration so I commented it out for the time being.

While case sensitivity and escaping is clearer in the code, it needs to be added to the user interface and additional simpletests added for it.

Please try out 7.x-1.x-dev, paying particular attention to ldap authorization mapping and drupal role/og group grants and revokes. I'd like to get this out as a beta11, since beta10 was buggy.

Here are additional details.

#1066608: module is not checking the OU roles object by looking for a member that is the DN Committed patch in comment19
#1601270: LDAP Authorization: exportables functionality broken Features/exportables is now broken for ldap authorization
#1589148: LDAP Authentication : login impossible with bind_method = 4 Login works with bind method option #4.
#1588068: LDAP Authorization: group memberships removed on login OG Group memeberships were being removed on logon. committed patch in comment #3
#1559388: LDAP Authorization Organic Groups: OG 7.x-2.x Support OG Groups authorization bug for getting current membership fixed. committed patch in #8
OG groups and all other simpletests fix

#1592888: LDAP Authorization: Username case sensitivity different for authentication and authorization with groups as entries setting,#1272190: LDAP *: Case Sensitivity Issues, Run through of case sensitivity and escaping issues. See also readme.developer.txt
#1588888: Can't add new lines to "Mapping of LDAP to drupal role (one per line)" and #1588854: LDAP Authorization: Roles not updated, authorization test fails,duplicate entries in ldap_authorization bug with saving configuration creating new table rows instead of updating. Fixed this but broke features support.

Hi John,

I had a bit of a query about the way the RESTful provisioning will theoretically work. I had always been working on the assumption that to handle renames it would require the PUID, but the mockup implies it would want the old? drupal username. What's the intention?

No particular intention. Whatever meets people's use cases. The old drupal username will only function if puid is in place, and I imaging any sort of provisioning would want to provide the current/new drupal username or the puid itself.

In response to comment #51: As an interim solution until 7.x-2.x alpha is released, I created a custom module to capture the drupal account information using Drupal's hook_user_presave, hook_user_insert, hook_user_update, hook_user_delete and then writing the information to the ldap server using PHP's ldap_mod_add, ldap_mod_mod, ldap_mod_del, respectively. It's not ideal, but will work for now.

@sassafrass, if possible can u share the module..?

There are still some issues on the ldap 7.x-1.x branch such as features support and some bugs. The 7.x-1.x branch has been turbulent enough so I'm back on the 7.x-2.x for development. The 7.x-1.x branch will just be bug fixes at this point. There will be an upgrade path from 7.x-1.x to 7.x-2.x release candidates. The will not be an upgrade path from 7.x-1.x to 7.x-2.x-dev and 7.x-2.x-dev betas.

In the 2.0 branch, the primary work is provisioning, unique ids, test coverage, and documentation. Provisioning in the 2.0 branch is all in the ldap_user module and its a consolidation of ldap provision, synch, profile, etc. modules. In the ldap modules, provisioning means creation of drupal users from ldap data and ldap users from drupal users and synching of user properties (mail, name, pwd) with ldap attributes. LDAP authentication already provisions drupal users from ldap entries and syncs mail and username attributes; ldap user will extend that to more extensible provisioning and allow configuration of what is synched and in which direction.

I'm starting a new thread for those who want to actively follow provisioning and give input on it #1622942: LDAP User: Ldap Provisioning in LDAP 7.x-2.x Branch General Discussion thread.

There have been a number of bug fixes since beta10 on May 14th, so I'm pushing out a beta 11.

There are still some issues that I feel are either not resolved or not need confirmation. If anyone can confirm or deny these bugs, that would be great. My current focus is on the 2.x branch, but want to get the 1.x branch bug free also. I'm working on setting up public reference ldaps for easier testing and debugging.

Strategy IIC of Authorization. Possibly fixed.

#1621710: LDAP Server: Test Functions and other token parsing functions don't deal with failing binary fields gracefully
#1066608: module is not checking the OU roles object by looking for a member that is the DN

Case sensitivity issues

#1592888: LDAP Authorization: Username case sensitivity different for authentication and authorization with groups as entries setting

Other

#1590170: ldap_authorization_og
#1588068: LDAP Authorization: group memberships removed on login
#1559388: LDAP Authorization Organic Groups: OG 7.x-2.x Support
#1621710: LDAP Server: Test Functions and other token parsing functions don't deal with failing binary fields gracefully

The provisioning aspect of the 2.0 branch is coming along well enough that I made a list of 7.x-2.0 release blockers (http://drupal.org/project/issues/search/ldap?text=&assigned=&submitted=&...) . Any dialog/feedback on these is appreciate. These issues are mostly feature requests since the 7.x-2.0 branch hasn't been stable enough for any real testing.

Likewise, I did the 7.x-1.x release blockers list (http://drupal.org/project/issues/search/ldap?text=&assigned=&submitted=&...)

Had a good couple weeks on ldap 7.x-2.x:
- got ldap_authorization, ldap_authentication working with new ldap_user module
- got all the simpletests back in working order (except ldap_authorization_og and ldap_user user interface)
- finished UI for ldap user mapping.

This is all checked in and in 7.x-2.x-dev. Still a little rough for anything but testing, but feedback and testing is appreciated.

Now that the refactoring for ldap_user is done, I'm moving onto the 7.x-2.x release blockers:

http://drupal.org/project/issues/search/ldap?text=&assigned=&submitted=&...

There are some additional developers working on LDAP 7.x-2.x-dev in the next two or three weeks. Expect turbulence and please respond to any issues relevant to your use cases in a timely manner. Most of the work will be centered around ldap user and ldap authorization og in the 7.x-2.x branch. Remember to tag issues as release blockers with "7.x-2.0 release blocker". See http://drupal.org/project/issues/search/ldap?text=&assigned=&submitted=&...

I got some questions last week about whether to use the 7.x-1.x or 7.x-2.x branch at this point. I don't have any answers on this. The 7.x-2.x branch is likely to be refined sooner than 7.x-1.x, but rough in the meantime. I would say 7.x-1.x if it works for you now and you aren't using provisioning to LDAP. We are applying patches to both when appropriate.

StatusFileSize
new66.46 KB
new179.62 KB
new83.86 KB

I committed alot of refactoring in the 7.x-2.0 branch. Its unlikely that this branch will be very functional at this point until I finish this up.

The basic changes are related to ldap group entries.

- moving group configuration specific to an ldap implementation into ldapServer class and out of other modules so it can be leveraged by more modules.
- moving related methods into ldapServer class
- making authorization strategy IIC work and more useable

Attached are some screenshots to give a sense of things. The update hook doesn't move the conf data, just adjusts the db fields.

StatusFileSize
new431.19 KB

Moving some of the ldap group related fields into ldap server and out of ldap_authorization and ldap_groups is working well. The most recent changes are committed and attached is a screenshot of the UI.

LDAP Servers module for 7.x-2.x is more or less where I want it to be except for small UI tweaks and whatever bug fixes come along.
ldap user, ldap authentication, and ldap authorization need to be adjusted for these changes, so they are broken or unstable. I'll be moving onto these next.

Testing and Feedback

If you want to do any testing or give feedback: install it, add a server, and look at the server test page. If you already have 7.x-2.x-dev installed, you will need to run update.php.

The main feedback I'm looking for is:

  • if the group functions tests on the server test page work in your ldap. the test page tests these functions: groupIsMember, groupAddGroup, groupRemoveGroup, groupAddMember, groupRemoveMember, groupAllMembers, groupMembershipsFromUser
  • form usability and wording feedback is always useful

The main changes to LDAP Servers module were:

  • -Moving of the group related fields from ldap_authorization to ldap_servers so that could be used across more modules.
  • Added hooks hook_ldap_entry_pre_provision_alter and hook_ldap_entry_post_provision which should be called whenever ldap entries (group, user, or otherwise) are created, modified, or deleted.
  • Shifted simpletest test data to be ldap implementation agnostic. Its stored in csv and the fake ldap structure for the simpletests is generated based on the particular ldap schema.
  • moved group related functions into LdapServer class: groupIsMember, groupAddGroup, groupRemoveGroup, groupAddMember, groupRemoveMember, groupAllMembers, groupMembershipsFromUser, groupMembershipsFromEntryResursive
  • added tests for these in ldap admin/config/people/ldap/servers/test/...
  • addes simpletests for some of these functions
  • fixed a bug in the ldap tokens
  • fixed a bug in ldapServer::dnExists

I'll check out the tests and get you more info, but quick and dirty:

1. The update didn't work; had to uninstall and reenable, groups stuff wouldn't save even after update.php. not a huge deal.
2. [eta: user error ;) ]

Aaaand ... so far all works for me.

Made good progress on the 7.x-2.x branch last week. Its best to start with a clean install as I'm not sure if everything is covered in update.php

LDAP Server, LDAP User, and LDAP Authentication are ready for testing and feedback. Please make sure you do a clean install of the LDAP project before testing and submitting bugs.

LDAP Server, LDAP User, and LDAP Authentication have been switched over to the new simpletests and adjusted for changes in LDAP Server. All their simpletests are working and additional simpletests will be added as bugs show up. The two unimplemented features are (1) cleanup of accounts that no longer have corresponding ldap entries and (2) "Email Behavior" and "Email Update" features still need test coverage and likely belong in LDAP User module rather than authentication.

LDAP Authorization and LDAP Groups are next on my radar for 7.x-2.x. LDAP Authorization primarily needs adjustments for the new group logic in ldap servers and adjustment of simpletests for current framework. I'm hoping this goes quickly. LDAP Groups just needs a little logic in it and some simpletest coverage; LDAP Groups is the counterpart of LDAP Authorization for provisioning groups and group memberships from Drupal to LDAP.

Great. I have a major update to do on our Intranet this/next week. After that, I'll reset my TEST server to a copy of our current LIVE and then upgrade to the latest LDAP to test.

Made great progress on 7.x-2.x-dev this week. I believe its preferred over the 7.x-1.x branch at this point. This post is a summary of the latest commits to 7.x-2.x-dev and my proposed path to a release candidate.

LDAP Authorization Drupal Roles simpletests are working. Its ready for testing and feedback. All the other simpletests are working also.

The latest commit includes the following:

  • alot of coder module changes (spacing etc)
  • dead code pruning
  • commenting out of ldap user webservice code
  • fix for ldap authentication excludeIfNoAuthorizations functionality
  • some hook_help additions
  • fixes for ldap authorization and ldap authentication simpletests
  • fix in ldap user/ldap authorization where ldap user was breaking storage of $user->data['ldap_authorization'] data
  • changes to make storage of ldap authorization authorization ids case insensitive, but actual roles or og groups mixed case
  • misc fixes to "Outlier" LDAP Modules. See below.
  • dependency on PEAR for simpletests removed

LDAP 7.x-2.x Remaining Issues

I've marked issues I don't expect to followup on with "postponed" status. Maybe they will get taken care of in 8.x version. I've assigned the issues I want to get finished before 7.x-2.x Release Candidate to myself, so the list is: http://drupal.org/project/issues/search/ldap?text=&assigned=johnbarclay&...
I'm receptive to patches and nudges, but want to get LDAP stable. Below is the same list broken down by module.

7.2 Branch "Outlier" LDAP Modules

Went through LDAP Views, LDAP Feeds, LDAP SSO, and LDAP Query; These are the modules that don't have test coverage and I'm not actively using or developing so I call them "outliers". I did the coder review, made sure the UIs worked, and basic visual checkover. Here's where I think each is at:

  • LDAP Query. Seems pretty simple and works. Could use some extra code to deal with pagination available in PHP 5.4.
  • LDAP SSO. Users of this are pretty quiet in general. There are some open issues on it and it would be great if people would step up and document their SSO setup (webserver, webserver extensions, how LDAP SSO is configured, and what "Authentication Mechanism" they are using. Including if its working for them.)
  • LDAP Feeds. Feeds has changed some since it was written. I fixed some obvious bugs and was able to use both the "Drupal User LDAP Entry Fetcher" and "LDAP Query Fetcher" to and the "LDAP Entry Parser" to import some simple nodes. I didn't test very much. The code to give a hint at which mapping fields are available (see ldap_feeds_form_feeds_ui_mapping_form_alter()) is broken now; perhaps the feeds form has changed. This could also use a step by step walkthrough in the documentation.
  • LDAP Views. Didn't test.
  • LDAP Authorization OG. Haven't gotten to yet.

I finished the initial 7.x-1.x-dev to 7.x-2.x-dev update code to encourage more testing of the 7.x-2.x branch. Its in 7.x-2.x-dev. See #1740152: LDAP_*: Upgrade script to 7.x-1.0 to 7.x-2.0.

I released a 7.x-2.0-beta1 this morning. Please actively report bugs in the 7.x-2.0 branch. I'm holding off on the binary attributes and the need to provision ldap groups for the sake of working toward a release candidate. I'm receptive to patches for these, but want to focus on bug fixes and documentation at this point.

Please tag bugs as 7.x-2.0-dev so they are easily searchable at: http://drupal.org/project/issues/ldap?text=&status=Open&priorities=All&c...

I'm still looking for someone to host the reference ldaps for this project. These are 2 or 3 read only ldaps (ad.ldap.yourorg, openldap.ldap.yourorg) that would be populated with the simpletest dataset configured with active directory, openldap, etc. standard configurations and used for ldap module users to test their configurations against a known ldap. The same ldaps could potentially help with other projects such as wordpress, moodle, etc.

LDAP Authorization in 7.x-2.0

I ended up rewriting alot of the code for ldap_authorization to deal with a number of issues. The gist of the changes are to allow a single query for existing og groups, roles, etc #1777088: LDAP Authorization: dangerous iterations using og_load_multiple & og_get_all_group(). I also added a hook to allow modules to intervene after the og groups, roles that will be assigned to the user are populated. I also removed the need for querying "all available" ids #1841396: LDAP Authorization: Consumer ids generation for OG consumer which is a problem for large og sites. The new code queries ogs once with field entity query and loads once with entity_load()

I'm working on getting the test coverage for og and og2 working now.

I'm looking for og 7.x-2.0 users to help test a sandbox version of this as I don't want to dump such changes without some testing, since ldap authorization for drupal roles is working.

Happy to help with the OG2 stuff, I'm working on a site that this would be perfect for.

great. thanks. I started a separate thread for that #1845358: LDAP Authorization. General cleanup for 7.x-2.0 and I'll get it up in the sandbox as soon as its functional.

7.x-2.0-beta2 is ready. It is bug fixes, excluding ldap authorization which will be tested separately before reintegrating into the ldap 7.x-2.0 betas. /update.php does NOT need to be run for it.

See [#1846478]

Any testing is greatly appreciated. Those not using ldap authorization are ideal testers, as those using ldap authorization will be more useful when its ready to intgrate into the beta process.

I put the new ldap authorization code in 7.x-2.x-dev. I didn't want to fork, but don't recommend using this -dev unless you are wanting to help test and debug any og authorization functionality. It has better test coverage, but a significant amount of code changes.

Requires

  • update.php run.
  • requires editing and saving ldap authorization and ldap server configurations. this will store mappings in normalized form. I'll add update code for this later.

LDAP Servers Changes

  • - made db field names lowercase to deal with different behavior of db storage and ctools load
  • - some fixes for ctools

LDAP Authorization Changes

  • - more code documentation
  • - made db field names lowercase to deal with different behavior of db storage and ctools load
  • - added ui tests. this was in a previous commit.
  • - moved all but og 7.x-1.5 simpletests into new test format.
  • - reworking of ldap authorization og
    • -- more efficient querying and loading of groups
    • -- additional storage of mappings so user's original input is stored as well as normalized mapping.
    • -- stubbed out creation of og groups as needed. please finish if needed.
    • -- has not been tested against og 7.x-1.5 yet.

I committed a couple example Drupal Features. One for general Active Directory authentication, authorization, and provisioning of Drupal users. Another for provisioning users from Drupal to LDAP.

See http://drupalcode.org/project/ldap.git/tree/530c215f61285cd3798a9ab85541...

The general idea is to have these for documentation purposes. At some point down the line, these Feature examples, the drupal.org documentation pages, the simpletests, and user interface examples will be aligned with an actual reference LDAP. For now, I'm just trying to align as much as possible.

As always anyone interested in doing or funding documentation on this project is welcome. I'll be trying to strike a balance between documentation and bug fixes for the 7.x-2.0 branch.

Version:7.x-2.x-dev» 7.x-2.0-beta3
Category:task» bug

I can't mapping to OG. Name of group isn't shown in test page, only gid-rid.

Please start an issue for it then. With more details. This is issue is not for bugs or support.

Version:7.x-2.0-beta3» 7.x-2.x-dev
Category:bug» task

I have all my dev code pushed out and all the simpletests working again. The commit was: http://drupalcode.org/project/ldap.git/commitdiff/7c7e62c9b05f2c50fd653f...

I'll be going through the bug reports and seeing if they are affected by the patch and adding simpletests where appropriate. My goal is still to produce a bug free release candidate; then proceed to documentation and usability concerns.

Since the simpletests are passing now, it will also be easier to apply some of the contributed patches.

Moved to Issue Queue

Interesting - it upgraded seamlessly for me on all my dev sites, but I've been following along with the dev releases and did each update as it came out, so maybe that's why?

This thread is not for bugs, feature requests, etc. Just general updates.

My next steps are:
- clean up the issue queue for 7.x-2.x-dev fixing any simple to fix bugs along the way. This is what I've been up to thus far this week.
- release a 7.x-2.0-beta4. This is simply to avoid getting bug reports against 7.x-2.0-beta3 and encourage testing.
- get at remaining bugs
- after a release candidate is available, get back to work on the upgrade script from 7.x-1.0 to 7.x-2.0.

John can you give a general yea/nay on whether OG authorization code is in the latest dev and (at least) as functional as it currently is in 7.x-1.x? I know there were a number of issues and this is the main thing making me worried about making the jump to 2.x, since OG mapping (just based on attributes of a user entry, in our case) is one of our key use cases.

Reply to #22: slerby, any chance you could move the ldap profile module into the 7.x-2.x branch. This would be immensely useful. I really need a way to map our Active Directory user data with our Profile2 user data.

Thanks.

I believe og 2.0 support works for 7.x-2.0-dev. The simpletests are broken on my version, but worked in the past. The simpletests cover most of the use cases: http://drupalcode.org/project/ldap.git/blob/refs/heads/7.x-2.x:/ldap_aut...

I haven't converted the simpletests for OG 1.5 in the 7.x-2.x branch yet, but its a high priority as a have a little funding to get OG 1.5 working with 7.x-2.0-dev .

I Committed patch to ldap authentication that refactored longest function to 7.x-2.x-dev. All simpletests are now passing. I picked off some simple issues to clean the issue queue up, and am heading down the following path:

authentication:

og authorization:

...lower priorities for me, please hop on any of these if you can.

configuration and state issues:

Ldap user issues:

I believe all the authentication issues in the last comment are resolved. Testing would be greatly appreciated, especially from ldap_sso users and those using multiple ldap servers.

Made some progress on misc bugs last week: http://drupal.org/node/806060/commits and all the simpletests are working. My main focus is still authorization and og authorization at this point.

Any patches on these would definately be appreciated. Simpletest coverage also would be great. They are all likely closely tied together.

Anyone working with an ldap that allows anonymous dinding should be aware of #1920094: ldap authentication: allow login with null byte - null byte attack and either hand apply related commits or update to the most current 7.x-1.x-dev or 7.x-2.x-dev versions of ldap.

I added a "Letter to LDAP Administrator" to the documentation. http://drupal.org/node/1925794

Its for people new to the module and/or LDAP to get the initial configuration questions to the LDAP Admins.

I've had several requests for such a template over the years and finally wrote one. Please take a look at it and revise it as appropriate; since its in the documentation queue anyone can edit it.

subscribing

You don't have to do that anymore. There's a green "follow" button at the top of the page that subscribes you to the issue without adding clutter to the conversation. Please use that instead. Thanks.

In working through some ldap authorization issues, I added an "execute" option in ldap authorization test form (admin/config/people/ldap/authorization/test/drupal_role, admin/config/people/ldap/authorization/test/og_group). This is largely for debugging and testing but also illustrates ldap authorization behavior. I've made some progress on authorization for og. #1825764: LDAP Authorization OG: Undefined property: stdClass::$type in og2Groups() when group entity doesn't have bundles, #1907782: LDAP Authorization 7.x-2.x and Organic Groups 7.x-1.5: Group Granting and Revoking but am waiting for more test coverage of authorization to put out a beta4.

Hello,

I don't konw if this is the good place, but...
I used the 7.1 version. And I don't found how I can derive drupal roles from attributes (II.B) with the 7.2-dev version.
I check "A user LDAP attribute such as memberOf exists...", and after, where I can fill my attributes?

Please... :)

No this is the wrong spot. Please read the issue summary.

Since comment #89, I've gotten through og 1.5 for authorization. Alot of the improvements may carry over to og 2.0, but og 2.0 is quite different than og 1.5.

Besides some small bugs, my focus will be testing og 2.0 and working through og 2 and authorization/group/role issues in general.
#1880118: LDAP User: with OG 7.2 Server Crashes after successful Ldap to Drupal sync with Drupal Account Provisioning Options
#1907782: LDAP Authorization 7.x-2.x and Organic Groups 7.x-1.5: Group Granting and Revoking
#1879168: Ldap Authorization: Derive from Group-dn does not work
#1808314: Ldap authorization: mapping IIB is not working in last dev version

Made good progress on LDAP Authorization OG for OG 7.x-2.0 and 7.x-1.5 over the last couple weeks. Here are my current priorities:

http://drupal.org/project/issues/ldap?order=priority&sort=desc&text=&sta...

First priority for my work are 7.x-2.x-dev Bugs with priority of "Major". Of course other issues can move faster with patches or funding; especially patches that don't break simpletests or, even better, include their own simpletest coverate.

Generally Feeds, Views, and SSO are lower priorities because they have lower participation levels and test coverage. LDAP SSO really needs some test coverage to make any progress on stability for it.

LDAP Servers, LDAP Authentication, LDAP User, and LDAP Authorization are higher priorities.

Help is definately needed as far as testing and writing patches.

Focused on uninstall and configuration (Features support, serialization issues, etc) lately. The big issues before the next beta are: http://drupal.org/project/issues/ldap?order=sid&sort=desc&text=&status=O...

Please actively test the most recent 7.x-2.x-dev if you have had configuration or features issues. there is an update that needs to be performed also.

Category:task» feature

Are there still any plans to allow LDAP user provisioning on e.g. cron runs? Authentication works fine, but for sites where you need to have a full list of all users available before they're logged in, the current state of the LDAP modules are insufficient. I am aware there are a number of possible workarounds for this, but a community-maintained solution would be much preferred.

No plans for #104. The closest thing thus far has been interest in provisioning via REST webservices.

Isn't #104 possible via LDAP Query + LDAP Feeds + the Feeds module? I just used this combination to do this last night and it seemed to work fine.

Can you clean up and export this as a feature and stick it in the documentation? It takes a bit for some to get their heads around feeds, but it has the potential to fill a lot of use cases. The example in 106 I think is a fairly good example.

@Kazanir...Yes, please do add this to the documentation. That would be most helpful!

7.x-2.x-dev was broken for the last couple days. #1965160: LDAP Servers: Group-Membership not derived correctly for non nested groups broke the simpletests and I didn't notice. I ended up reverting and recommitting a number of patches so the commit log is a mess. Below are the commits that were reverted and recommitted.

I have a revised patch for #1965160: LDAP Servers: Group-Membership not derived correctly for non nested groups , but have not committed it.

The drupal 8 version is coming along. Alot of the areas where drupal 8 shines such as configuration are where the LDAP module needed some help.

For anybody who is interested in today's code sprint (at Drupalcon Portland), I'm in A104 and can help point you in the right direction. I'll be working on #1740978: LDAP Authentication and LDAP User: LDAP not allowing to authenticate to multiple servers

I think its time for another beta for 7.x-2.x. There have been quite a few patches since beta5. Its not clear if people are using 7.x-2.x-dev or not from (https://drupal.org/project/usage/ldap).

- Are there any patches out there that have not been committed?
- Is anyone using the multiple servers #1740978: LDAP Authentication and LDAP User: LDAP not allowing to authenticate to multiple servers?

Are there any issues besides those in #110 that are critical to a release candidate?

I'm not using multiple servers, but I have the latest dev as of yesterday, and have tried putting it through the paces (using submodules for SSO, User, Authorization, Authentication, Query, etc.), and everything I've tested is now working beautifully!

One note (more of an overarching/long-term thing): It would make debugging and contributing a little easier if the code were run through the Coder module's review, and things like whitespace and commenting were cleaned up a bit. Just a suggestion, and I know that this would make a lot of patches currently in the queue need to be updated... but I think it would save time for future contributions :)

thanks. I started a thread for coder fixes. I also committed non minor coder fixes. My main priority is a release candidate and documentation at this point. The module is too complex not to have more step throughs for common ldap setups.

I don't know if it's release critical to the project but #2053215: LDAP Feeds: ldap_feeds does not populate sid, puid or puid_attr is a major issue for us. We're using the module on our Intranet and the Drupal users are used to build an online staff directory. For us that means that employees who have left the organization are still showing up in that directory. I've been trying to find time to revisit that and provide a patch but haven't had an opportunity yet. I'd really like to help get a fix in before the next release though. Do you have a target date you're aiming for for the next release? I'll do my best to get a patch to you before then.

Thanks lawsonk for point this out. I have a similar problem and I would also like to be able to update the "expiration date" of contract based users.

Status:Needs review» Active

S see issues regarding the upgrade path from 1.x to 2.x (#2001750: 7.x-1.x to 7.x-2.x upgrade path broken on ci database systems) . Not sure if there is a working migration path between the branches. If so, it prob. need some work and should perhaps be added in a beta/rc version.

Issue summary:View changes

removed outdated gliffy reference

I committed a number of patches as well as all those marked RTBC (there were none). Some testing is in order of 7.x-2.x-dev so I'm marking it as 7.x-2.0-beta7. I also did some issue queue cleanup. Please mark any new issues against 7.x-2.x-dev.

There are a number of patches that need review. If everyone could review 2 others' patches we could get some progress on cleaning up the queue.

Current issues:

https://drupal.org/project/issues/ldap?text=&status=Open&priorities=All&...

Thanks for all your hard work. Should #2001750: 7.x-1.x to 7.x-2.x upgrade path broken on ci database systems be on the list linked to in #118. There is currently one (or was it two) upgrade issues.

Issue summary:View changes

I assigned myself some issues that seem relatively straightforward, just to clean up the noise in the queue.