LdapPlugin: user_rdn support for users in several OUs?

52 views
Skip to first unread message

Jim Page

unread,
Jun 6, 2007, 3:40:54 AM6/6/07
to trac-...@googlegroups.com

Morning All

 

My problem: I am using LdapPlugin to manage my Trac permissions, and it’s great. However our AD structure has users assigned to various different OUs, Technical, Sales, Management and so on. The Groups I am using to assign permissions are in the Technical OU (which I set up in group_rdn), and all works fine, as long as the users themselves are in the OU I set up in the ‘user_rdn=’ config entry. But there are several users in other OUs I would like to allow in, including (rather urgently) the Technical Manager (who is in OU=Management). Is this currently supported in any way?  Grasping at straws, I tried ‘OU=*’ in user_rdn J but it didn’t work of course.

 

All help gratefully received.

 

In the event that this is not currently supported, I am considering the idea of patching LdapPlugin to allow an array of RDNs in user_rdn – anyone care to comment on that idea, is it a desirable feature for anyone except me? Is there a better way to do this?

 

All the best

Jim

 

Jim Page

Chief Technical Architect

Email Systems Ltd

Telephone: +44 (0) 870 141 7070

Facsimile: +44 (0) 870 141 8080

www.emailsystems.com - robust messaging technology

 

Wilson, Bruce E.

unread,
Jun 6, 2007, 1:58:10 PM6/6/07
to trac-...@googlegroups.com
We're using LDAP as well.  It's a bit of a hack, but what I've done is use an Include file that has a set of require user and require group directives.  I've built a database table, and the list is generated from that table with a cron job.  Doing it this way -- with the include file -- lets me use the same file in both the SubVersion section of the conf files and the Trac section.  I'm actually managing three different SubVersion repositories and two related Trac instances.

============================================================
Bruce E. Wilson (wils...@ornl.gov)
Environmental Sciences Division
Oak Ridge National Laboratory
 


From: trac-...@googlegroups.com [mailto:trac-...@googlegroups.com] On Behalf Of Jim Page
Sent: Wednesday, June 06, 2007 3:41 AM
To: trac-...@googlegroups.com
Subject: [Trac] LdapPlugin: user_rdn support for users in several OUs?

Jim Page

unread,
Jun 6, 2007, 6:04:48 PM6/6/07
to trac-...@googlegroups.com

Hi Bruce

 

Thanks for the reply Bruce, but if I understand your reply correctly, it solves a different problem to mine.

 

Are you describing a way of getting LDAP authentication working in apache? Strangely enough, I am having no problem with that side of it, all my users can log in fine to both subversion and trac using ‘AuthBasicProvider ldap’ etc, and I have groups set up for Trac users and Subversion users, and use ‘require ldap-group <blah>’. It doesn’t seem to matter what OU the users are under for the apache http authentication to work as long as they are members of the right group.

 

The problem I am trying to solve is trying to get the Trac LdapPlugin to assign Trac permissions to users based on their LDAP group memberships. I have permissions assigned (via trac-admin) to various groups (TracAdmin, TracUser, TracGuest etc); everything works as long as the Users are in the OU I specify in user_rdn (in trac.ini). The trouble is I want to admit users in different OUs. When a User logs in to Trac who is in the right group but not in the right OU, trac loads (ie apache http authentication works) but with no permissions set (empty menu bar, front page message ‘403 Forbidden (WIKI_VIEW privileges are required to perform this operation)’, ie LdapPlugin group permissions is broken.

 

My working theory for why Apache LDAP group authentication works and Trac LdapPlugin doesn’t is that apache LDAP looks for the User in the group’s ‘member’ attributes. LdapPlugin looks at the User’s ‘memberOf’ attributes to look up the groups the user belongs to, ie back to front compared to apache. Apache only needs to know the CN of the group (which is supplied in ‘require ldap-group’) whereas the LdapPlugin needs to know where the groups are AND where the Users are, but will only look in <user_rdn>,<base_dn> for Users; if a given User is not in this branch then the lookup will fail. A similar problem would exist if the Groups themselves were in different OUs.

 

So it looks like I have 2 options:

 

1)       some guru tells me how to set it up properly using the existing version

2)       I patch the plugin to allow more than one user_rdn setting, perhaps using an array

 

