We help IT Professionals succeed at work.

Active directory OU and groups

Da_Ch0sen asked
i designed the following OU's
sales, marketing, board , executives , etc ...

some users can be in two department at the same time.
and those who are in two department should have all the privileges and the shares of both departments.

should be those groups or OU's ?
and can a group exist in more than one ou ?

what would be a good design for this ? with example please
Watch Question

Joseph MoodyBlogger and wearer of all hats.
After creating each OU, I would probably create a group for each OU that is named the same. Assign permissions and policies to the group and place members inside of the group.

User accounts could go into the OU that they originally belonged to or the department that they primarily work for.
They should be groups. You can organize them in AD in OU's any way you want for organizational or group policy purposes. But in the case of giving users access to folders in other departments this is where you would use groups. Personally I use a structure of groups for either read or write access for each share I create and add the users there.

Example Groups

Finance Share - Write Access
Finance Share - Read Access

Then add the groups to the shares accordingly. And Add the users to the groups.

This is just my system of giving permissions. But its clean and organized.

The OU structure is another story but does not pertain to giving users folder access.
IT Director
OU's are very useful for group policy, but when setting user permissions on files and folders you should use groups of user accounts.  Groups don't really belong to an OU, and it is fine for a user to be a member of several groups thereby giving them permissions from each group.
tigermattSite Reliability Engineer
Most Valuable Expert 2011
As the others indicate, OUs are not for awarding permissions to folders -- use groups for that, since a user can then be a member of multiple groups.

In the design of your grouping strategy, I would strongly recommend you employ a role-based mechanism in accordance with best practices, distilling the recommendations of the AGDLP strategy. In a single domain environment, you do not necessary need to worry about creating domain local / global / universal groups; the default of a global group would be fine.

In a nutshell:

Each resource you need to protect gets its own group; this might be file shares, access to websites, etc.

Each department / user "role" gets its own group; e.g. "Marketing staff", "Finance staff", etc.

You add the department groups as members of the resource groups, so Marketing staff becomes a nested member of "Marketing share -- read only access", for example.

You add the relevant staff members to the user role group, "Marketing staff" in this case.

This makes auditing radically simpler in future. If you just use a single group for each job function (e.g. "Marketing staff"), your directory has no location which tells you what permissions are granted by virtue of being a member of that group; you must either keep fastidious documentation, or (as is the case in most cases) will ultimately have no idea what resources are accessible and will spend a lot of time modifying ACLs to fix up "security issues".