roles are not assigned during initial login

With the same conditions, Active Directory and upgrades, I constate too that roles are not assigned during initial login and I revert back LDAP integration 1.2

can you put some debug statements in the code and tell me what's happening so I can troubleshoot that better ?

From the looks of it, it is only that the first time when a user logs in, the roles are not being granted - all other times this is working - correct ?

hmm.. may be something funky in the _user_authenticate()

Ran into the same thing.

I traced what was going on, and it seems things are fine up to the _ldapgroups_ldap_init($user) check in ldapgroups_user_login(). _ldapgroups_ldap_init() returns false during the initial login, and true on subsequent logins. I presume this is because ldapauth hasn't saved its information to the DB by the time ldapgroups is trying to read this data. Maybe the data needs to come from the user object rather than the DB?

Hey guys!

Same problem roles are assigned on the second login, not on the first...
Is there a solution yet?

And I've got just another problem, not all LDAP Groups are created in Drupal. That means even if I create the groups manually before the initial login of a member of one of these groups, they aren't assigned to them...

Any ideas?

Thx

Same problem here.
In fact, I just posted a bug report (with no resolution yet) over here:
http://drupal.org/node/173825

Any solved this? It's killing me!

I just got back into town from work-related travel. May be this weekend I will dive into the code. Hold on to your horses! (or submit a patch!)

I will try pulling the group stuff from the user object but I also want to be sure.

Darth_Mobb - you assigned it to yourself - will you be taking on the patch creation - I can commit it when you are ready?

rajeev

User object is indeed cached:
http://drupal.org/node/74020

That is our issue.

Kludge that fixes this problem...just after calling user_save() to store the variables, manually add them to the user object in memory.
Attached file appears to work fine for me.

The code in question (with my watchdoggers too)

$config_name = $ldapauth_ldap->getOption('name');
watchdog("ldap","Config name = $config_name");
$userinfo = array('mail' => $mail, 'ldap_dn' => $dn, 'ldap_config' => $config_name);
watchdog("ldap","user info (to be saved): <PRE>" . sprint_r($userinfo) . "</pre>");
user_save($user, $userinfo);

//added by Brian Miller, 2007-09-07
// aim:  get around the seemingly cached user object which doesn't contain the stuff we just
//       tried to save with user_save();
$user->mail = $mail;
$user->ldap_dn = $dn;
$user->ldap_config = $config_name;

// obtain the DN for this user in this specific LDAP repository
$_SESSION['ldap_login']['dn'] = $dn;
$_SESSION['ldap_login']['pass'] = $pass;

watchdog("ldap","USER BEFORE RETURN: <PRE>" . sprint_r($user) . "</pre>");

return $user;

Hey guys,
sry kreaper I'm an absolute drupal newbie and didn't know what assigned meant...
I set it back to unassigned...
sry if I created trouble...

user_save returns the updated $user object, so why not just use the return value?

The user object is not guaranteed to be complete until after a user_load call; presumably also after a user_save call. But the question is what was the 1.2 version doing differently? I'll try to look into that, but has anyone else yet?

Also is everyone experiencing the "issues with role permissions" that was mentioned? I'm having problems with it. Is anyone not having any role related permissions problems?

Indeed the problem is fixed with the following change, at the end of _ldapauth_save_user.

Change:

      $config_name = $ldapauth_ldap->getOption('name');
      $userinfo = array('mail' => $mail, 'ldap_dn' => $dn, 'ldap_config' => $config_name);
      user_save($user, $userinfo);

to:

      $config_name = $ldapauth_ldap->getOption('name');
      $userinfo = array('mail' => $mail, 'ldap_dn' => $dn, 'ldap_config' => $config_name);
      $user = user_save($user, $userinfo);

And this change also cleared up the permissions problems I had as well. I'm closing this unless anyone else still has problems.

I guess you'll commit a fix, then?

