Group Membership Checking not working with OpenLDAP about ldap_login HOT 21 CLOSED

Most other LDAP-enabled applications I've used will ask you to provide the LDAP query strings and property names/classes, which allow them to work with any variety of schemas without having to change the underlying code. Unless there is a reason to do otherwise, this might be a good solution to this problem, and it seems like it will also simplify the group checker code in the Ldap class.

Tnx! I'm working on a new update that will implement this. This will also fix #20 and implement multi group support (admin/users)

from ldap_login.

hello, i have same issue...

from ldap_login.

same problem here...but with freeipa for the ldap-backend

from ldap_login.

I had the same problem. Can you double check that you have your user added to the group?

I saw I had to add my users to memberUid

from ldap_login.

Hello, I have the same issue.
My LDAP is populated / driven by SAMBA (4.5) Active Directory.
It does not populate the memberUid attribute for any of my groups so far.
Yet I tried to manually put my users uidNumber (uid attribute is empty for all my users) in there, but that does not solve it - also tried the sAMAccountName but no luck either.

The attribute that gets populated by SAMBA AD automatically is the member attrib' for groups, it holds the full DN for any user who is member of that group.

@Kipjr what did you put into the memberUid attribute of your group? Is it maybe possible to use a different attribute to evaluate memberships?

from ldap_login.

Hi @sock3t I tried to fix it by installing a testserver with OpenLDAP and modified some code. I updated in the dev-tree. Please check 2d5313d and try if it works.

from ldap_login.

Hi @Kipjr I'm having the same problem, trying to connect to Windows AD. I have tried your new version 2d5313d that allows you to select MS Active Directory, but I am still getting the "Credentials OK, Check GroupMembership..." response.

I'm not sure the "DN of Group for membership-check and calculated CN (using RegEx)" is working, or maybe I just don't understand how it's supposed to work. I'm putting in the full DN path in that field... so cn=MY-GROUP-NAME,ou=MY-OU,dc=company,dc=com

After I save it, the RegEx box lists exactly the same string, there is no new CN value calculated. Is this how it is supposed to work?

I think I'm missing something....

https://i.imgur.com/z62C84G.png

from ldap_login.

Hi, thanks for your message. The field DN of Group for membership-check and calculated CN (using RegEx) is working as followed:

On a user the function isMemberOf() is executed (works only in AD!). This results in an array containing the groups in which the user is placed. (For non-AD this works the other way around, which users are in the specific group)

This array is compared with the DN of the group and based on the boolean result, you get access.
My DN-value is: cn=piwigo_users,ou=groups,dc=home,dc=local and CN: cn=piwigo_users. This value is just as-is and will be calculated after save and reload. Internally it is used to directly address the CN. Also check the difference between CN and DN in the documentation, it helped me a lot

Also I noticed you are using group and member, maybe this can result in difficulties. Check you attributes in ADDS (advanced) at the user and group item.

from ldap_login.

Thanks for the reply. I figured out one problem... my CN was not calculating correctly because your RegEx is case sensitive. I had typed in my DN with capital letters (DN=, OU=, DC=), which caused the RegEx to just keep the entire string. Once I converted my DN characters to lowercase (cn=, ou=, dc=), the RegEx correctly changed the string to only the cn= value.

However, I am still getting the Check Group Membership warning... I have tried every combination of group class and member attribute (group/posixGroup, member/memberUID)

Also, I don't think this is related to the problem, but I'm getting a warning at the top of the page after testing the connection that says:

Warning: file_put_contents(/var/log/ldap_login.log): failed to open stream: Permission denied in /var/www/html/plugins/Ldap_Login/class.ldap.php on line 14

I did a chown and chmod 777 to the whole Ldap_Login folder so I'm not sure why I'm getting a permission issue writing to the log...?

from ldap_login.

from ldap_login.

No problem about the RegEx, just something I didn't think about at first.

I figured out the log permission problem... it wasn't the permission of the class.ldap.php file that was the problem, it was the permissions in the /var/log folder where it was trying to write the logs to. I created the ldap_login.log file in that folder manually and chowned it, now the error is gone and the logs write successfully.

The logs are actually really helpful, but I'm still not sure what the problem is. Here's the log from when I test using the same configuration I described before... Windows AD mode, group and member options selected.

https://i.imgur.com/mnIOP2K.png

In this example the AD username I type in is "jessek". It binds using the admin credentials successfully, finds the user account dn, and finds the group dn. But it fails to find the username when checking the group member's array... I am wondering if something is wrong with the php code that does the check for the array. Seems like it has all the info it needs but it can't match them for some reason.

