Add LDAP authentication backend

LdapAuthStore? module

Password-checking mechanism

The newest ldap_store.py offers 3 ways: MD5, CRYPT, sasl binding (cram_md5) to check password.

Additional Setup

Leave the apache setting same as after AccountManager is installed. Don't follow LdapPlugin's apache setting.

Follow LdapPlugin's trac.ini setting. didn't use its Permission/Groups part. It requires customize attributes (tracperm) to be added to the LDAP server schema.

Disable AccountManager's old password store mechanism (such as acct_mgr.htfile.htdigeststore). acct_mgr.web_ui.registrationmodule should also be disabled as LDAPAuthStore doesn't offer functionality to add new user into LDAP server. acct_mgr.web_ui.registrationmodule checks whether the password store component has the set_password() function to decide its own enability.

Enable acct_mgr.ldap_store.LdapAuthStore? and set password_store = LdapAuthStore?.

Complete configuration. Change store_bind, bind_user according to your LDAP server

[account-manager]
#htdigest_realm = Trac Users
#password_file = /usr/local/digest
#password_format = htdigest
#password_store = HtDigestStore
;2008-03-17
password_store = LdapAuthStore

[components]
acct_mgr.admin.accountmanageradminpage = enabled
acct_mgr.api.accountmanager = enabled
;acct_mgr.htfile.htdigeststore = enabled
acct_mgr.web_ui.accountmodule = enabled
acct_mgr.web_ui.loginmodule = enabled
;acct_mgr.web_ui.registrationmodule = enabled
trac.web.auth.loginmodule = disabled
;2008-03-17
acct_mgr.ldap_store.LdapAuthStore = enabled
...

;2008-03-17
ldapplugin.* = enabled

...

[ldap]
;2008-03-17 for ldapplugin.* and LdapAuthStore
# enable LDAP support for Trac
enable = true
# enable TLS support
use_tls = false
# LDAP directory host
host = localhost
# LDAP directory port (default port for LDAPS/TLS connections is 636)
port = 389
# BaseDN
basedn = dc=example,dc=org
# Relative DN for users (defaults to none)
user_rdn = cn=users
# Relative DN for group of names (defaults to none)
group_rdn = cn=groups
# objectclass for groups
groupname = posixGroup
# dn entry in a groupname
groupmember = memberUid
# attribute name for a group
groupattr = cn
# attribute name for a user
uidattr = uid
# attribute name to store trac permission
permattr = tracperm
# filter to search for dn with 'permattr' attributes
permfilter = objectclass=*
# time, in seconds, before a cached entry is purged out of the local cache.
cache_ttl = 900
# maximum number of entries in the cache
cache_size = 100
# whether to perform an authenticated bind for group resolution
group_bind = false
# whether to perform an authenticated bind for permision store operations
store_bind = true
# user for authenticated connection to the LDAP directory
bind_user = bind_user_dn
# password for authenticated connection
bind_passwd = secret
# global permissions (vs. per-environment permissions)
global_perms = false
# group permissions are managed as addition/removal to the LDAP directory groups
manage_groups = false
# whether a group member contains the full dn or a simple uid
groupmemberisdn = false

...

[trac]
...
;permission_store = LdapPermissionStore
permission_store = DefaultPermissionStore

Author/Contributors

Author: naan

Contributors: crocea

1. reformat the code with tab replacing spaces; 2. change objectclass=simpleSecurityObject to object=*; 3. try sasl binding first in check_password()

Quick note: Both ldap_store.py versions may not work depending on the ldap layout: 1. using objectclass=simpleSecurityObject might not work, e.g. if you handle your users with a different objectclass, e.g. "account" 2. using objectclass=* triggers an ldap error if the returned result is "too long" (whatever that means), i.e. for big ldap setups

==> objectclass for user lookup must essentially be configurable. I'll post a solution if I find one.

It's quite usual for the whole LDAP search criteria to be configurable, then people can easily tailor it for the LDAP server and schema they are using.

Oh, it would also make sense to put (uid=*) in the default search query too, instead of doing:

m = re.match('uid=([^,]+)', user)

