Kallithea issues archive

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


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
    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
    155                 except ldap.INVALID_CREDENTIALS:
    156                     log.debug("LDAP rejected password for user '%s' (%s): %s",
    157                               uid, username, dn)
    159             else:
    160                 log.debug("No matching LDAP objects for authentication "
    161                           "of '%s' (%s)", uid, username)
    162                 raise LdapPasswordError()
    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 @@
                     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

                 except ldap.INVALID_CREDENTIALS:

Patch tested and working for us on the Microsoft ADAM 2008 and Microsoft LDAP 2008.



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:

  1. does the log really say LDAP says no such user '' () with empty '' and empty ()? Or did you remove the names?
  2. 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.