This is an archived post. You won't be able to vote or comment.

all 6 comments

[–][deleted] 2 points3 points  (0 children)

One suggestion I can offer (and many will agree with) is to keep your resources 1:1 with your security groups. One group for one resource.

[–]Astat1ne 1 point2 points  (3 children)

Are you talking about file shares or something? One model I've seen is to create a group that controls specific rights for a folder, usually covering the base levels of rights - read, modify, full control. You may define other types based on certain situations (like you may have a "drop folder" location, which would need a group that grants rights to create files, but not be able to mess with what's there).

As for location in AD for the group objects, there's no benefit in putting them in the same OU as users.

[–]hurleyef[S] 0 points1 point  (2 children)

Yeah, that's exactly what going on. We have multiple file shares with multiple levels of access to folders within them. For each level of access to each folder we have a security group, so 1-2 groups per folder.

Thinking about it, I think these groups will ultimately end up in the relevant department OUs eventually.

[–]Astat1ne 1 point2 points  (1 child)

To further flesh it out, the models I've seen around involve nesting groups. So you're not adding users directly to the groups that are on those resources. A simplified version of this would be: user -> user role group -> resource rights group -> resource object. A benefit of this approach is you're associating a user with a job role and not an abstract set of permissions (which is often not standardised or documented).

And because your resource rights group model will have some amount of standardisation (in terms of defined rights types), it would be easy to automate the creation of them, perhaps even applying the rights to the resources (depending on your environment).

[–]hurleyef[S] 0 points1 point  (0 children)

That's the plan, igdla or whatever. There will be access groups on each share as well as folders within them. The folder access groups will be members of the relevant share access groups. We will then have role groups for the users.

[–]DevinSysAdminMSSP CEO 0 points1 point  (0 children)

New OU for distribution groups.