Not always the password is stored in the format "{hash_algorithm}password" where hash_algorithm is in upper case. Some time it is in lower case, and that makes the login fail.

some little change to the code should fix it (ldap_store.2.py:77)

mech = m.group(0)
if (mech == '{MD5}') or (mech=='{md5}'):
    password = mech + base64.encodestring(md5.new(password).digest()).rstrip()
elif (mech == '{CRYPT}') or (mech == '{crypt}'):
    password = mech + crypt.crypt(password, stored[7:9])

Thanks

Aragh0rn

Patch which fix uppercase and lowercase hash problem

Not all ldap uses sasl, like ebox. Try simple bind if sasl fails.

Modified patch to collect the two previous patches, and add set email and name session attributes from LDAP.

Removed my name, modified patch to collect the two previous patches, and add set email and name session attributes from LDAP.

Is it work ? I applied this patch to TracAccountManager?-0.2.1dev-py2.4.egg and get in "Manage user accounts" error message: This password store does not support listing users

And I dont see the "LdapPasswdStore?" section in plugin conf trought web interface.

It is working for me, can you please check your trac configuration, and try to describe the problem more clearly ? Also turn on debugging and see if there are any related messages there. I am not the original author of the patches, I just merged them and did a little modification.

Replying to iamer@open-craft.com:

It is working for me, can you please check your trac configuration, and try to describe the problem more clearly ? Also turn on debugging and see if there are any related messages there. I am not the original author of the patches, I just merged them and did a little modification.

Same dor me, it is not working. I am getting ERROR: Skipping "acct_mgr.ldap_store = acct_mgr.ldap_store": (can't import "No module named tracusermanager.api") inside my logfile. I am using trac 0.11.2 Might that bew the problem?

Installing the UserManagerPlugin resolved the issue

minor fix for handling utf8 names pulled from LDAP; you only need this patch (unless there is another account-manager-patch.X.patch below!) - just get AccountManager sources, patch them with this patch, and install AccountManager, then follow the instructions below.

I added the plugins: LdapPlugin UserManager? AccountManager (with attached patch)

and followed the recommended config. Here is what appears in my log file. Thanks for any help you can provide. Note that I probably snipped more than you need at the top.

2009-04-06 21:25:15,462 Trac[init] DEBUG: No policy allowed anonymous performing TICKET_CREATE on None 2009-04-06 21:25:15,463 Trac[init] DEBUG: No policy allowed anonymous performing TRAC_ADMIN on None 2009-04-06 21:25:15,463 Trac[init] DEBUG: No policy allowed anonymous performing PERMISSION_GRANT on None 2009-04-06 21:25:15,463 Trac[init] DEBUG: No policy allowed anonymous performing PERMISSION_REVOKE on None 2009-04-06 21:25:15,463 Trac[init] DEBUG: No policy allowed anonymous performing TICKET_ADMIN on None 2009-04-06 21:25:15,465 Trac[init] DEBUG: No policy allowed anonymous performing EMAIL_VIEW on None 2009-04-06 21:25:15,465 Trac[init] DEBUG: Retrieving session for ID '5538c15467edd61e55b7e5cc' 2009-04-06 21:25:15,507 Trac[init] DEBUG: 175 unreachable objects found. 2009-04-06 21:25:20,270 Trac[init] DEBUG: Dispatching <Request "POST u'/login'"> 2009-04-06 21:25:20,313 Trac[init] INFO: Sasl Failed, trying other. 2009-04-06 21:25:20,314 Trac[init] DEBUG: LDAPstore : Getting for name 2009-04-06 21:25:20,357 Trac[init] INFO: Sasl Failed, trying other. 2009-04-06 21:25:20,359 Trac[init] DEBUG: LDAPstore : Getting for name 2009-04-06 21:25:20,359 Trac[init] ERROR: list index out of range Traceback (most recent call last):

File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 233, in dispatch

self._post_process_request(req)

File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 301, in _post_process_request

f.post_process_request(req, *(None,)*extra_arg_count)

File "build/bdist.linux-x86_64/egg/acct_mgr/web_ui.py", line 205, in post_process_request File "/usr/lib/python2.4/site-packages/trac/web/api.py", line 169, in getattr

value = self.callbacks[name](self)

File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 131, in authenticate

authname = authenticator.authenticate(req)

File "build/bdist.linux-x86_64/egg/acct_mgr/web_ui.py", line 437, in wrap File "build/bdist.linux-x86_64/egg/acct_mgr/web_ui.py", line 447, in authenticate File "build/bdist.linux-x86_64/egg/acct_mgr/web_ui.py", line 474, in _remote_user File "build/bdist.linux-x86_64/egg/acct_mgr/api.py", line 140, in check_password File "build/bdist.linux-x86_64/egg/acct_mgr/ldap_store.py", line 99, in check_password

IndexError?: list index out of range 2009-04-06 21:25:20,361 Trac[init] ERROR: list index out of range

Follow up on my last post:

This error ONLY occurs when I use a valid username/pw. So if I try one that doesn't exist in the LDAP directory I just get an error on the login page saying invalid username or pw. But if I use a valid login I get the index out of range error. This suggests to me that I am being authenticated against my directory.

I have the same problem as vclark@globalera.com with error message:

IndexError?: list index out of range

I have LdapPlugin, UserManager? and AccountManager plugins with the account-manager-ldap.3.patch installed. If i login with right username/pass i become following in my browser:

Traceback (most recent call last):

File "/usr/local/lib/python2.6/site-packages/Trac-0.11.4-py2.6.egg/trac/web/api.py", line 367, in send_error

'text/html')

