ldap_is_group_member appends incomplete dn to uid if user is not direct child of ou=people

[lukas-th]

Version
docker.io/wheelybird/luminary:v2.1.0

Description
I am trying to use luminary for a existing LDAP server. Users in the admin group (useradmins) are unable to access /account_manager (redirected to /unauthorized).

Output of /run_checks

• The RFC2307BIS schema appears to be available.
• The group OU (ou=groups,dc=mydc) is present.
• The user OU (ou=people,dc=mydc) is present.
• The LDAP account administrators group (useradmins) is present.
• The LDAP account administrators group (useradmins) isn't empty.

LDAP search result for cn=useradmins (some values altered for privacy)

dn: cn=useradmins,ou=groups,dc=mydc
objectClass: posixGroup
objectClass: top
objectClass: groupOfNames
cn: useradmins
description: The Admins for the Users
member: uid=testadmin,ou=internal,ou=People,dc=mydc
member: uid=testadmin2,ou=internal,ou=People,dc=mydc
gidNumber: 2045
displayName: useradmins

Debugging logs:

Able to bind as testadmin: dn is uid=testadmin,ou=internal,ou=people,dc=mydc and account ID is testadmin
...
Auto-setting group_membership_uses_uid to FALSE
...
Session: user testadmin validated (IS_ADMIN=), sent orf_cookie to the browser.

Root cause
In ldap_is_group_member() (ldap_functions.inc.php):

• The function checks if the $username appears in the member attributes of a group.
• It is called during login, to check if the user is in the admins group.
• In the function, the $LDAP['user_dn'] is appended to the $username, to match what is expected in the member attribute when using the RFC2307BIS schema.
• However, $LDAP['user_dn'] is only ou=people,dc=mydc, and therefore missing the ou layers between ou=people and the user leaf.
• Therefore, the function searches the admin group for uid=testadmin,ou=people,dc=mydc instead of uid=testadmin,ou=internal,ou=people,dc=mydc.

Question
Is Luminary generally assuming that all users exist directly under ou=people? Or is this issue specific to ldap_is_group_member()?

Possible Resolution

1. If this is a general assumption that users must be directly under ou=people, document it.
2. Otherwise, if the issue is specific to ldap_is_group_member(), modify www/login/index.php (line 29) to have ldap_auth_username() return the full dn (result[0]['dn']), which can then be supplied to ldap_is_group_member() in line 30.

[wheelybird]

Thanks for reporting this. You're right, Luminary assumes members should be directly under ou=people, but this is a bug. Could you try container image wheelybird/luminary:v2.1.1? That (hopefully) has a fix.

[lukas-th]

Thank you for the quick response. Indeed v2.1.1 has resolved the issue.

Could there be any other places in luminary, where this is implicitly assumed or was ldap_is_group_member() the only place?

[wheelybird]

Yes, there are a few others. I'm adding fixes to the new branch and I'll update the container when done (and push a new release).

[wheelybird]

The new release has been published - if you pull the newer version of wheelybird/luminary:v2.1.1 it will hopefully solve your issue.