I looked at the Attributes Editor on the user account in ADDS and I don't see anything unusual except that there is no memberOf attribute listed. But according to Google that is normal, since memberOf is just a calculated attribute based on the "members" attributes of the groups. Still, if you're looking for the memberOf attribute, and its not there, maybe that's the problem?

Thanks for your assistance

from ldap_login.

@jessek09 , hopefully it is fixed

from ldap_login.

Well I was unable to get it working the way it was intended. But I don't actually need to check group membership to authorize Piwigo access, I just need to allow any domain user login permissions. So I stripped out the group check code and just kept the credential check code. So now any domain user will be granted a login assuming their credentials are validated. Not ideal but it works for my purposes.

from ldap_login.

I get it. But without filling in any group you'll be granted access regardless of the group membership.

from ldap_login.

I get it. But without filling in any group you'll be granted access regardless of the group membership.

That’s correct. In my situation, I am not concerned with securing which groups have permissions to access the gallery. The gallery is basically public, but I want each user to have their own login which will be used to define upload permissions to various folders. So as long as LDAP can authenticate their user credentials, I can handle access permissions with Piwigo itself.

from ldap_login.

from ldap_login.

Well, I don't think the root problem (group membership check) is solved. I worked around it but other users may not be able to. But I will let you decide :)

from ldap_login.

I just recently ran into this problem as well (using FreeIPA). FreeIPA uses 'groupofnames' object type for its non-POSIX groups, rather than the 'group' class. So adding 'groupofnames' to the available object classes, I was able to get the LDAP query to return results.

The problem then became that the code was trying to compare the string "uid=myuser,cn=groups,dc=example,dc=org" to "myuser", which was never going to succeed. I hacked a fix for this by adding in a preg_match() to Ldap::check_ldap_group_membership(), and everything was working.

Most other LDAP-enabled applications I've used will ask you to provide the LDAP query strings and property names/classes, which allow them to work with any variety of schemas without having to change the underlying code. Unless there is a reason to do otherwise, this might be a good solution to this problem, and it seems like it will also simplify the group checker code in the Ldap class.

Example from Bitbucket's LDAP provider setup page:

Anyway, thanks for your work on this plugin!

from ldap_login.

Hi @Kipjr,

it still does not work for me as well. Just to make sure again: the users sAMAccountName is not the same as the values that are stored in the member attribute of the group:

• the group
  
• the membership list
  
• the user and the sAMAccountName
  

But I am not even sure whether it gets that far. This is from /var/log/ldap_login.log:

2019-03-22T22:00:47+01:00: [function]> ldap_search_dn(username)
2019-03-22T22:00:47+01:00: [ldap_search_dn]> Connecting to server
2019-03-22T22:00:47+01:00: [ldap_search_dn]> make_ldap_bind_as($this->cnx,CN=piwigo ldap user,OU=accounts,DC=domain,DC=com,*_password_here_*)
2019-03-22T22:00:47+01:00: [function]> make_ldap_bind_as
2019-03-22T22:00:47+01:00: [make_ldap_bind_as]> $conn,CN=piwigo ldap user,OU=accounts,DC=domain,DC=com, *_password_here_*
2019-03-22T22:00:47+01:00: [ldap_search_dn]> @ldap_search($this->cnx,DC=domain,DC=com,(&(objectClass=person)(sAMAccountName=username)),array('dn'),0,1)
2019-03-22T22:00:47+01:00: [ldap_search_dn]> ldap_search NOT successfull:
2019-03-22T22:00:47+01:00: [function]> ldap_bind_as
2019-03-22T22:00:47+01:00: [ldap_bind_as]> CN=piwigo ldap user,OU=accounts,DC=domain,DC=com,*_password_here_*
2019-03-22T22:00:47+01:00: [function]> make_ldap_bind_as
2019-03-22T22:00:47+01:00: [make_ldap_bind_as]> $conn,CN=piwigo ldap user,OU=accounts,DC=domain,DC=com,*_password_here_*
2019-03-22T22:00:47+01:00: [ldap_bind_as]> Bind was successfull

Still this message on the ldap config page after doing the "Test settings":
Error : Binding OK, but no valid DN found on server ldaps://dc.domain.com:636 for user username

from ldap_login.

I think this is bug.
And I tried to fix it. #25

from ldap_login.

Thanks everyone for your support, please check: 37802bb

from ldap_login.