Closed Thread: List of Wants, Features, and Fringe Cases

It might be more useful to put each feature, use case, and integration case as a separate issue so we can tag issues and add "major" priority to features we want in this project and "major" priority to module integrations. We can also add a component type called "integration design" for design issues with integration.

+1 for #2, some prioritization could help.

LDAP Profile is must have. :)

I have a situation where accounts need to talk to the ldap server for authentication, but I am not the ldap admin and have no control over how the ldap is structured.
I end up getting a list of more users than I need to allow.

I need the ability to make a whitelist and or blacklist of allowed accounts based on names or other ldap settings.

I also need to add and manage users who are not in the ldap database, and so ldap authentication should exist along side drupal authentication. (I guess this means +1 for 'Promote Interoperability with other authentication/authorization modules')

Very excited to see activity on this module/API. We are looking at launching a new D7-based site in mid-late 2011 and having LDAP will be key. We could stay at D6 but we are very attracted by some of the improvements in 7.

Putting feature requests in as separate issues sounds good, but not sure I have any new ones to suggest and I don't want to contribute to issue glut :)

Right now in my shop on Drupal 6 we:

- use webserver_auth module to provide Pubcookie-obtained authentication to Drupal
- use LDAP Integration and a single privileged DSA to sync LDAP groups to Drupal roles every hour.

Many (or most?) of authentication servers/modules like Apache, Omni, PubCookie and CAS all seem to use the REMOTE_USER environment variable. I was always looking for a check box in LDAP that would simply say "Trust REMOTE_USER for authentication" and dispense with WebServer Auth (or Pubcookie module).

With respect to LDAP user and group synchronization, our cron's sync appears to sync every user and group afresh every time. This seems a bit brutal, and I would like to think that there was a less resource-intensive way to sync LDAP-->Drupal that was a bit more incremental, but I don't really know if that is realistic given that you want to interoperate with multiple LDAP technologies. I should probably just get over it :)

I am also now distressed that I see 100+ LDAP groups (many of which will never have any special permissions assigned to them) in the Permissions pane under Drupal 6 (boy does that take a long time to load!). I was going to request something like a synchronization whitelist to limit the number of groups that Drupal sees/imports, but then I started to think that this is maybe better achieved with a module like Filter Permissions (http://drupal.org/project/filter_perms).

So, I am not so concerned about using Drupal LDAP module to manage LDAP data at least at first. My priorities would be a built-in ability to select REMOTE_USER for authentication and sync of LDAP groups/memberships to Drupal roles.

You have a long list!

Jim

I went through the ldap_integration issue queue and copied/consolidated ldap groups feature requests to this issue queue with title of LDAP Authorization: ...

I then referenced the issue here in the comments of the original issue.

I added them to a wiki page in the ldap integration group also, for my own notes mostly: http://groups.drupal.org/node/105789

If anyone has some energy to do the same for ldap authentication, that would be handy.

If someone wants to start articulating use cases and functional tests in the same wiki, that would be helpful.

Subscribe - will post back after I finish my current project.

I just wrote a piece of code that could be useful for the entries management part.
The whole discussion is here: http://groups.drupal.org/node/107924.

I also want to point out that we do not just need to store users and groups on LDAP, but it could be useful to manage other types of entries, with inter-relationships etc. etc.
An example would be organizations and locations, but there are several more use cases for this.

I was at a quite good point writing a module that does that in a cck-like way, although it could be done better by extracting more information from the LDAP schema [eg. must/may fields, multivalue support, ..].

Then, with the birth of this module, I stopped development in that way to wait for the new APIs to be ready for use, in order to avoid re-thinking and re-writing again the same code, (I reduced the initial scope of the project I'm working at to just fit my very own needs at the moment, then I'll upgrade the whole stuff when new modules are ready), so a "LDAP Objects" or "LDAP Fields" module is coming soon too!

Cross posting this request (as asked) from an issue against ldap_integration

A very common way of creating a group is to use the standard ldap schema objectClass groupOfUniqueNames which has a multi-value attribute uniqueMember the syntax of which is a DN (Rather than a CN or UID type value).

It would be really useful to allow this sort of group.

Openldap defines groupOfUniqueNames and uniqueMember in core.schema.

They are discribed in RFC2256, groupOfUniqueNames in section 7.18 and uniqueMember in section 5.51.

An example LDIF fragement might resemble

dn: cn=group1,ou=groups,dc=example,dc=com
cn: group1
objectClass: groupOfUniqueNames
description: An optional description
uniqueMember: cn=user1,dc=example.com,ou=Domains,dc=example,dc=com
uniqueMember: cn=user2,dc=example.com,ou=Domains,dc=example,dc=com
uniqueMember: cn=user3,dc=example.com,ou=Domains,dc=example,dc=com

It would be a huge bonus to be able to authorise only a set of users that belonged to a particular LDAP group or (and this is the killer...) belong to a group that belongs to a group.

In an enterprise scenario, it is very likely that users will be added to a departmental group and that group will be added to an application group. This way, a new member of the department only has to be added to one group to receive all their services.

I'm keen enough about this to help make it happen if someone can help get me started on the module...

Rachel

I was unsuccessful when I tried using this module and configuring/testing an LDAP server to find a user in LDAP. Not sure why, but it seems like the result we get from our LDAP server is different from what the code expects. I had to make the following changes to ldap_servers/LdapServer.class.php:

@@ -289,7 +289,7 @@
 
     foreach ($this->basedn as $basedn) {
       if (empty($basedn)) continue;
-  
+      
       $filter = $this->user_attr .'='. $drupal_user_name;
 
       $result = $this->search($filter, $basedn);
@@ -302,7 +302,15 @@
         continue;
       }
       $match = $result[0];
-  
+      
+      $result = array(
+          'dn' =>  $match['dn'],
+          'mail' => @$match[$this->mail_attr][0],
+          'attr' => $match,
+        );
+
+      return $result;
+      /*
       // These lines serve to fix the attribute name in case a
       // naughty server (i.e.: MS Active Directory) is messing the
       // characters' case.
@@ -332,6 +340,7 @@
           return $result;
         }
       }
+      */
     }
   }
 }

