[horde] Active Directory - Kronolith Calendar Group Permissions

Mike Peachey mike.peachey at jennic.com
Fri Jan 18 12:28:44 UTC 2008


Mike Peachey wrote:
> X-Relates-To: Kronolith
> X-Relates-To: Active Directory
> X-Relates-To: Group Permissions
> 
> Since I am using AD for LDAP authentication, I cannot set group 
> permissions on a calendar. The reason for this is that the "Select a 
> group to add:" combo box does not populate with the group data. I have 
> discovered, through a little debugging, that the cause for this is a 
> subtle difference between OpenLDAP and Active Directory and how member 
> information is stored.
> 
> By default, Kronolith is set-up to only list the groups of which the 
> current logged-in user is a member, so you would only see groups listed 
> that you are a member of, however in order to do this, it sets a filter 
> on the LDAP search of the form member=$username (or - more precisely 
> `($this->_params['memberuid'] . '=' . $user)`) 
> (HORDEROOT/lib/Horde/Group/ldapp.php).
> 
> This is fine for OpenLDAP which stores group members as usernames (I 
> think), but in AD they are stored as Full DNs e.g.: member=CN=Test 
> User,OU=Organisation,dc=Domain,dc=TLD.
> 
> There are two ways to solve this problem, one is simple, but the 
> consequences are unknown, the other is complex.
> 
> The complex, but perfect, solution would be to write into the code extra 
> AD support, and possibly a checkbox on the config page for "Are groups 
> in an AD server" that would, instead of searching for groups on a user 
> filter, search for memberOf within the current user.
> 
> The simpler solution is to simply remove the member filter so that the 
> combo box populates with all available groups. Permission-wise I like 
> this solution, as there is no reason why any individual user should not 
> be able to assign view rights for their calendar to a group they are not 
> a member of, in fact this may even be considered a desirable feature - 
> what I don't know is what effect this change may have on other parts of 
> the horde code.
> 
> So really, other than bringing this problem to the attention of others, 
> I am posting this to ask a qustion:
> 
> If I simply change the group search in the getGroupMemberships function 
> in lib/Group/ldap.php so that instead of filtering on the user, it 
> doesn't filter at all and returns all known groups - am I likely to 
> cause any undesirable changes to the function of anything else within 
> Kronolith or any other application in the Horde suite?

I've just discovered the first painful side-effect of making that 
change. Having done it, all new calendars created when new users log in 
are created with Show and Read permissions for ALL groups.

I can only assume this means that the default action on creation of a 
new calendar is to share it with all groups a user is a member of -- and 
now that means ALL groups.

Any comments?
-- 
Kind Regards,

__________________________________________________

Mike Peachey, IT
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 - Registered In England
http://www.jennic.com
__________________________________________________


More information about the horde mailing list