ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

Version 1/2 - Next » - Current version
Richard Sheppard, 2013-03-04 04:05 pm


LDAP Authentication

ChiliProject natively supports LDAP authentication using one or multiple LDAP directories.

Declaring the LDAP

Go to Administration -> Settings -> Authentication and click LDAP authentication, on the bottom right of the screen.

Enter the following:

  • Name: an arbitrary name for the directory
  • Host: the LDAP host name
  • Port: the LDAP port (default is 389)
  • LDAPS: check this if you want or need to use LDAPS to access the directory
  • Account: enter a username that has read access to the LDAP , otherwise leave this field empty if your LDAP can be read anonymously (Active Directory servers generally do not allow anonymous access)
  • Password: password for the account
  • Base DN: the top level DN of your LDAP directory tree
  • Login attribute: enter the name of the LDAP attribute that will be used as the ChiliProject username

ChiliProject users should now be able to authenticate using their LDAP username and password if their accounts are set to use the LDAP for authentication.

To test this, create a ChiliProject user with a login that matches his LDAP account, select the newly created LDAP in the Authentication mode drop-down list (this field is visible on the account screen only if a LDAP is declared) and leave his password empty. Try to log in into ChiliProject using the LDAP username and password.

On the fly user creation

By checking on-the-fly user creation, any LDAP user will have his ChiliProject account automatically created the first time he logs into ChiliProject.
For that, you have to specify the LDAP attributes name (firstname, lastname, email) that will be used to create their ChiliProject accounts.

Here is an typical example using Active Directory:

Name     = My Directory
Host     = host.domain.org
Port     = 389
LDAPS    = no
Account  = MyDomain\UserName (or UserName@MyDomain depending on AD server)
Password = <password>
Base DN  = CN=users,DC=host,DC=domain,DC=org

On-the-fly user creation = yes
Attributes
  Login     = sAMAccountName
  Firstname = givenName
  Lastname  = sN
  Email     = mail

Here is another example for Active Directory with a compartmentalized intranet:

Name     = Just a description for the auth modes page
Host     = DepartmentName.OrganizationName.local
Port     = 389
LDAPS    = no
Account  = DepartmentName\UserName (or UserName@MyDomain depending on AD server)
Password = <password>
Base DN  = DC=DepartmentName,DC=OrganizationName,DC=local

On-the-fly user creation = yes
Attributes
  Login     = sAMAccountName
  Firstname = givenName
  Lastname  = sN
  Email     = mail

Note that LDAP attribute names are case sensitive.

Base DN variants

Although it's quite possible that the Base DN above is standard for Active Directory, the Active Directory at my employer's site does not use the Users container for standard users, so those instructions sent me down a long and painful path. I recommend also trying just "DC=host,DC=domain,DC=org" if login fail swith the settings there.

Troubleshooting

If you want to use on-the-fly user creation, make sure that ChiliProject can fetch from your LDAP all the required information to create a valid user.
For example, on-the-fly user creation won't work if you don't have valid email adresses in your directory (you will get an 'Invalid username/password' error message when trying to log in).
(This is not true with newer ChiliProject versions; the user creation dialog is populated with everything it can find from the LDAP server, and asks the new user to fill in the rest.)

Also, make sure you don't have any custom field marked as required for user accounts. These custom fields would prevent user accounts from being created on the fly.

Errors in the login system are not reported with any real information in the ChiliProject logs, which makes troubleshooting difficult. However, I found most of the information I needed using Wireshark between my ChiliProject host and the LDAP server. Note that this only works if you have permissions to read network traffic between those two hosts (which was true for me because ChiliProject was running locally).

OpenDS

If you are using the OpenDS server, you might have issues with the request control "Paged results" sent with the initial query searching for the user by the specified login attribute. This request control 1.2.840.113556.1.4.319 is not allowed for anonymous users by default, thus preventing ChiliProject from finding the user in the directory even before the binding takes place.

Add a global ACI like this

./dsconfig -h SERVER_IP -p 4444 -D cn="Directory Manager" -w PASSWORD -n set-access-control-handler-prop --trustAll 
--add global-aci:\(targetcontrol=\"1.2.840.113556.1.4.319\"\)\ \(version\ 3.0\;\ acl\ 
\"Anonymous\ control\ access\ to\ 1.2.840.113556.1.4.319\"\;\ allow\ \(read\)\ userdn=\"ldap:///anyone\"\;\)
Note: Enter the command on one line, use the escaping exactly as indicated (the \ after "acl" is meant to be "\ " for a space).