File "/usr/local/lib/python2.6/site-packages/Trac-0.11.4-py2.6.egg/trac/web/chrome.py", line 708, in render_template

data = self.populate_data(req, data)

File "/usr/local/lib/python2.6/site-packages/Trac-0.11.4-py2.6.egg/trac/web/chrome.py", line 618, in populate_data

dchrome?.update(req.chrome)

File "/usr/local/lib/python2.6/site-packages/Trac-0.11.4-py2.6.egg/trac/web/api.py", line 194, in getattr

value = self.callbacks[name](self)

File "/usr/local/lib/python2.6/site-packages/Trac-0.11.4-py2.6.egg/trac/web/chrome.py", line 476, in prepare_request

for category, name, text in contributor.get_navigation_items(req):

File "/usr/local/lib/python2.6/site-packages/Trac-0.11.4-py2.6.egg/trac/ticket/web_ui.py", line 163, in get_navigation_items

if 'TICKET_CREATE' in req.perm:

File "/usr/local/lib/python2.6/site-packages/Trac-0.11.4-py2.6.egg/trac/web/api.py", line 194, in getattr

value = self.callbacks[name](self)

File "/usr/local/lib/python2.6/site-packages/Trac-0.11.4-py2.6.egg/trac/web/main.py", line 264, in _get_perm

return PermissionCache?(self.env, self.authenticate(req))

File "/usr/local/lib/python2.6/site-packages/Trac-0.11.4-py2.6.egg/trac/web/main.py", line 133, in authenticate

authname = authenticator.authenticate(req)

File "build/bdist.linux-i686/egg/acct_mgr/web_ui.py", line 430, in wrap

return func(self, *args, **kwds)

File "build/bdist.linux-i686/egg/acct_mgr/web_ui.py", line 440, in authenticate

req.environREMOTE_USER? = self._remote_user(req)

File "build/bdist.linux-i686/egg/acct_mgr/web_ui.py", line 467, in _remote_user

if AccountManager(self.env).check_password(user, password):

File "build/bdist.linux-i686/egg/acct_mgr/api.py", line 140, in check_password

valid = store.check_password(user, password)

File "build/bdist.linux-i686/egg/acct_mgr/ldap_store.py", line 86, in check_password

value = unicode(value[0], 'utf-8')

IndexError?: list index out of range

Thanks for any help

I implemented a authentication store that primarily fetches LDAP account details such as email and password from AD or LDAP. The primary goal is to avoid entering information manually. This is meant to be used in a corporate setting that has AD/LDAP already deployed. My goal was to make this work well with Agilo. The entire user add/remove will be done in the context of a team. So I have stripped the UI parts out and Agilo will take care of adding/removing users.