Ideas, anyone?

 

Thanks again

Jim

 


<BR

Jim Page

unread,
Jun 6, 2007, 8:00:07 PM6/6/07
to trac-...@googlegroups.com, emmanu...@free.fr

Hi Again

 

I decided to have a go at fixing my issue by patching the plugin source. Apologies to real python programmers – this is my first attempt at python programming and probably contains many discordant stylistic errors. Nevertheless it works for my setup, and may work for someone else’s – your mileage may vary, etc. Here are the issues this patch solves:

 

·         _get_user_groups: on my system, self._ldap.get_groups returns empty groups, i.e. list members of value ‘None’. This causes the code to stack trace. This patch adds an ‘if group!=None:’ statement to step over empty groups.

·         _get_user_groups: I added some debug output from this function to help debug my setup. It is commented out in the patch.

·         get_groups: modified this function to use the group_rdn config setting, so that only the effective groupdn is searched for groups, rather than the whole hierarchy; on my setup this made 10 seconds or so of difference as we have around 100 groups in our directory, only 4 of which we are interested in. NB this may not be the right thing to do!

·         user_attrdn: modified to handle multiple user_rdn values, to accommodate Users in different LDAP containers. The function was modified to return an array of DNs in all cases, multiple cases being the result of splitting the user_rdn config setting using the delimiter ‘|’. Even if (after splitting) there is only one item generated, a singleton list is still returned; this is to simplify the calling code (_get_user_groups) which has been modified to handle list return values instead of strings. This allows user_rdn to be set like:

 

user_rdn = <rdn0>[|<rdnx>]*

 

for example:

 

user_rdn = ou=technical|ou=management|ou=sales

 

The patch is an svn diff of ldapplugin/api.py taken from my working copy against version 2262 on your subversion server. I have attached it as a text file.

 

Hope this helps someone.

 

Cheers

Jim

 


From: Jim Page
Sent: 07 June 2007 00:05
To: 'trac-...@googlegroups.com'
Subject: RE: [Trac] Re: LdapPlugin: user_rdn support for users in several OUs?

 

Hi Bruce

 

Thanks for the reply Bruce, but if I understand your reply correctly, it solves a different problem to mine.

 

Are you describing a way of getting LDAP authentication working in apache? Strangely enough, I am having no problem with that side of it, all my users can log in fine to both subversion and trac using ‘AuthBasicProvider ldap’ etc, and I have groups set up for Trac users and Subversion users, and use ‘require ldap-group <blah>’. It doesn’t seem to matter what OU the users are under for the apache http authentication to work as long as they are members of the right group.

 

The problem I am trying to solve is trying to get the Trac LdapPlugin to assign Trac permissions to users based on their LDAP group memberships. I have permissions assigned (via trac-admin) to various groups (TracAdmin, TracUser, TracGuest etc); everything works as long as the Users are in the OU I specify in user_rdn (in trac.ini). The trouble is I want to admit users in different OUs. When a User logs in to Trac who is in the right group but not in the right OU, trac loads (ie apache http authentication works) but with no permissions set (empty menu bar, front page message ‘403 Forbidden (WIKI_VIEW privileges are required to perform this operation)’, ie LdapPlugin group permissions is broken.

 

My working theory for why Apache LDAP group authentication works and Trac LdapPlugin doesn’t is that apache LDAP looks for the User in the group’s ‘member’ attributes. LdapPlugin looks at the User’s ‘memberOf’ attributes to look up the groups the user belongs to, ie back to front compared to apache. Apache only needs to know the CN of the group (which is supplied in ‘require ldap-group’) whereas the LdapPlugin needs to know where the groups are AND where the Users are, but will only look in <user_rdn>,<base_dn> for Users; if a given User is not in this branch then the lookup will fail. A similar problem would exist if the Groups themselves were in different OUs.

 

So it looks like I have 2 options:

 

1)       some guru tells me how to set it up properly using the existing version

2)       I patch the plugin to allow more than one user_rdn setting, perhaps using an array

 

Ideas, anyone?

 

Thanks again

Jim

 


From: trac-...@googlegroups.com [mailto:trac-...@googlegroups.com] On Behalf Of Wilson, Bruce E.


Sent: 06 June 2007 19:58
To: trac-...@googlegroups.com

<BR

