Issue #221: Connection issue with ldap
| Reported by: | Alexandre Tarantini |
| State: | new |
| Created on: | 2016-05-31 09:05 |
| Updated on: | 2016-06-27 12:10 |
Description
When trying to connect to Microsoft ADAM 2008, Kallithea reject the connection. We don't have this issue on Microsoft LDAP 2008.
Logs :
2016-05-30 16:06:20.007 DEBUG [kallithea.lib.auth_modules.auth_ldap] Checking for ldap authentication
2016-05-30 16:06:20.008 DEBUG [kallithea.lib.auth_modules.auth_ldap] Trying simple_bind with password and given DN: CN=***,OU=***,O=***
2016-05-30 16:06:20.403 DEBUG [kallithea.lib.auth_modules.auth_ldap] Authenticating 'OU=***,O=***' filter (&(name=***)) at ldap://***:***
2016-05-30 16:06:20.512 DEBUG [kallithea.lib.auth_modules.auth_ldap] Trying simple bind with CN=***,OU=***,O=***
2016-05-30 16:06:20.835 DEBUG [kallithea.lib.auth_modules.auth_ldap] LDAP says no such user '' ()
2016-05-30 16:06:20.836 ERROR [kallithea.lib.auth_modules.auth_ldap] Traceback (most recent call last): File "/python/lib/python2.7/site-packages/kallithea/lib/auth_modules/auth_ldap.py", line 332, in auth log.debug('Got ldap DN response %s', user_dn) File "/python/lib/python2.7/site-packages/kallithea/lib/auth_modules/auth_ldap.py", line 168, in authenticate_ldap except ldap.SERVER_DOWN: LdapUsernameError
According to the source code, password check for user and BIND account is done but the server.search_ext_s() raise an exception with the user account on the ADAM : lib/auth_modules/auth_ldap.py
144 for (dn, _attrs) in lobjects: 145 if dn is None: 146 continue 147 148 try: 149 log.debug('Trying simple bind with %s', dn) 150 server.simple_bind_s(dn, safe_str(password)) 151 attrs = server.search_ext_s(dn, ldap.SCOPE_BASE, 152 '(objectClass=*)')[0][1] 153 break 154 155 except ldap.INVALID_CREDENTIALS: 156 log.debug("LDAP rejected password for user '%s' (%s): %s", 157 uid, username, dn) 158 159 else: 160 log.debug("No matching LDAP objects for authentication " 161 "of '%s' (%s)", uid, username) 162 raise LdapPasswordError() 163 164 except ldap.NO_SUCH_OBJECT: 165 log.debug("LDAP says no such user '%s' (%s)", uid, username) 166 raise LdapUsernameError() 167 except ldap.SERVER_DOWN: 168 raise LdapConnectionError("LDAP can't access authentication server")
If the ADAM user account don't have the permission to browse the ADAM, the authentication doesn't work. The actual code don't take care about this possibility of permission.
Workaround :
--- auth_ldap.py.orig 2016-05-31 09:21:54.409693248 +0200 +++ auth_ldap.py 2016-05-31 09:20:04.728703007 +0200 @@ -148,8 +148,7 @@ try: log.debug('Trying simple bind with %s', dn) server.simple_bind_s(dn, safe_str(password)) - attrs = server.search_ext_s(dn, ldap.SCOPE_BASE, - '(objectClass=*)')[0][1] + attrs = _attrs break except ldap.INVALID_CREDENTIALS:
Patch tested and working for us on the Microsoft ADAM 2008 and Microsoft LDAP 2008.
Attachments
Comments
Comment by Mads Kiilerich, on 2016-06-13 12:56
Thanks for the report and patch.
Effectively, this will loosen the requirement for being authenticated. It is enough to do a bind - it will no longer be a requirement that you must have access to "something". Do you agree this loosening in some setups could be a problem? Have you found any references (using python-ldap or in general) indicating that the old method was too restrictive and that your proposed method is right?
Comment by Alexandre Tarantini, on 2016-06-14 09:44
I think, it could be a problem on some others setups.
I'm not a developer, so, I didn't check on the documentation if my method is the best or not but it's just a workaround.
Thanks for your response.
Comment by Mads Kiilerich, on 2016-06-14 12:00
I think is a matter of knowing LDAP more than of being a developer ;-)
I would love to take the change if we can get evidence that it not only works for you but also is The Right Thing.
Comment by domruf, on 2016-06-14 16:12
A few questions:
- does the log really say
LDAP says no such user '' ()with empty '' and empty ()? Or did you remove the names? - I'm not familiar with ADAM. Do missing browsing permissions mean a user is not allowed to read his own attributes?
Comment by Alexandre Tarantini, on 2016-06-20 11:30
@domruf : I remove the names and I have no idea for your second question, I'm not a specialist on ADAM technology.
@kiilerix : I hope that a specialist will see this issue because I have no idea.
Comment by domruf, on 2016-06-24 13:33
Well I'm not a ADAM expert either. I only read the code and your log.
My understanding of this situation is that the user gets properly authenticated. But the users attributes we could only get with the 'admin' credentials. So the question is :Is it okay to use those attributes?
Comment by Alexandre Tarantini, on 2016-06-24 13:54
@domruf We must get users attributes with the bind account but it's in our case (it can works with a user account in a different environment I think). I have no idea if getting users attributes are mandatory on this line or not. In our environment, we have patched the software with my patch and we have no bug.
Comment by domruf, on 2016-06-24 18:24
Yes I'm sure the code works fine this way. But you kinda bypassed the ADAM security because you give the user the attributes which he would be able to get otherwise.
I can't think of a scenario where a user should not be allowed to know his own email address (or full name). So I'd like say it is okay. But still, working around the security settings doesn't feel exactly right.
Comment by Alexandre Tarantini, on 2016-06-27 12:10
I understand what you mean because with the bind account, we can fetch others accounts in ADAM. I'm not the administrator of this ADAM and in this environment, it's like what I explained before.
I think, you can let the code as it is but in your documentation, you can mention this patch if someone is in the same case.