SafeAF / enterprise-log-search-and-archive

Automatically exported from code.google.com/p/enterprise-log-search-and-archive
0 stars 0 forks source link

Proposed bug fix for LDAP authentication #104

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
Two issues below: 
1- LDAP user search (as part of the authentication stage) not working for 
custom LDAP structures
2- LDAP group search when using LDAP operational attributes for the group (like 
memberof with Memberof overlay)

What steps will reproduce the problem?
1. Setup ELSA to authenticate via LDAP against anything but an AD

What is the expected output? What do you see instead?
I would expect ELSA to use the settings in the /etc/elsa_web.conf to build the 
LDAP queries, but instead it uses a static AD-centric query for first SEARCH 
operation. See example below: 

No matter what config has been set, ELSA will try to use the following LDAP 
query for the initial user search: 
(&(objectClass=organizationalPerson)(objectClass=user)(sAMAccountName=<USERHERE>
))'

Following my LDAP structure, the right search query would be: 
(&(objectClass=posixAccount)(uid=<USERHERE>))'

* What I've done to make SEARCH/Authentication work (diff included below):
-- Disclaimer: my perl sucks :-)

1- Add a new ldap/objectClass entry in the elsa_web.conf, describe in this 
entry the objectClass filter for your users (in my case, posixAccount), so it 
looks like this: 
         "objectClass" : "posixAccount",
         "searchattrs" : "uid",  

2- Edit Web.psgi, get to the proximities of line 29 (just before the $auth = 
....) and add the following:

        my $filter = sprintf( '(&(objectClass=%s)(%s=%%s))',
            $api->conf->get('ldap/objectClass'),$api->conf->get('ldap/searchattrs'));

3- In the same file, few lines below, replace:

        filter => '(&(objectClass=organizationalPerson)(objectClass=user)(sAMAccountName=%s))',

With:

                filter => $filter,

This will fix the search step and will allow users to authenticate.
Diff below:

28a29,32
> 
>         my $filter = sprintf( '(&(objectClass=%s)(%s=%%s))',
>             
$api->conf->get('ldap/objectClass'),$api->conf->get('ldap/searchattrs'));
> 
34c38
<       filter => 
'(&(objectClass=organizationalPerson)(objectClass=user)(sAMAccountName=%s))',

---
>       filter => $filter,

* What I've done to make the group function works when the group-mapped 
attribute is an operational attribute (like memberof when using openldap + the 
memberof overlay)

The problem is that the search used in ELSA is not retrieving operational 
attributes. The fix below is not elegant and not flexible (the ideal fix will 
pull a list of fields from the conf file, and then pass them here as an array, 
but this is as far as I go with Perl sadly!) :-)

1- Edit User.pm and add the following within the Net::LDAP::Express call:
        searchextras => ['memberof'], 

That will request the operational attributes in the array (in my case, memberof)

Hope this helps, happy to help with testing/debugging or LDAP setups for 
anybody using OpenLDAP with custom structures.

Thanks

Original issue reported on code.google.com by rhatu...@gmail.com on 7 Mar 2013 at 11:31

GoogleCodeExporter commented 9 years ago
I'll try to get these changes incorporated, though I'm not sure I'll be able to 
test properly.  I have some other fixes I have to get in first, so it may be a 
few days.

Original comment by mchol...@gmail.com on 7 Mar 2013 at 2:38