Details
-
Bug
-
Resolution: Fixed
-
Major
-
None
-
None
-
Debian GNU/Linux 7 (wheezy), Observium r5164, Windows Active Directory (servers 2008, 2008 r2, 2012)
Description
When logging in using LDAP authentication access level is always 0.
I have narrowed this down to auth_user_level function not being called or exiting at the if statement.
The easiest way for me to confirm this was to add a
print_debug(echo("auth_user_level is running"));
|
just inside the if and enable debugging. While the rest of the LDAP debugging displayed, this never echoed to the screen, the group(s) never displayed, and the user(s) never were granted an access level higher than 0
I have attached the sanitized ldap section of my config.php. I altered none of the lines beyond swapping domain names and passwords.
Attachments
Activity
Here is a version 2 of the patch that fixes permissions (user id lookup) for level 1 users.
This has only been tested against active directory and my or may not break other ldap instances.
When logging in as a level 1 user no access is granted to any of the allowed devices or interfaces still. Upon further inspection this is because it is looking for a user with the ID of "-1" When logging in as a level 10 user I can verify that the user id of all the level 1 and level 10 users is set correctly to the last portion of their objectSID from Active Directory so it is something later, building the query or setting the session that is still broken.
I guess that the actual problem is that there is a backslash in there to escape a comma, but in Active directory the backslash in a LDAP filter needs to be represented by it's hex equivalent https://social.technet.microsoft.com/wiki/contents/articles/5312.active-directory-characters-to-escape.aspx#LDAP_Filters in order to match. By adding slashes, escaping, the backslash in the existing \5C it preserves the filter.
Just in case your curious here is the string that was the problem:
Here is how it looks to a human
(member=CN=Seal\, Solomon,OU=Users_FacStaff,DC=domain,DC=edu)
|
and here is how the system was seeing it
(member=CN=Seal\5C, Solomon,OU=Users_FacStaff,DC=domain,DC=edu)
|
Escaping the slashes fixed it up nicely.
Found the problem and have attached a patch, in Active Directory some backslashes needed escaped. i haven't tested this on a non windows system, but if it isn't safe enough to implement as is you could always check against the $config['auth_ldap_attr']['uid'] for sAMAccountname before you escape the slashes.
No, same as before. When I enable debugging it never show that it is lopping through my groups. It never outputs anything ldap related to the screen upon login and I have level 0 permissions. Running r5299
I want to reiterate that users are able to login without issue. The primary group is being checked and if removed logins fail. It is only the settings of levels that is not working.
Yah, we so long not answered to this issue, but as I see escaping ldap filter issue already fixed for a long time.