Project

General

Profile

Actions

Defect #1420

open

LDAP authentication extremely flaky

Added by mathew murphy over 16 years ago. Updated almost 12 years ago.

Status:
Needs feedback
Priority:
Normal
Assignee:
-
Category:
LDAP
Start date:
2008-06-10
Due date:
% Done:

0%

Estimated time:
Resolution:
Affected version:

Description

I hit a problem with LDAP on Linux. It turns out that net/ldap is extremely unreliable when authenticating against the LDAP server at work. I've filed a bug against net/ldap on RubyForge, but since the project seems dormant it's not clear anything will happen.

As a workaround, I coded up a replacement for app/models/auth_source_ldap.rb that uses the Ruby interface to OpenLDAP. So far this has been reliable.

Presumably ruby/ldap works for some people, so it might be nice to offer both as options, but I couldn't immediately work out how to patch RedMine to do that.


Files

auth_source_ldap.rb (4.08 KB) auth_source_ldap.rb Replacement LDAP authentication code using Ruby's OpenLDAP interface mathew murphy, 2008-06-10 19:18
defect_1420_adriano_crestani_rev_2482.patch (5.44 KB) defect_1420_adriano_crestani_rev_2482.patch Patch for revision 2482 Adriano Crestani Campos, 2009-02-20 22:21

Related issues

Related to Redmine - Defect #3253: LDAP Auth : Alias DereferenceNew2009-04-28

Actions
Actions #1

Updated by Adriano Crestani Campos about 16 years ago

Hi Mathew,

I also ran into this problem when trying to use the default ldap api on a linux server. Your patch works great, thanks ; )

Adriano Crestani Campos

Actions #2

Updated by Adriano Crestani Campos almost 16 years ago

I'm uploading a new patch that contains a merge of the file created by Mathew (the one that uses OpenLDAP instead) and the auth_source_ldap.rb file from revision 2482.

Actions #3

Updated by Daniel Marczisovszky over 15 years ago

I've created a patch that also uses Ruby/LDAP. After I wrote it, I found your patch and they are very similar ;) However it seems that your patch does not bind as the given user if it is set in the account and password fields. I've (hopefully) fixed it in initialize_ldap_con by adding a call to bind after creating connection. The patch can be found here: #3253

Actions #4

Updated by Antoine Beaupré almost 15 years ago

this should be filed under the LDAP category.

Actions #5

Updated by Felix Schäfer almost 15 years ago

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

Updated by Daniel Felix almost 12 years ago

  • Status changed from New to Needs feedback

Well maybe this is resolved due some further upgrades of ldap.

Any news on this? Someone who can verify this?

Actions #7

Updated by mathew murphy almost 12 years ago

Last time I tried it was when I upgraded to 2.1, and it's still broken there. If there have been LDAP improvements in the last few months, I can try again?

Actions #8

Updated by Daniel Felix almost 12 years ago

  • Target version set to Candidate for next major release
Actions

Also available in: Atom PDF