RE: [ActiveDir] Group Management

[joe]

JoeK... quite honestly, it almost sounds like you could sell this beast. I am sure there are things very specific to your business, but I expect you could tweak what you have into something others could use. It sounds pretty cool to me. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, July 01, 2005 12:21 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Group Management I could not agree more with Joe on this point too.  We have a bunch of business rules that work really well for us, but they definitely aren’t for everyone.  For example, most organizations would not allow all users to create and delete groups willy-nilly like we do.  I can actually change that quite easily via config to restrict that to a particular group or groups, but the business users want it the other way.  End user maintenance of groups for line of business apps is very important to the model.   The other piece I never mentioned was that we have a separate app for creating query-based groups as well.  Essentially, the main website for groups is for “ad hoc” membership.  The other app is essentially a batch process that generates groups based on LDAP queries.  Anything that can be built and maintained based on schema is done that way.  We also have about 75 user account schema additions for pushing in all sorts of data from the HR system to make it easy to create these groups.  We do this with a custom app so that we can get security and DL groups (the current query-based groups are for DLs only unless you are talking about the AzMan query groups which isn’t enough for us) and so we can do custom nesting to accommodate syncing the group structure to Domino which has bigger limits on group sizes.   Joe K.   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Thursday, June 30, 2005 7:18 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Group Management   I think you need to solve your business issues before your technical issues. The technology is certainly readily available to handle this type of work if you want to build it. However, you need to be able to feed rules into the system to follow or else the systems no matter how complex will be as worthless as not having anything and not help you as you stand right now.   You must find owners for all groups and those owners need to be responsible for the membership. Doing this at a centralized manned level will kill you and be a good way for mistakes to come in and people get access to things they shouldn't as you indicate.     From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, June 28, 2005 11:05 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Group Management Hi all, sorry up front for the long post. I'm curious how larger organizations manage groups in AD, with respect to authorizing users to be added to/removed from a group.  I don't mean the security around the administration, but the supporting business processes and workflows.   We've just centralized security administration, and this has created a problem with group administration on quite a large scale.   Our security admins will get a request to add UserA to GroupA.  Since they have inherited the job, there isnt a clear 'owner' of GroupA, be it an IT owner like the SQL group, or a business owner like the Radiology dept.  If its a group that ultimately get you admin rights on all SQL servers or access to patient data...you can see the problem developing here.  The problem is really two-fold, the security aspects, as well as the time it takes to complete the request.  (multiply it by 1500 requests a day and the admins are really  backed up) I'm wondering if anyone has had success with a self-service web-based request system, or something similar, and what made it successful?  Ideally, the goal here is to get a detailed request into the admin group with all the info and approvals already in it. Thanks in advance, rb This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.