Yes I will, to head & to a bug fix version, but it will not be for a few days or later. It would be good to get a few folks confirming that this does fix the problem too.

If anyone needs help making the change manually, let me know.

Hi scafmac problem is solved with this assignin
(i described in http://drupal.org/node/175051 -- sorry for duplicates but i didn't found this thread after 2 hours search and debug)

NP - glad to hear it worked.

OK, I was just concerned about the issue being marked fixed without a fix being committed.

good point

I just wanted to chime in with my success with this patch as well. This fixed three things for me:

1. Users had no groups on their first login - they had to login, logout, and then login again.
2. Users who went through the steps in 1 above, still didn't get all the permissions they should have and had to edit/save their user record for full group memberships to take effect.
3. Users who were in an LDAP group and removed stayed in that role in Drupal. I suspect this is because they were "added manually" in step 2, and not by way of LDAP synchronization. This is reported separately in: http://drupal.org/node/137836

Anyway, I attached a patchfile, which matches up with the suggested fix in this conversation, if that's helpful.
-N

Mmmmm, [sorry but] this ammendment to the ldapauth module on first glance *doesn't* seem to have sorted this issue for me, users still need to logon a second time to get groups, so I'm investigating.

One possibility I need to consider is my users *don't* have email address in their Active Directory accounts. (but do have email addresses). That line above the amendment...

$userinfo = array('mail' => $mail, 'ldap_dn' => $dn, 'ldap_config' => $config_name);

can I safely hardcode that by adding the username variable to '@mydomain.com' ? If so, any php wizard able to supply the php coded line?

Any advice/help appreciated
Cheers!
Dave

pasa,

Would you explain in detail (maybe even a cut & paste) of the change you made. Also please explain how you have tested it and what versions et al you use.

I wouldn't recommend hardcoding the email into ldap - it is a bad idea, but it is simple to do.

$userinfo = array('mail' => $user->name .'@badExample.com', 'ldap_dn' => $dn, 'ldap_config' => $config_name);

Good luck

Sure Thing..
[Changes I made]

As per the patch, changed the following..

- user_save($user, $userinfo);
+ $user = user_save($user, $userinfo);

Drupal 5.2, Ldap module v 1.3. Ldap via Active Directory, Server 2003, Drupal running on a linux box.

The way I tested was I waited for a new user to logon, and then checked to see if the role was assigned.

This is easy, as Drupal is set up exclusively for student use at a school, and has just been launched. (Also why I'm investigating hardcoding the email. Email is not entered on their AD account, we have hundreds of users but all have the same email domain.)

Cheers!
Dave
(lol, dave, but had to use pasa as 'somehow' another user got 'dave' :-))

After applying the

- user_save($user, $userinfo);
+ $user = user_save($user, $userinfo);

patch, everything is working well except when a user is deleted from an ldap group, they are not removed from the Drupal role.

It looks like this function is only deleting the user's current ldap groups.

$user->ldap_drupal_roles = isset($user->ldap_drupal_roles) ? $user->ldap_drupal_roles : array();

foreach ($user->ldap_drupal_roles as $role) {
_ldapgroups_deny_role($user, $role);
}

...

function _ldapgroups_deny_role($user, $rolename) {
$result = db_query("SELECT * FROM {role} WHERE name = '$rolename'");
$role_exists = db_num_rows($result);

if ($role_exists) {
$role = db_fetch_object($result);
$result = db_query("SELECT * FROM {users_roles} WHERE uid = $user->uid AND rid = $role->rid");
$role_present = db_num_rows($result);
if ($role_present) {
db_query("DELETE FROM {users_roles} WHERE uid = $user->uid AND rid = $role->rid");
}
}
}

Should it check the other way around? Look in the users_roles table, and if there is no corresponding ldap group, delete the user from the role.

Also, the $rolename in the above function contains the entire DN. So we would need to do the $friendly_role, like the create and grant functions.

if (preg_match('/^[^=]*=([^,]*),.*$/', $rolename, $matches)) {
$friendly_role = $matches[1];
}
else {
$friendly_role = $rolename;
}

Thanks.

I take back what I said about the user not being removed from the Drupal role when they are removed from the ldap group. It is working fine now.

So the only thing I had to change was :

foreach ($user->ldap_drupal_roles as $role) {
_ldapgroups_deny_role($user, $role);
}

to this :

foreach ($user->ldap_drupal_roles as $role) {
if (preg_match('/^[^=]*=([^,]*),.*$/', $role, $matches)) {
$friendly_role = $matches[1];
}
else {
$friendly_role = $role;
}
_ldapgroups_deny_role($user, $friendly_role);
}

Also I had to issue a menu_rebuild(), since our users' menus change based on their roles.

Thanks

Any reason not to commit the fix for this bug?

I've found three issues that seem to describe the same problem.

The last comment on 175051 directs users to this issue.

Comment #1 on 211590 references this issue, and proposes a slightly different patch.

#27 above asks about committing this fix, but the last patch in this issue was #14 and there have been many code changes proposed since then. I basically took the patch from 211590 and rolled the attached for your review. There are a couple of differences between this one and #26 here, so I don't think this should be committed until the discrepancies are discussed and you guys agree what's right:

• added menu_rebuild() as described in 211590.
• used $role instead of $friendly_role in ldapgroup.module, but it's not completely clear which way is better.
• Not sure I really needed to make the change at line 290 in ldapgroup.module.

This patch works in my environment, but I haven't tested every possible scenario. Please review and comment, and maybe we can get this finished off and committed.

Just to confirm that micah's patch #28 works well on OpenLDAP 2.2.13 running on RHEL4.
Thanks!

All, sorry for the delays...

So has anyone confirmed the need of the menu_rebuild? Once I corrected the $user = user_save in the multiple sites I maintain, I didn't have a problem with menus & such changing per role. They worked as expected.

With regard to #25 above - sorry to be dense, but was there a problem? You say "It looks like this function is only deleting the user's current ldap groups", but you don't explain the problem you were experiencing or any testing you did...

At this point, I'm only going to commit the patch from #21 in a bug fix release.

Hmmm.... somehow I missed patch #21 before. I reapplied #21 to a fresh 5.x-1.3 and tested with a new user. Yes, this seems to be working fine with just the one line changed. The other stuff I added from 211590 does appear to be superfluous at this point.

Yeah, you can ignore #25. The only thing I had to do was #26.

Thanks

User still needs to logon a second time to have roles mapped.

I've tried #25, #25 and #28 independently.

I'm using Drupal 5.7
Ldap via Active Directory, Server 2003
ldapauth.module,v 1.28 2007/08/22
ldapgroups.module,v 1.24 2007/07/22 20:04:25

I'll try to see if I can find the location of the problem and a fix.

The patch is in the 5.x-1.x-dev release. That release should be used until 5.x-1.4 release is posted.

Using 5.x-1.x-dev I've the same problem, just not with groups: with LDAP Data. Mapping of ldap attributes to some profile's field happens only after the second user's login!

The current (May 10) 5.x-1.x-dev version doesn't resolve the need to logon a second time to assign roles so this should remain an open bug. Even if 5.x-1.x-dev did fix it, it should still remain an open bug for version 5.x-1.3.

Is the earlier version of 5.x-1.x-dev referred to in comment #34 available?
I can test also, just let me know which drupal 5 version needs testing.

I tested this on a clean install of Drupal 5.7:

- Apache/1.3.41 (Darwin) PHP/5.1.4 mod_jk/1.2.6 mod_ssl/2.8.31 OpenSSL/0.9.7
- Active Directory LDAP Server
- leaving the file modules/ldap_integration/ldap_integration/ldapgroups.conf.php unchanged
- LDAP Groups specified by LDAP Attribute "memberOf"

RE: #35 - You need to open up a new issue or find an existing one with the same problem. This issue only applies to LDAP Groups.

Let me check the dev release...

John,

Hmm, I just tested it against an AD server and it worked, but it wasn't on a Drupal-5.7 install... I'll try it once I upgrade.

How do you have the authentication configured - Drupal then LDAP or LDAP only?

You've confirmed that the role does get assigned on second login? Does it ever take three or more login attempts or always on the second?

Can you confirm that line 962 in ldapauth.module is:
$user = user_save($user, $userinfo);

Are you relying on recursion to search multiple CNs or do you explicitly set the groups CN? Is that the only LDAP Group section enabled?

Can you humor me and perform the following steps - Actually I would first try, skipping steps 2 & 3, but then if it doesn't work start again with all steps - your call:

1. Delete your AD user from Drupal
2. Remove & uninstall ldapauth & ldapgroups
3. Re-enable ldapauth & ldapgroups & setup
4. Login with your AD test account in another browser (or logout first)
5. Switch back to the admin account & check the roles assigned to your AD test user in Drupal

Let me know what you discover & I'll try a 5.7 install.

Thanks for responding. I hope I can help isolate the bug.

I tried your steps and answer your questions below, but attached are 3 files that may also help. One of my overall configuration related to LDAP, one of the user object and relevant table data after the first logon, and one after the second logon.

How do you have the authentication configured - Drupal then LDAP or LDAP only? Drupal then LDAP

You've confirmed that the role does get assigned on second login? Does it ever take three or more login attempts or always on the second? Yes. Second time.

Can you confirm that line 962 in ldapauth.module is:
$user = user_save($user, $userinfo); This wasn't the case as I was using the recommended version of 5.x-1.3, but I changed it before testing.

Are you relying on recursion to search multiple CNs or do you explicitly set the groups CN? Is that the only LDAP Group section enabled? I'm letting the ldap groups come from the memberOf attribute, so there are many roles created autmatically

p.s. I see your 5.2 dev version. I have a site to test this on, but only have access to MS Active Directory.

Anyone else - #261573: 5x-2-dev update & admin interface feedback

How do you have the authentication configured - Drupal then LDAP or LDAP only?
Drupal then LDAP

Would you repeat the tests (skipping steps 2&3) with it set to LDAP only. Any difference?

Can you confirm that line 962 in ldapauth.module is:
$user = user_save($user, $userinfo); This wasn't the case as I was using the recommended version of 5.x-1.3, but I changed it before testing.

Until I get more feedback on the dev release (5.x-1-dev), I'm going to leave 5.x-1.3 as recommended even though I know it has bugs. But the LDAP project page has some useful suggestions for some problems like this. The main one being upgrade to the 5x-1-dev to see if it fixes your problem. Try the LDAP only test first though please.

Are you relying on recursion to search multiple CNs or do you explicitly set the groups CN? Is that the only LDAP Group section enabled? I'm letting the ldap groups come from the memberOf attribute, so there are many roles created autmatically

Just to be clear, your using the third group configuration, titled "Groups exist as LDAP entries where a multivalued attribute contains the members' CNs"?

- I tried with LDAP only and same result.
- I'm using the second option on /admin/settings/ldapgroups/edit/ "Groups are specified by LDAP attributes" and my attribute name is "memberOf"

- is the April 29th dev version available somewhere (comment #34). I'd like to use the dev version, but its likely a moving target and the May 10 dev version isn't helpful. When I browse the CVS over the web, I don't see any dev versions (http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/ldap_integr...) I'll also try permutations of all the patches in this thread.

I found the problem in my case.

My DN for non-anonymous search didn't have rights to view memberOf attribute which held the user's group name. (I call this user the "machine user") The machine user could get other attributes so didn't throw and ldap error though. This is because in our LDAP the memberOf attribute is protected for privacy (FERPA) reasons.

When the user initially logs on, the user LDAP object is queried using the binding of the machine user. The second logon and afterward, the user's DN and credentials are used to bind.

I found the problem with a lot of print_r()'s. Seems to be completely unrelated to other suspected causes on roles not being assigned on first logon, so this scenario likely caused a lot of confusion for those in my boat.

My quick fix was to change the following around line 345 of ldapgroups.module

from:

$pass = isset($_SESSION['ldap_login']['pass']) ? $_SESSION['ldap_login']['pass'] : '';

to:

if ($_POST['op'] == 'Log in' && $_POST['pass'] ) {$pass = $_POST['pass'];}
else {$pass = isset($_SESSION['ldap_login']['pass']) ? $_SESSION['ldap_login']['pass'] : '';}

I wouldn't call this a patch as I don't fully understand the module or its affect on other LDAP_integration configurations.

Resolving the bug could simply mean changing the text in admin/settings/ldapauth/edit/ in the Advanced configuration to read:

For security reasons, this pair should belong to an LDAP account with stripped down permissions. But the account should be have rights to read any attributes and objects used by other modules such as LDAP_Groups.

Thanks for helping me narrow this down. I'll keep testing 5.x-2.x-dev as it changes.

Well, I experience now a reversed behaviour: during the first log in user gets assigned to the existing Drupal role and gets no group upon following logins!..

5.7
OpenLDAP 2.3.30
Latest 5.x-1.x-dev (2008-May-10)
Using CNs as UserNames
"Groups exist as LDAP entries where a multivalued attribute contains the members' CNs"; attribute - member.

cn=groupName,ou=Groups,dc=domain,dc=tld holds members like uid=username,ou=People,dc=domain,dc=tld (tried members as cn=User Name,dc=domain,dc=tld to no avail).

Alex.

UPDATE:

Commenting out the whole function ldapgroups_roles_filter($groups) function in ldap_integration/ldap_integration/ldapgroups.conf.php as well as adding a site specific ACL rule in slapd.conf helped to get a normal behaviour.

I can confirm that #42 fixed my issue.

This is a pain because the issue still exists in the latest version (1.3). I did apply the other user_save change as well but it didn't seem to do anything. Can we get this patch applied to 1.3??? I'm not savvy enough to submit a patch so someone with know-how should submit one so that this can be fixed. I had this module working for a while when I applied this change about 3 months ago. I since forgot about this change and had to spend a few hours searching for it. When I finally found it and made the change it fixed the problem.

It'd be nice to know that we can upgrade to the latest version and not worry about having to dig for this change to make the module work. Forgive me for ranting about this. I love the module and am glad that it exists. It's making our website incredible!

Guys,
I'm still having issues with roles not getting deleted when the user is removed from the group in LDAP.
I applied the patches in 28, but still seem to be having problems.

in ldapgroups_user_login()

foreach ($user->ldap_drupal_roles as $role) {

if (preg_match('/^[^=]*=([^,]*),.*$/', $role, $matches)) {
$friendly_role = $matches[1];
}
else {
$friendly_role = $role;
}
_ldapgroups_deny_role($user, $role);
}

In this loop, $user->ldap_drupal_roles seems to only contain groups from LDAP that the user currently belongs to.
If a user is removed from a group, the group does not show up in this array, so how can it remove the user from a role that is now no longer listed in the user's groups?
Should $user->ldap_drupal_roles contain all groups from the LDAP server or something?

I'm on Drupal 5.1, LDAP integration 1.3

maybe it's a configuration issue? Is there some setting that tells the module to look somewhere for the list of ALL groups in LDAP instead of just the ones the user is part of?

Thanks

Drupal 5 has reached end of life, so I am closing all D5 issues in my list.

I have not seen this problem with ldap_groups since switching to D6. (Actually hadn't seen it for a long time on my remaining D5 site, either.)

If this issue still applies with Version 6.x or later, please reopen this issue with correct version tag.