[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