openldap user login process still incorrect

[GoogleCodeExporter]

Present in latest svn revision 3048:

1) The search filter string ("objectclass=person")  in LdapAuthBase.java:228
HashMap<String, String> getUidCnHashMap(String searchBase) 
is a database specific filter.

It can not be hardcoded.

2) The searching for all user ids is a serious performance issue when there
is a large database of users in the ldap.

Is there a good reason that the code searches for all persons?

Why don't you just create the full dn by the following method:
ldap_search_filter + "," + ldap_search_scope 

If you have to search, why isn't the ldap_search_filter value used?  That
would return at most one result instead of creating a map of all the
persons in the ldap.

Original issue reported on code.google.com by fields.trevor@gmail.com on 27 Feb 2010 at 12:10

[GoogleCodeExporter]

Can we have those in OM_LDAP.CONF as an options? This will be customized by
individual needs.
i.e. in openfire I can customize to search for my AD as follow:
ldap.groupSearchFilter = (&(objectClass=group)(member=*)(!(|(cn=Domain
Guests)(cn=Domain Users)(cn=Exchange Domain Servers))))

ldap.searchFilter = (&(objectCategory=person)(objectClass=user)
(objectClass=organizationalPerson)(mailNickname=*)(!(|
(name=SystemMailbox*)(sAMAccountName=*ap-*)(sAMAccountName=*admin)
(sAMAccountName=abuse)))) 
Thanks,

Original comment by danny.d....@gmail.com on 2 Mar 2010 at 2:16

[GoogleCodeExporter]

Oliver can you comment this Issue? thanks

Original comment by seba.wag...@gmail.com on 2 Mar 2010 at 1:27

• Changed state: Accepted
• Added labels: Type-Task
• Removed labels: Type-Defect

[GoogleCodeExporter]

@trevor : 

1.u r right - the hardcoded "objectclass" searchstring isn't beautiful - it was 
added
on revision 2743, as a part of an openLdap patch (regarding the commit 
message...).
As discussed before in Usergroup, i also think, it would be best to make the 
LDAP
Search more configurable (without adding too much complexity and keeping
compatibility...).

2. why don't we? why don't u? ;-)

@danny : openMeetings isnt a XMPP server as openfire, so it isnt ment to cope 
with
any given LDAP structure ;-). But i also agree with you : making the 
searchparameters
more configurable would be a good idea...

unfortunately, i dont have the time at the moment to extend the ldap 
configuration,
but i dont think it is too hard to add additional LDAP config params into 
current
code - if i can assist you, give me a ping via email...

Looking forward to your commits!

see ya

Smoeker

Original comment by i...@oliver-becherer.name on 2 Mar 2010 at 2:09

[GoogleCodeExporter]

Here is a patch to make the user filter a configurable value.

Original comment by fields.trevor@gmail.com on 2 Mar 2010 at 6:33

Attachments:

• 20100302_ldap_user_filter_changes.patch

[GoogleCodeExporter]

This is incompatible with mine (ticket #1208) that fixes the other OpenLDAP 
issue: 
avoid to download all users entries from LDAP which cause issues with sizelimit.

In Fix 1208, the (objectclass=person) filter is removed and replaced simply by 
the 
user filter (for instance uid=thelogin) which is compliant with any LDAP schema.

However adding a user filter is possible and easy to do. I would recommend to 
implement it after #1208 patch (or derivative) is applied.

Thibault

Original comment by t.lem...@gmail.com on 17 Apr 2010 at 6:30

[GoogleCodeExporter]

Original comment by seba.wag...@gmail.com on 31 Jan 2012 at 12:23

• Added labels: Restrict-AddIssueComment-Commit

[GoogleCodeExporter]

OpenMeetings moves to Apache Foundation, update your bookmarks to the new 
project page:

http://incubator.apache.org/openmeetings/

New Issue tracker is located: https://issues.apache.org/jira/browse/OPENMEETINGS

New Mailing Lists located at: 
http://incubator.apache.org/openmeetings/mail-lists.html 

Original comment by seba.wag...@gmail.com on 31 Jan 2012 at 12:25