LdapPlugin-api.py-2262-group_rdn-patch.txt

Emmanuel Blot

unread,
Jun 6, 2007, 8:04:01 PM6/6/07
to trac-...@googlegroups.com
Hi Jim,

There is an issue here: how to ensure that entries are unique?

The problem is that to build a distinguished name (DN), you need the
username, plus a RDN.
As long as there is a single RDN defined in the plugin configuration
that is used to build the DN, we can guarantee that a single username
always maps to one unique DN in the LDAP directory (and vice-versa
from the LdapPlugin perspective)

If you start adding several RDN to build a DN (whatever the way it is
implemented), this condition cannot be guaranteed anymore.

In other words, if there is one "joe.user" in OU=Technical and another
"joe.user" in OU=Management, there is no way to distinguish one from
the other, and the permission system would be compromised, one group
being picked at random by the system.

In order to make it work, you'll have to be sure that there are no two
"joe.user" users registered in your enterprise directory, or at least
in the common subtree of all RDNs.

This kind of bypass the role of the DN in a LDAP directory. You could
nevertheless implement such a hack where the plugin would use a list
of RDN instead of a single one, and build several DNs with each RDN,
and stop on the first match.
Keep in mind that this may represent a security issue.

HTH,
Cheers,
Manu (main author of the LdapPlugin)

Jim Page

unread,
Jun 6, 2007, 8:25:02 PM6/6/07
to trac-...@googlegroups.com
Hi Manu

Yes, I did see that, though I suppose you could argue that there would
only really be a problem if, for example, there were 2 John Smiths in 2
different Trac permission groups, or one in a group and one not in a
group ... they would also both have to be in the RDNs specified in
user_rdn. It would certainly be easy to demonstrate the problem, but how
often in reality you would have it I don't know.

My guess is that it would be hard to get around this, since once John
Smith is logged in (via LDAP/authz) the information as to which of the
John Smiths is logged in, ie the rest of the DN after the username, is
lost. Without having that information I don't see how this can ever be
'properly' fixed unfortunately.

I think it's a call individual sysadmins need to make; for me the
advantages of supporting users in multiple containers outweighs the
security implication because I'm pretty certain it's never going to be a
problem in our case.

By the way - the LdapPlugin is an absolutely excellent tool and makes a
huge difference to me in managing Trac. I congratulate you! My intention
is not to complain, but to help make an already great tool work better
for me. I have just posted a patch to the forum - by all means take some
or all of it, if you like it, for the benefit of mankind, or feel free
to throw it away.

All the best
Jim

-----Original Message-----
From: trac-...@googlegroups.com [mailto:trac-...@googlegroups.com]
On Behalf Of Emmanuel Blot
Sent: 07 June 2007 02:04
To: trac-...@googlegroups.com
Subject: [Trac] Re: LdapPlugin: user_rdn support for users in several
OUs?

Emmanuel Blot

unread,
Jun 6, 2007, 8:36:06 PM6/6/07
to trac-...@googlegroups.com
> By the way - the LdapPlugin is an absolutely excellent tool and makes a
> huge difference to me in managing Trac. I congratulate you! My intention
> is not to complain, but to help make an already great tool work better
> for me. I have just posted a patch to the forum - by all means take some
> or all of it, if you like it, for the benefit of mankind, or feel free
> to throw it away.

Thanks for the patch.
Improvements are always welcomed as they may help other users.

Could you fill in a ticket on trac-hacks.org against LdapPlugin, and
attach your patch to the ticket? I think it will be easier for the
plugin users to find you patch rather than searching the MailingList.

I can't tell you now whether I will merge this patch to the plugin or
not (this security issue may be a show stopper), but at least it will
be easy for other users to take advantage from your patch.

I've not been working on this plugin for a while (it was my first Trac
plugin) as I'm no longer needs it, but I think it deserves many
improvements. There are already several patches to merge.

Cheers,
Manu

Jim Page

unread,
Jun 6, 2007, 9:04:22 PM6/6/07
to trac-...@googlegroups.com
> Could you fill in a ticket on trac-hacks.org against LdapPlugin, and
> attach your patch to the ticket? I think it will be easier for the
> plugin users to find you patch rather than searching the MailingList

Done, tickets #1622 and #1623

Reply all
Reply to author
Forward
0 new messages