refrerring to #11:

The first case is covered already in LDAP Authorization. The group within a group I think is really more about nested groups. Does user belong to Group A if they are not directly in Group A, but are in Gorup B which Group A contains. Correct me if you are thinking of something else. I added this as a feature request #1016728: LDAP Authorization: Nested group recognition for authorization in group strategy IIB and IIC so correct me on that issue request.

I need this use case myself from time to time, but so many applications do a poor job of dealing with nested groups that we keep our groups as flat as possible avoiding nesting via automated reconciliation; a real pain. Anything this module can do to avoid that sort of hack is a plus as far as I'm concerned.

There are some performance issues in recursing up through all the groups a user is a member of. I believe the way to implement this is to have an explicit list of groups to test (groupA, groupB) and an option for whether or not to recurse. I'm not sure if that what option II.C. on the ldap authorization configuration options is meant for or if we should implement it as II.D.?

the end of the file should already have that in it (see below). Is it possible all your files didn't download? Or maybe you took them from head instead of the unstable 2 release? In either head is the most up to date drupal 7 version with a small fix to make ldap authorization work.

 // These lines serve to fix the attribute name in case a
      // naughty server (i.e.: MS Active Directory) is messing the
      // characters' case.
      // This was contributed by Dan "Gribnif" Wilga, and described
      // here: http://drupal.org/node/87833
      if (!isset($match[$this->user_attr][0])) {
        $name_attr = drupal_strtolower($this->user_attr);
        if (!isset($match[$name_attr][0]))
          continue;
      }
      // Finally, we must filter out results with spaces added before
      // or after, which are considered OK by LDAP but are no good for us
      // We allow lettercase independence, as requested by Marc Galera
      // on http://drupal.org/node/97728
      //
      // Some setups have multiple $name_attr per entry, as pointed out by
      // Clarence "sparr" Risher on http://drupal.org/node/102008, so we
      // loop through all possible options.
      foreach ($match[$name_attr] as $value) {
        if (drupal_strtolower(trim($value)) == drupal_strtolower($drupal_user_name)) {
          $result = array(
            'dn' =>  $match['dn'],
            'mail' => @$match[$this->mail_attr][0],
            'attr' => $match,
          );

          return $result;
        }
      }

in reply to #13...

Yes - having read the feature request, it is exactly what I'm looking for.

Thanks

p.s. If I can help, please give me a shout - I have access to a test Windows AD environment with LOTS of groups...

Rachel

This would help move this along the most:

- create a feature request for recursive groups in authorization
- write out how the configuration text/form would look
- explain how you would implement it in the type of ldap you use.
-- With AD I would think you would use the memberOf attribute of the user and find all groups the user belonged to. Then find all the groups those groups were children of.
-- With AD, Alternatively you could list all the groups dns that you wanted to recurse, find them and recurse through them until all were exhausted.
-- Openldap, novell, etc I would hope there was an easier way to do this. Perhaps there is an easier way in AD?

By being a discrete issue in the issue queue it can be given status and focused dialog.

Thanks. I think this will be very handy if we can implement it well.

Voting for groupOfUniqueNames.

It is pretty common and widely used.

I suggest that simplest change will be:
'Name of the multivalued attribute which holds the CNs of consumer_shortNamePlural members, for example: memberUid'
to
'Name of the multivalued attribute which holds the CNs or DNs of consumer_shortNamePlural members, for example: memberUid or uniqueMember'
and corresponding code changes, of course.

Maybe choice selector 'Search for DN, then for CN (default) / Search for DN only / Search for CN only' will be useful also.

I'm closing this thread. It doesn't fit into the drupal project issue queue data structure which is designed for a feature request to be created individually so they can have responses and be tracked into the code. Please move any feature requests to their own issues tagged as "feature requests".

If someone has the energy to go through this thread and move any feature requests not in 7.x-1.x-beta1, that would be helpful.

The feature requests have been pretty well articulated in this project and I appreciate that. What would be even more helpful would be if feature requests came with:
- tag it for 7.x-1.x-dev or 7.x-2.x-dev.
- some pseudo code for the simpletest for the feature and the fake ldap server data used to test it. See ldap/ldap_authentication/tests/LdapServerTestData.ldapauthen1.inc, ldap_authorization/tests/ldap_authorization_test_data.*.inc, and LdapServerTestData.ldapauthor1.inc for examples.
- some documentation and UI stuff.
- a use case or two.
- pseudo code is even helpful.

Often feature requests are just confusing