Hi there,

Everything works great with this module and my Active Directory until I add someone to more groups, or change the group they're in. As an example:

> LDAP Bind failure for user CN=Firstname Lastname,OU=Group 1,OU=Group 2,OU=Users,OU=Whole Org,DC=companyname,DC=thecompany,DC=com. Error 49: Invalid credentials

I took myself out of some of those groups. Now, LDAP auth tries to bind as my wrong DN and I don't get any of my permissions or new groups! Even if I disable ldapgroups and ldapdata, the module still doesn't bind correctly!

Please advise :)

Comments

KiberGus-1’s picture

KiberGus-1 commented

The same thing wiht 5.1 drupal. Autentification works well, but user dn, stored in users table is not modified. I think, the best solutions, would be to catch bind errors, and search for user with the same name in the directory again.

kreaper’s picture

kreaper commented
Assigned: Unassigned » kreaper

Can you please check out HEAD and let me know if the problem persists ? The code in HEAD updates the dn from the successful con fig.

kreaper’s picture

kreaper commented
Version: 4.7.x-1.0 » master
kreaper’s picture

kreaper commented
Status: Active » Postponed (maintainer needs more info)
KiberGus-1’s picture

KiberGus-1 commented

Now it is much better. User can login after his acount was moved to another OU. But there is one minor bau. User DN in drupal will be updated only after user logs in. So before user logs in administrator wouldn't be able to modify users fields.

smithmb’s picture

smithmb commented
Status: Postponed (maintainer needs more info) » Active
miglius’s picture

miglius commented
Status: Active » Closed (won't fix)

That's true, but how can the drupal know where the account in LDAP tree had been moved to?

smithmb’s picture

smithmb commented

Can't you just do a search based on the current module settings, see if the account name field matches any results, and then update the Drupal account's DN with the search result that matched? This would be a bad strategy if you treated DN as a unique key for each user, but your module allows an account name to be a unique key for each user, and allows DN to be a non-unique value (with groups embedded in it, for example). So match on the account, update the DN. Essentially, just treat every login like the user didn't exist yet when you go to look them up -- don't store DN in a drupal table if it isn't going to be unique forever for a user :)

miglius’s picture

miglius commented

You're asking what's already there:

The DN stored in drupal is just for a record to see which DN was matched on the last login.

On each login module cycles through all configured servers and all Bind DNs for each server. If the user's DN which consists from the user's name + bind dn is found in ldap, then the module tries to authenticate with that matched DN. If authentication succeed, the user gets authenticated and the DN is stored in the drupal. The cycle continues until all servers and Bind DNs are tried out.

If your new DN is CN=Firstname Lastname,OU=Group 1,OU=Group 2,OU=Users,OU=Whole Org,DC=companyname,DC=thecompany,DC=com,

try adding OU=Group 1,OU=Group 2,OU=Users,OU=Whole Org,DC=companyname,DC=thecompany,DC=com to the Bind DN's list.