Please note that this has NONE of the functionalities of the other patches.

I hope someone will find this useful!

Attachment: acct_mgr_ldap_agilo.patch

The same as account-manager-ldap.3.patch except with the addition of SSHA password support and a bugfix that others seem to have had trouble with. See comment below.

I have fixed a couple of issues in my installation:

• I have implemented SSHA password hashing. It works in my context, which is based on the smbldap toolset, which supplies a 'salt' length of 4. Works for me. YMMV.
• The 'Trac[init] ERROR: list index out of range', caused by the lack of one or other of the 'name' or 'email' fields from the [ldap] section of trac.ini. If you do use these, they should be set to the attributes used for the user's name and email address respectively. My fix means they don't have to be there.

attachment:account-manager-ldap.4.patch

Hope this helps someone.

Does it work in trac 0.10.3 ? I'm applied the patches manually, and copied the ldap_store.py to my accountmanager directory, build the .egg, but when I try to login, I get username or password incorrect. It's like it is searching for uid=anonymous, here is part of my ldaplog: conn=88 op=2 SRCH base="ou=users,dc=mysite,dc=org" scope=1 deref=0 filter="(uid=anonymous)"

Replying to sergiocharpinel@gmail.com:

Does it work in trac 0.10.3 ?

I don't know but I don't see why not. But I am no expert ... this is the second time I have set Trac up and the first time I have used LDAP on the back end. But I will help if I can.

when I try to login, I get username or password incorrect. It's like it is searching for uid=anonymous, here is part of my ldaplog: conn=88 op=2 SRCH base="ou=users,dc=mysite,dc=org" scope=1 deref=0 filter="(uid=anonymous)"

Can you post the [ldap] section of your trac.ini? (leave out bind_passwd)

Also, what LDAP mechanism are you connecting to? AD, or (like me) OpenLDAP or similar?

Replying to anonymous:

Replying to sergiocharpinel@gmail.com:

Does it work in trac 0.10.3 ?

I don't know but I don't see why not. But I am no expert ... this is the second time I have set Trac up and the first time I have used LDAP on the back end. But I will help if I can.

when I try to login, I get username or password incorrect. It's like it is searching for uid=anonymous, here is part of my ldaplog: conn=88 op=2 SRCH base="ou=users,dc=mysite,dc=org" scope=1 deref=0 filter="(uid=anonymous)"

Can you post the [ldap] section of your trac.ini? (leave out bind_passwd) Also, what LDAP mechanism are you connecting to? AD, or (like me) OpenLDAP or similar?

I'm using OpenLdap?. here is my conf:

enable = true host = localhost basedn = dc=mysite,dc=org user_rdn = ou=users uidattr = uid bind_user = cn=bind,dc=mysite,dc=org bind_passwd = **********

Replying to sergiocharpinel@gmail.com:

Ok can you set log_level = DEBUG in your trac.ini, try to log in, and then attach the resulting log to a new posting here?

