Defect #2040


first ldap auth mode does not works but the second does

Added by Erik Ordway over 15 years ago. Updated about 11 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Cant reproduce
Affected version:


Ok I set up two instances to test this.

Where I work the LDAP tree (AD) has a section for "faculty and staff" and other for "students" . Due to wanting students to be able to self reg I set up two auth methods, one for students (id => 1) and another for "faculty and staff" (id => 2). I never really tested the student one as it has not been used yet.

Then I needed to set up another instance that only "faculty and staff" have access to so I only set up one authentication method. It would not work. The test button was happy but now one could auth. I took the working site config and line by line copied the config and used the same user to connect to the ldap tree and to try and log in with. The only difference was that the first site had 2 auth methods with the working one being second and the second site had only one.

So I copied the first auth method on the second site to a second auth method and low and behold it worked and people could log in when the new auth menthod was set for them. Then I when back and tested the first auth method on the first site and it would not work also.

What seems happening is that this code
dn = :base => self.base_dn,
:filter => object_filter & login_filter, # only ask for the DN if on-the-fly registration is disabled
:attributes=> (onthefly_register? ? ['dn', self.attr_firstname, self.attr_lastname, self.attr_mail] : ['dn'])) do |entry|
dn = entry.dn

is not running for the first auth method and the dn is empty so that when you get to

return nil if dn.empty?

the method returns.

I can not explain why this happens.

Actions #1

Updated by Erik Ordway over 15 years ago

After a bit more testing it seems that method #1 will always fail but ones with id's of 2 and 3 will work.

Actions #2

Updated by Daniel Felix about 11 years ago

  • Due date set to 2013-02-13
  • Status changed from New to Needs feedback

I'm currently not able to reproduce this error with the current Redmine trunk. Maybe you could test this with the current trunk?

I will close this issue next week if there will be no feedback on this issue.

Actions #3

Updated by Toshi MARUYAMA about 11 years ago

  • Category changed from Accounts / authentication to LDAP
Actions #4

Updated by Daniel Felix about 11 years ago

  • Status changed from Needs feedback to Closed
  • Resolution set to Cant reproduce

I'm not able to reproduce this in the current release and trunk. LDAP seems to work as expected.

As there is no feedback on this issue. I'm going to close this issue.


Also available in: Atom PDF