Pretty much the same here, although I tend to try not to nest groups at all if possible. With regard to AD, I have always been of the "one group, one function" methodology. Saves a lot of hell when some idiot accidentally removes a group if you know exactly what the scope of that group's function was. There is a little overhead when it comes to setting things up - but I can live with that. Of course, if you get into massive environments there is (or was, maybe 2008 has overcome it) a limit to the number of groups a user can be a member of before you start getting weird logon issues (I can recall using the tokensz tool to calculate the number of groups users were members of at one point). This may or not be a factor for some people.
2009/10/13 David Lum <[email protected]> > I am going through file/folder permissions and our security groups in AD > – I imagine some of you guys have hundreds of security groups? For a given > share I have a security group associated (with RWXD perms) with it, and if > some folks need read-only I create another group. I also have groups for > each department and they become members of whatever security group is > associated with access to whatever shares they need. I do the same for > non-shared folders that also need specific permissions. > > *David Lum** **// *SYSTEMS ENGINEER > NORTHWEST EVALUATION ASSOCIATION > (Desk) 971.222.1025 *// *(Cell) 503.267.9764 > > > > > > > > -- "On two occasions...I have been asked, 'Pray, Mr Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." http://raythestray.blogspot.com ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