No logs about it 2009-05-13 18:19:34,557 Trac[loader] DEBUG: Loading egg plugin ldapplugin.api from /var/trac/maquinas/plugins/LdapPlugin-0.5.1dev_r1611-py2.4.egg 2009-05-13 18:19:34,639 Trac[loader] DEBUG: Loading egg plugin webadmin.logging from /usr/lib/python2.4/site-packages/TracWebAdmin-0.1.2dev_r5911-py2.4.egg 2009-05-13 18:19:34,655 Trac[loader] DEBUG: Loading egg plugin webadmin.ticket from /usr/lib/python2.4/site-packages/TracWebAdmin-0.1.2dev_r5911-py2.4.egg 2009-05-13 18:19:34,805 Trac[loader] DEBUG: Loading egg plugin webadmin.basics from /usr/lib/python2.4/site-packages/TracWebAdmin-0.1.2dev_r5911-py2.4.egg 2009-05-13 18:19:34,810 Trac[loader] DEBUG: Loading egg plugin webadmin.perm from /usr/lib/python2.4/site-packages/TracWebAdmin-0.1.2dev_r5911-py2.4.egg 2009-05-13 18:19:34,817 Trac[loader] DEBUG: Loading egg plugin webadmin.web_ui from /usr/lib/python2.4/site-packages/TracWebAdmin-0.1.2dev_r5911-py2.4.egg 2009-05-13 18:19:34,820 Trac[loader] DEBUG: Loading egg plugin webadmin.plugin from /usr/lib/python2.4/site-packages/TracWebAdmin-0.1.2dev_r5911-py2.4.egg 2009-05-13 18:19:35,016 Trac[loader] DEBUG: Loading egg plugin acct_mgr.admin from /var/trac/maquinas/plugins/TracAccountManager-0.1.3dev_r5273-py2.4.egg 2009-05-13 18:19:35,558 Trac[loader] DEBUG: Loading egg plugin acct_mgr.db from /var/trac/maquinas/plugins/TracAccountManager-0.1.3dev_r5273-py2.4.egg 2009-05-13 18:19:35,579 Trac[loader] DEBUG: Loading egg plugin acct_mgr.htfile from /var/trac/maquinas/plugins/TracAccountManager-0.1.3dev_r5273-py2.4.egg 2009-05-13 18:19:35,605 Trac[loader] DEBUG: Loading egg plugin acct_mgr.http from /var/trac/maquinas/plugins/TracAccountManager-0.1.3dev_r5273-py2.4.egg 2009-05-13 18:19:35,610 Trac[loader] DEBUG: Loading egg plugin acct_mgr.ldap_store from /var/trac/maquinas/plugins/TracAccountManager-0.1.3dev_r5273-py2.4.egg 2009-05-13 18:19:35,620 Trac[loader] DEBUG: Loading egg plugin acct_mgr.pwhash from /var/trac/maquinas/plugins/TracAccountManager-0.1.3dev_r5273-py2.4.egg 2009-05-13 18:19:35,623 Trac[loader] DEBUG: Loading egg plugin acct_mgr.web_ui from /var/trac/maquinas/plugins/TracAccountManager-0.1.3dev_r5273-py2.4.egg 2009-05-13 18:19:35,626 Trac[loader] DEBUG: Loading egg plugin acct_mgr.api from /var/trac/maquinas/plugins/TracAccountManager-0.1.3dev_r5273-py2.4.egg 2009-05-13 18:19:42,024 Trac[api] DEBUG: new: [] 2009-05-13 18:19:42,043 Trac[cache] INFO: Check for sync [90] vs. cached [90]

Replying to anonymous:

No logs about it

Ok, it seems to assume in the code that you will be using groups for getting Trac permissions as well as just authentication. There is a line in ldapplugin/api.py which appears to indicate that an anonymous bind will be used if group_bind is not set:

            # new LDAP connection
            bind = self.config.getbool('ldap', 'group_bind')
            self._ldap = LdapConnection(self.env.log, bind, **self._ldapcfg)

This makes sense given that the author of this module has done a minimal integration (i.e. hack) with LdapPlugin to get authentication working. IMHO this is a really useful feature where LDAP users are concerned and maybe it should be integrated fully, perhaps with the authentication option isolated from the rest of the groups and store functionality. But that's not the case for right now, and you might end up having to use at least the groups functionality in LdapPlugin in order to get the authentication hack to work. I wouldn't worry though, it works great, and you were probably planning to do it anyway. Most people I imagine will be doing it the other way to you: getting the ldap group functionality working with HTTP authentication, then adding in LDAP authentication, in which case everything would be set up correctly already. Try setting group_bind = true and see if you get any further. You may have to set other group-related settigs as well. Here is my trac.ini [ldap] section:

[ldap]
basedn = dc=*****,dc=com
bind_passwd = *****
bind_user = cn=Manager,dc=*****,dc=com
enable = true
group_bind = true
group_rdn = ou=Groups
groupmember = memberUid
groupmemberisdn = false
groupname = posixGroup
manage_groups = true
name = cn
permattr = tracperm
permfilter = objectClass=tracuser
store_bind = true
user_rdn = ou=Users

