Context Navigation

Modify ↓

#11307 closed enhancement (fixed)

Please support specifying full DN of group whose membership is required to log in

Reported by:	Andras Korn	Owned by:	Andras Korn
Priority:	normal	Component:	DirectoryAuthPlugin
Severity:	normal	Keywords:
Cc:		Trac Release:

Description

It is sometimes desirable to have LDAP groups used for trac access control in a separate subtree from groups used for e.g. role management (such as granting TRAC_ADMIN privileges).

Currently, the plugin doesn't support specifying group DNs anywhere; all groups are only referred to using their cn, which is not guaranteed to be unique if the search can span several subtrees.

Attachments (0)

Change History (13)

comment:1 Changed 9 years ago by bebbo

In 14830:

refs #12068
refs #11686
refs #11361
refs #11307
refs #11304
refs #10878
refs #10715
refs #10667
refs #10632
refs #10631
refs #11015

various fixes

comment:2 follow-up: 3 Changed 9 years ago by bebbo

Resolution:	→ fixed
Status:	new → closed

the group search base dn ist configured via group_basedn

comment:3 in reply to: 2 Changed 9 years ago by Andras Korn

Resolution:	fixed
Status:	closed → reopened

Replying to bebbo:

the group search base dn ist configured via group_basedn

Unfortunately that's insufficient. As explained in the Description, there may be several groups with the same cn under group_basedn; that's why it is necessary to be able to select a specific group by its full DN.

comment:4 Changed 9 years ago by branson

So that's not really possible. Groups are expanded into the Trac "namespace" by their CN. What you're suggesting has a few problems:

the nomenclature is "@" + {groupname} .. so "@admin". You can't use @{DN} as many DN's have spaces and that won't parse.

If you have multiple CN's with the same name under group_basedn .. with different permission models.. you'll have trouble. The search is going to return the first entry and use that on the lookup, and it's rather non-deterministic as to which one will come first. That's why we use a group_basedn to identify the top of the tree where we know it'd be right.

If you have this case.. i'd suggest you create a sub OU under group called Trac .. and then define your permissions there, unique to the definitions.

You could also explore other ways to resolve this:

allow more than one group_basedn to be defined, and the ordering of the definition would specify precedence. While this might work it's a penalty in search.. and will be complex.

comment:5 follow-up: 6 Changed 9 years ago by bebbo

btw: I dropped the '@' prefix since it caused trouble elsewhere... and I did not see any benefit of this prefix.

And I agree that a structured LDAP tree should have all trac groups as children/grandchildren/etc. under one ou node.

Thus specifying this sinlge ou as the group_basedn and with all permission groups having unique names there is no way for any duplicate.

comment:6 in reply to: 5 Changed 9 years ago by branson

Replying to bebbo:

btw: I dropped the '@' prefix since it caused trouble elsewhere... and I did not see any benefit of this prefix.

You might want to write a db update to migrate the permissions models for adopters that are using the current implementation. The use of '@' was the original configuration before I took on this plugin before; I left it that way as there were usernames that matched group names in AD... and there were also situations where local 'group' names may have been the same as AD group names (anonymous) .. and this was a good way to make sure the groups were uniquely identified.

Also helped identify the groups from the users... in my the last few implementations we had ~1500 users and ~300 groups. Doesn't hurt to separate it .. but will limit the implementations for some people and won't be backwards compatible unless you update the database as well.