Login fails with similar CNs

Appreciate the suggestion, and that would also be my choice... but considering the numbers of schools and offices and the existing eDirectory structure, I have a better chance of winning the lottery than getting any of that changed. :)

Q: I also manage several moodle sites for online learning and stuff, and the moodle ldap feature does not suffer the same failure for users that fail on my Drupal setup. Don't get me wrong, I by far prefer drupal and its nomenclature... but am guessing that the fetch/validation operation is different between both systems. I would have to guess that Moodle fetches and validates one at a time and posts login failure once it is out of usernames/pwds pairs... whereas the Drupal module throws an error if more than one user is found (without any validation being done before this error)?

I would not need to filter or do anything else if the module could simply fetch and validate every user, one at a time, until it is out of users/pwd matches...

I am going to try and look at the code right now... but feel that it is most likely out of my reach to make any useful changes. I will keep you updated.

Appreciate your input! More than happy to entertain any other ideas you may have, or even better, tell me if my resoning (above) is sound/on the right track.

Alright... so I looked over some of the code in the ldapauth.module....

A few reasons why there is no 'easy' fix for my situation from what I can make out of the code...

- if you allowed similar CNs in the _ldapauth_user_lookup call, there would be a problem in the Drupal user list - if a user authenticated successfully against LDAP first time, the user is registered in the Drupal system... so being a flat namespace in Drupal, you would have identical user accounts one the second user tries to log in.... correct?

*uggggh, from what I can see, I may have to abandon Drupal because of this... arrrgh. Hmmph.

Q: Based on your suggestion above however, (revamping the LDAP structure), there would still be a common CN for some users... but the OU attribute would differentiate them - making my comment above incorrect? Not a flat namespace if what you suggest works... because although the namelookup would find them in different DNs, would it not still cause conflict in creating the user in Drupal? I am unclear as to why your suggestion would work (because there would still be two users found with multiple DNs listed), and I assume it stops iterating through the DN list once a user is found and authenticated successfully... if it gets that far, because once the user is registered, it would only check for the password in ldap? (which would fail if it were the second user trying to log in)

Q: Before returning the result of the _ldapauth_user_lookup call, could we not eliminate the duplicates by only registering the correct user/pwd lookup?

I am obviously a newb in trying to work through this code (quite impressive btw!) and obviously don't have the full picture of the process yet...

Appreciate yout time/patience and suggestions as I really would prefer to use DRUPAL + LDAP in my organization.

Thanx Miglius, hope to hear from you some more on this...

nb: I can appreciate that our LDAP structure is the issue here... however, surely in large organizations, this still occurs? How would this module accomodate that?

Ahh, you bring clarity to the Drupal process for registering users.
I much appreciate the comments and armed a little better to have this discussion with the network admins or our organization.

I will tinker with one of my Moodle setups to see if I can follow the logic in that process. Again, very much appreciate your time. If anything pops up with regards to my particular situation and any other approaches, please don't hesitate to communicate with me here!

Cheers.

If I were to list the 'deepest' DNs first, and work my way back up the tree that way, would this make a difference? Your suggestion of having the LDAP structure re-worked to put employees in their own container and avoid nesting of OUs suggests we could still have common CNs (usernames) and authentication woud work? Thus, when a user authenticates and iterates through the listed DNs, does it search one of them and attempt to validate the user if it finds one BEFORE proceeding to the next DN in the list, or does it do a full search of the entire tree (iterating all the DNs I list...) before attempting to validate the user(s) found (and failing immediately if matches$<>1 )?

Beating a dead horse I know... but just a thought that popped up from what you explained earlier....

Alright, tinkered some more... answered some of my own Qs in the process.

The users I tested that had same CN usernames were in different branches... so I changed the DN list and put in specific branches... thinking that what you suggested about the LDAP structure change might help...
but alas, no. The process fails as soon as it encounters 'incorrect credentials', however, the matches$ problem does not occur. So your final comments about each user needing to have unique usernames ultimately remains true.

All this being said, I would have to think this ugly issue will raise its ugly head again in larger enterprises as similar CNs will occur (in different branches, there is definitely improper LDAP structures out there)... based on this experimentation here, I can appreciate your concern about auto-generated pwds being a concern, but one, pretty remote chance, and two, can be documented in the release / installation notes...

..iterating through an array of returned users from the lookup call instead of just killing the process at the first found user would seem logical to me... undoubtedly a significant change to the inner workings of the process and dependencies with the other LDAP modules, but surely this will be a limiting factor for many orgs.

Again, thanx for your time and patience as I knit some kind of ugly kludge for my situation... essentially just trying to fully understand the process.

I would appreciate your feedback on these comments once again.

Cheers!

Well, I seem to be just bombing this issue eh?

I have found what I think will be a short term solution... authentication wise for now... I changed the CN parameter and specified 'mail'... so that the user accounts created in Drupal will be the employees email address, which are obviously unique in the tree! I tested this with only two accounts at the moment, but it worked... students are not provided an email address, so it takes care of that issue, and if they have access to their own school's moodle, then they don't need to log into the main website (although I would have liked a one stop login 'area')... but I am still working out this idea.

Now, the design of your module was surely not to use the email addies for this purpose (although it is used on all the major sites....). I am hoping I can easily 'mask' or specify which attribute to use (First name or shortened email addy to the username) for posts, comments, etc, as I would not want bots to pick up all these email adresses and increase our spam hundredfold.

Am I missing some very obvious security/management issues in this approach? Again, like all the posts above, your feedback is appreciated and welcomed here once again...

Thanx miglius (and whomever may reply), have a good weekend. :)

U have echoed everything I discovered on the weekend trying to hammer this out. You have worded it far better than I would have, but I did indeed confirm everything you describe here above. I respect the design decision, and knew as embarked on this project that the LDAP structure was going to be an issue.

I am a fan of proper structure and protocol as well, I was just trying to limit the amount of frustration in dealing with this in my setup. I appreciate the time and thought you have given to my questions. You have truly been helpful.

Cheers!