As you can see I am using ldap for group membership info, and to store permissions. It seems to be working great for me.

Patch for ldap_store.2.py for Trac 0.10 and fix {crypt} encryption

I just changed the log funtions to log in trac 0.10 and fixed the crypt funtion (it was taking just the first 2 letters to make the encryption, whereas wasnt working for me). And included SSHA and Invalid credential fix, that was already implemented in others patches.

Please create a separate plugin for this backend. I'd rather not add the extra dependencies that this requires, but it could benefit from being in version control and having its own issue list. It should make it easier if users can install that plugin rather than trying to keep track of the all these patches.

Patch for ldap_store.2.py for Trac 0.10 and fix {crypt} encryption and adds filter option in ldap

After noting that we are using the account-manager-ldap.4.patch, which added support for SSHA, I think we are having a problem with certain variants of SSHA, particularly longer versions generated by the luma LDAP client and the Mandriva directory server. #5485 describes our issue, however if the decrypt happens in account manager, we now believe this issue may have its roots here. Perhaps fatalflaw has some insight on the initial support for SSHA.

Adds 'basedn_filter' option to [ldap] section for LDAP search filter (default is objectclass=*). Fix MySQL error when log in with same user. SSHA and CRYPT working for "longer versions" (decrypt function from OpenLDAP site).

Replying to ian@ianbmacdonald.com:

Perhaps fatalflaw has some insight on the initial support for SSHA.

Looks as if Sergio has already taken care of it.

Replying to JimPage:

Looks as if Sergio has already taken care of it.

Great, I can see the improved SSHA handling grabing all but the 20 byte digest to obtain the salt rather than a specific byte-count for the salt. Merging just

+                challenge_bytes = base64.decodestring(stored[6:])
+                salt = challenge_bytes[20:]
}}} allows the 16byte salt luma uses in its SSHA to work, but the longer MDS salt (20 bytes) still fails. I assume ldap_store.3.py fixes this too as Sergio makes reference to length as opposed to just the salt, however I am getting an error at run-time when I apply the whole file so unable to test.

I am applying the ldap_store.3.py on top of current 0.11-r6159 patched with account-manager-ldap.4.patch.

{{{
Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/trac/web/api.py", line 339, in send_error
    'text/html')
  File "/usr/lib/python2.5/site-packages/trac/web/chrome.py", line 684, in render_template
    data = self.populate_data(req, data)
  File "/usr/lib/python2.5/site-packages/trac/web/chrome.py", line 592, in populate_data
    d['chrome'].update(req.chrome)
  File "/usr/lib/python2.5/site-packages/trac/web/api.py", line 169, in __getattr__
    value = self.callbacks[name](self)
  File "/usr/lib/python2.5/site-packages/trac/web/chrome.py", line 460, in prepare_request
    for category, name, text in contributor.get_navigation_items(req):
  File "/usr/lib/python2.5/site-packages/trac/ticket/query.py", line 734, in get_navigation_items
    if 'TICKET_VIEW' in req.perm and \
  File "/usr/lib/python2.5/site-packages/trac/web/api.py", line 169, in __getattr__
    value = self.callbacks[name](self)
  File "/usr/lib/python2.5/site-packages/trac/web/main.py", line 254, in _get_perm
    return PermissionCache(self.env, self.authenticate(req))
  File "/usr/lib/python2.5/site-packages/trac/web/main.py", line 131, in authenticate
    authname = authenticator.authenticate(req)
  File "build/bdist.linux-x86_64/egg/acct_mgr/web_ui.py", line 437, in wrap
    return func(self, *args, **kwds)
  File "build/bdist.linux-x86_64/egg/acct_mgr/web_ui.py", line 447, in authenticate
    req.environ['REMOTE_USER'] = self._remote_user(req)
  File "build/bdist.linux-x86_64/egg/acct_mgr/web_ui.py", line 474, in _remote_user
    if AccountManager(self.env).check_password(user, password):
  File "build/bdist.linux-x86_64/egg/acct_mgr/api.py", line 140, in check_password
    valid = store.check_password(user, password)
  File "build/bdist.linux-x86_64/egg/acct_mgr/ldap_store.py", line 72, in check_password
    stored = p[0]
IndexError: list index out of range
}}}

