Another option would be to provide a web tool that proxies the group membership management. The account that the tool runs under would have the necessary delegated permissions to manage the group membership, but the members of the TK_ChangeGroupMembership group would not. The tool could authenticate the logged in user against AD and determine whether the account has membership of the TK_ChangeGroupMembership group. This way you still have the required delegation in place, but no danger that nested groups will be created.
Tony ---------- Original Message ---------------------------------- From: "joe" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Date: Thu, 28 Oct 2004 10:02:07 -0400 A is definitely the best answer in terms of a guarantee. C is the most fun. :o) For a quick workaround I would combine B wih C. A script that checks groups for nested groups and then if it finds them cleans them up, then sends a note to everyone who can change the membership the group that had the problem and what group had been nested in it. Basically give enough info so someone could chase help desk tickets and embaress someone. Make sure you catch the managers of the help desk staff as well as possibly the security group. Note that even with custom taskpads and such, people can manipulate groups with scripts and command line tools... joe _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jorge de Almeida Pinto Sent: Thursday, October 28, 2004 8:39 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Delegation of group membership changes to add use rs and not to ad d other groups thanx.. We also thought about option C, but we would than ran out of helpdesk employees and have to change the group memberships our selves. ;-)))) (very bli smile!) just kidding.. _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nicolas Blank Sent: donderdag 28 oktober 2004 14:26 To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Delegation of group membership changes to add users and not to ad d other groups a) third party provisioning tools, Quest/Aelita/Similar b) run a scheduled script to strip out groups within groups every fifteen minutes c) publicly beat a helpdesk employee to make an example of them - oops, don't we do that anymore ? ;) _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jorge de Almeida Pinto Sent: 28 October 2004 12:16 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] Delegation of group membership changes to add users and not to ad d other groups Hi Everyone, Our situation: OU "Groups" with all security groups OU "Users" with users OU "Tasks" with a taskgroup named "TK_ChangeGroupMembership" Helpdesk accounts are member of the group "TK_ChangeGroupMembership" The group "TK_ChangeGroupMembership" has been delegated the control to change group memberships of groups in the OU "Groups". With this solution the helpdesk has the possibility to add a user to a group. OK..., but the helpdesk also has the possibility to add a group to another group (group nesting) AND WE DON NOT WANT THAT! So we created a taskpath view so that the helpdesk only sees the USERS OU. With the last solution the problem still exists because the helpdesk guys open the properties of a user in the USERS OU they still have the possibility to resquest the properties of the groups the users are a member of, and therefore they still can add a group to another group. I think I've tried everything, but no solution until now... Does any of you know how I could solve this? Thanx! Met vriendelijke groet / Kind regards, Jorge de Almeida Pinto Infrastructure Consultant __________________________________________ <<...OLE_Obj...>> LogicaCMG Nederland B.V. (BU SD/AT) Division Industry, Distribution and Transport (ID&T) Kennedyplein 248, 5611 ZT, Eindhoven * Postbus 7089 5605 JB Eindhoven * Tel : +31-(0)40-29.57.777 * Fax : +31-(0)40-29.57.709 * Mobile : +31-(0)6-26.26.62.80 * E-mail : [EMAIL PROTECTED] " < <http://www.logicacmg.com/> http://www.logicacmg.com/> - Solutions that matter - This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. ________________________________________________________________ Sent via the WebMail system at mail.activedir.org List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
