I posted my question in support, and Boris Mann said it is probably a feature request (http://drupal.org/node/78457). I did a search of existing requests, and mine may be related to http://drupal.org/node/65105 but I didn't see others like it.

I want to be able to set up drupal-based ACLs for certain users so they're ready the first time that user logs in via ldap. (The drupal admin won't have write privileges to the ldap database.)

Ideally, I think it would be great if on the administer -> users -> [add user] tab right by the password box there were a checkbox that said "fetch user from ldap" and if that box were checked, the page would return what you normally get when you click the "edit" link next to the list of users (and password would cease to be a required field).

A submit button on the [add user] tab that said something like "find user in ldap" would work, too, essentially turning the form into a search that could do partial matches and the like so you wouldn't necessarily have to know the username before you started.

The necessary functionality, though, is to create the data that is created the first time an ldap user logs in without having to know the user's password or have the user log in first.

I've worked with a CMS which offered to import all users and then created a pick list of them all, which was completely unruly. However, smaller orgs might want to. And it would be very handy to search on a group and handpick multiple users to assign specific roles.

Thanks in advance for considering the possibility of adding such a feature. I'm more than willing to assist with documentation and with testing.

Comments

kreaper’s picture

kreaper commented
Version: 4.7.x-1.x-dev » master
Status: Active » Postponed
jjk005’s picture

jjk005 commented
Status: Postponed » Active

I second the idea of this feature. I need to be able to assign users to groups instead of roles, and I can't do this until the user logs in. If i create the account in drupal before the user logs in for the first time, they get a duplicate user error message, which makes sense since the module isn't expecting the user to already exist. But I can't assign them to groups until they log in, which means that I have to wait for that to happen before finally setting up the site, which doesn't seem to be the way to go. So i guess this post is about the same thing, except that it would be nice to be able to map ldap groups to drupal groups prior to login. Any idea how feasible this is?

fronbow’s picture

fronbow commented

I have the exact same requirement as jjk005. I can't start assigning stuff to users until they login and their details are verified with ldap. (Which is usually when I'm not around and they need to do something urgently!!)

nirbhasa’s picture

nirbhasa commented

Third this idea.

Or basically anything that means I dont have to ask the user to log in and log out before giving them the role....

micahw156’s picture

micahw156
he/him/his
commented

+1 for some way to do lookups for administrators creating users that will authenticate via LDAP. It's a lower priority for me, but it would be a nice feature to have eventually.

micahw156’s picture

micahw156
he/him/his
commented

I was just looking at the patch at http://drupal.org/node/80570#comment-440133, which appears to do an LDAP lookup to reset connections for all users (except uid=1). Modifying those changes to do a lookup on new user creation, and/or to reset a single existing user, might be the key to solving this issue.

micahw156’s picture

micahw156
he/him/his
commented
Status: Active » Closed (works as designed)

From the original post:

I want to be able to set up drupal-based ACLs for certain users so they're ready the first time that user logs in via ldap. (The drupal admin won't have write privileges to the ldap database.)

This is now what happens under the LDAP Groups module in Drupal 6, based on functionality added to the Drupal 5 version of this module. If appropriate group-to-role relationships are defined in ldap_groups, then ACLs can be set before users log in for the first time.

Considering that this issue was opened for Drupal 4.7 and has been inactive for nearly three years, I think it's safe to say that it has been resolved.