Seems like your LDAP search is not getting userPassword attribute. You dont know your LDAP trre, but maybe your bind is not correct, or you need a filter (basedn_filter).

I didnt understand what you did. You just need to copy the file into acct_mgr folder (rename it to ldap_store.py), add 'acct_mgr.ldap_store = acct_mgr.ldap_store', to setup.py and build it. If it still not working, put self.log.debug commands to investigate why it is not getting results.

I'm having trouble setting this up.. Does this or does this not allow ldap authentication via the html login form? Also I don't allow anonymous binds to server and instead have a system 'authenticate' account to which the bind_user can't seem to bind with:

Jul 21 11:05:04 codedef httpd: PHP Notice: Undefined index: preview in /srv/web/hosts/blog.codedef.com/public_html/include/common.php on line 53 Jul 21 11:08:59 codedef slapd[10252]: conn=288 fd=27 ACCEPT from IP=127.0.0.1:56271 (IP=0.0.0.0:389) Jul 21 11:08:59 codedef slapd[10252]: conn=288 op=0 BIND dn="uid=authenticate" method=128 Jul 21 11:08:59 codedef slapd[10252]: conn=288 op=0 RESULT tag=97 err=49 text= Jul 21 11:08:59 codedef slapd[10252]: conn=288 op=1 UNBIND Jul 21 11:08:59 codedef slapd[10252]: conn=288 fd=27 closed Jul 21 11:08:59 codedef slapd[10252]: conn=289 fd=27 ACCEPT from IP=127.0.0.1:56272 (IP=0.0.0.0:389) Jul 21 11:08:59 codedef slapd[10252]: conn=289 op=0 BIND dn="uid=authenticate" method=128 Jul 21 11:08:59 codedef slapd[10252]: conn=289 op=0 RESULT tag=97 err=49 text= Jul 21 11:08:59 codedef slapd[10252]: conn=289 op=1 UNBIND Jul 21 11:08:59 codedef slapd[10252]: conn=289 fd=27 closed Jul 21 11:08:59 codedef slapd[10252]: conn=273 op=2 UNBIND Jul 21 11:08:59 codedef slapd[10252]: conn=273 fd=24 closed

This is what is currently happening on login (form) and then it throws a python error: (partial text)

File "build/bdist.linux-i686/egg/ldapplugin/api.py", line 577, in get_dn

sr = self._search(basedn, filterstr, dn?, ldap.SCOPE_SUBTREE)

File "build/bdist.linux-i686/egg/ldapplugin/api.py", line 660, in _search

self._open()

File "build/bdist.linux-i686/egg/ldapplugin/api.py", line 653, in _open

raise TracError?("Unable to open LDAP cnx: %s" % e[0]desc?)

TracError?: Unable to open LDAP cnx: Invalid credentials

Is there some concise list of tasks to perform on a new install of TRAC to get AccountManager working with LDAP? This forum seems to be focused on fixing bugs in existing installs.

Replying to mgood:

Please create a separate plugin for this backend. I'd rather not add the extra dependencies that this requires, but it could benefit from being in version control and having its own issue list. It should make it easier if users can install that plugin rather than trying to keep track of the all these patches.

A huge +1 to this idea. Let's get out of the realm of insanity, peoples!

Replying to mgood:

Please create a separate plugin for this backend. I'd rather not add the extra dependencies that this requires, but it could benefit from being in version control and having its own issue list. It should make it easier if users can install that plugin rather than trying to keep track of the all these patches.

I've packaged this up at LdapAuthStorePlugin. It doesn't work for me and I don't really want to maintain it, but I figured it should better live there as a real versioned resource than as an attachment on a ticket with over 30 comments. Please feel free to contact me and adopt it.

#1600 has another version of this that simplifies most of the password handling but lacks cache support, if anyone is up to doing forward porting and testing.

how can we get rid of all this spam comments?

Replying to diroussel:

how can we get rid of all this spam comments?

Done.

dang how the heck do you unsubscribe from this spammed ticket