Thanks Robert, time for me to post my thoughts. (These might be turned into a document later...)

So there are several ways of doing 'LDAP groups'. I don't think they oppose each other (we can do multiple ways) but I want to make sure that when someone talks about 'LDAP groups' we are clear which type they are talking about.

LDAP Synchronization of Groups and Users¶

This copies LDAP groups into ChiliProject with their members. So you end up with identical users and groups in both systems.

This means ChiliProject will need to extract the group data and also send updates to LDAP when users/grouped are added/removed/edited. Pushing the changes into LDAP could be difficult because typically LDAP systems are more restrictive than ChiliProject would be.

LDAP Group Mirroring¶

This is similar to synchronization but is more one-way (from LDAP to ChiliProject). In my opinion this could be a step towards a two-way synchronization.

Auth Source Groups¶

This addition is purely in ChiliProject. It makes all users from a specific Auth Source a member of a group when they are created (multiple groups too). Since LDAP is a type of AuthSource, this lets you define "all users logging in from 'LDAP Source 1' become members of the 'Employee' group in ChiliProject".

This is mostly a time saving feature, so admins don't have to manually add people to Groups after they login.

I have working code for this.

Custom LDAP Queries¶

This isn't totally about LDAP groups but I have a client using it with them with a lot of success. When combined with Auth Source Groups (above) it is effectively mirroring LDAP groups into his ChiliProject.

What this does is allows an admin to define a stricter LDAP query for finding users for each Auth Source. So you can have two different Auth Sources:

• Employees - query by LDAP group=employee
• Contractors - query by LDAP group=contractor

So when a Contractor logs in, they match up in LDAP with the "Contractors" AuthSource and (using Auth Source groups above) get put into the ChiliProject Contractor group automatically. This is a bit of a hack but it is really flexible because it lets the admin control the queries so they can filter however they want (e.g. by domains, by custom attributes, etc).

I have working code for this.

(I also have some rake scripts that can be used to "refresh" some LDAP data in ChiliProject.)

I'm sure there are a few other ways for LDAP groups, but I can't remember them right now. I don't use LDAP so I'm not very familiar with the different set ups of it.

Eric Davis

Eric Davis wrote:

Custom LDAP Queries¶

This isn't totally about LDAP groups but I have a client using it with them with a lot of success. When combined with Auth Source Groups (above) it is effectively mirroring LDAP groups into his ChiliProject.

What this does is allows an admin to define a stricter LDAP query for finding users for each Auth Source. So you can have two different Auth Sources:

• Employees - query by LDAP group=employee
• Contractors - query by LDAP group=contractor

So when a Contractor logs in, they match up in LDAP with the "Contractors" AuthSource and (using Auth Source groups above) get put into the ChiliProject Contractor group automatically. This is a bit of a hack but it is really flexible because it lets the admin control the queries so they can filter however they want (e.g. by domains, by custom attributes, etc).

One caveat I see with this: You're only part of the first authsource/query that matches.

Felix Schäfer wrote:

One caveat I see with this: You're only part of the first authsource/query that matches.

Exactly. It's used in an environment where each LDAP user only belongs to one group. With multiple groups it would be problematic as it's based on the order of the records.

Eric Davis

May I give my take on this:

you're a user in a LDAP store, associated with one or more groups. Eg. I'm a user in our Active Directory and I am a member of developers, support and UK groups.

As an admin, I would want to create Chili groups that have LDAP group names associated with them (eg, chiliDev = developers).

When I log in, the system would recognise the groups I'm a member of, match them to the chili-defined groups and add (or remove) me to them automatically.

That's it. I don't want 2-way sync as my AD admin will not let that happen (and I think you'll get the same response from every corporate user). I don't want Chili to automatically create groups based on LDAP settings as they would not be appropriate (all those internal mail groups...). I do want to configure Chili for those groups that I need though, which would be solved by the assign-on-login solution I suggest above.

I'm looking at MediaWiki which has LDAP support and allows access based on group membership. I don't think it queries LDAP based on the specified groups, but on the user logging in.

My old ldapsearch script does this to get a full list of 'memberOf' groups.

ldapsearch -b "DC=domain,DC=com" -h <ip> -x -W -D "CN=admin,OU=Service Accounts,OU=Western,OU=Europe,DC=domain,DC=com" -LLL "(sAMAccountName=me)" objectClass memberOf
(where ip is the server ip address, 'admin' is the user that access to perform LDAP search queries, 'me' is my userid.

The same one we use for several projects, I mean the ldapsearch construct. This one makes it easy to say, which person can use which project.