One thing that seems a pretty good idea is to ensure that resources are acl'd for the largest common group. For example, your \\server\share portion might be open to everyone for access at the share and ntfs level (don't forget about that part) and then more narrowly focused by group and then sub-group and so on until it no longer makes sense.
The common variable that seems to give the best indication of success is the planning. The more you do up front the better you'll be down the road.
Oh, and be sure to keep it from being any more complex than it absolutely needs to be. The more complexity you introduce ( i.e. too many groups) the more likely it will be circumvented by someone that doesn't understand it fully.
My $0.04 worth.
On 10/12/06, Grillenmeier, Guido
<[EMAIL PROTECTED]> wrote:
ABE won't necessarily reduce the number of groups you need to control access, although it certainly controls the visibility for those that don't have any rights to specific data in your shares.
Your approach is a very common approach and certainly nothing unusual. Not sure how you get from 15 departments to 60 groups (a more concrete sample of your group structure would help understand). But whatever it is, a user will likely be a member of quite a few groups either directly or through nesting - I wouldn't worry too much about the number of groups you create (if they have good structure that makes sense), but more about the number of groups a user will have to be a member of.
At some point you have to think about the kerb token size the users will get at logon and if that is going to cause issues. You can obviously influence this by choosing to create some of your groups locally on the FS, but this has it's own downsides.
/Guido
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Steve Evans
Sent: Thursday, October 12, 2006 1:20 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] OT: File Server Permissions Design Question
We're actually using ABE (or will be once we start migrating to this box). It helped me a ton with a couple situations (home folders being the big one because of something called FERPA, if you don't know what it is you don't ever want to know). However I don't see how that helps me here specifically.
Steve Evans
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Mark Parris
Sent: Wednesday, October 11, 2006 2:38 PM
To: ActiveDir.org
Subject: Re: [ActiveDir] OT: File Server Permissions Design Question
Have you looked at installing the Access based Enumeration feature pack and basing the permissioning on this type of model?
Assuming W2003.
Regards,
Mark Parris
Base IT Ltd
Active Directory Consultancy
Tel +44(0)7801 690596
-----Original Message-----
From: "Steve Evans" < [EMAIL PROTECTED]>
Date: Wed, 11 Oct 2006 12:57:52
To:<ActiveDir@mail.activedir.org>
Subject: [ActiveDir] OT: File Server Permissions Design Question
I've had difficulty finding a better forum in which to ask this. And since it involves AD Security Groups I thought I could get away with it.
We're in the process of migrating to a new file server. Our shared drive has a basic structure of:
Shared\Department\Sub-Department\<one public folder & one private folder>
Our original thought was to have one Read and one Read/Write group for each public and private folder. Those groups would then be populated by role based groups (department groups, position groups (ex all management)). I've
written a script that you can point to a directory structure and it creates the appropriate groups and assigns the security permissions.
However I end up creating a lot of groups. Just in ITS (for example) we have 15 sub-departments so that will produce 60 groups right there. On the other hand everything is very structured and in theory you can mange file security permissions from within AD. Since everything is scripted you never
need to go and look at folder permissions (except for the file server admin guys when troubleshooting).
I'm also concerned that users will end up being in groups that are nested in
a substantial number of groups. For instance most of the public-read groups for ITS will contain the group "ITS - All Staff". That means any given ITS employee will have 30 security group tokens just from this.
Any thoughts or opinions?
Steve Evans
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
[EMAIL PROTECTED]®ËŠËE¬§â²Ö«r¯zm§ÿðÃœ¶+Þv*è®æ—ûa汫)
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.activedir.org/ml/threads.aspx
