Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a file server with 20 shared folders one for each department and their emploees have write permission through a AD group with same name of that folder.

The thing is some people have to write files on others department folders so they have write permission for this folder too, giving they full access to any file.

I want change that practice to this one:

I'll create a AD group by each company position and give to each read and write access to diferent folders acording to position needs. So, each emploee will have the correct access to the files and if an employee change your position, I'll only have to change it from your position group.

Any suggestions?

share|improve this question
This is referred to as role-based access control, and is generally considered best practice. That said, questions should address specific problems, and you've already got a plan to deal with the one that you've outlined. On a side-note, you've got some good answers on older questions, please consider going back and accepting some of them if they've helped you. – Shane Madden Apr 8 '11 at 17:17
If going to role-based access from your current setup, I would suggest keeping the current folder-groups as your "resource" groups. Then when you create your "role groups", you should assign access rights by adding the "role group" to a "resource group". This approach will give you more flexibility in the long-term, as th actual resources (folders, DFS targets, etc.) can be moved more easily without having to redo ACLs. It is a bit more work to setup and DOCUMENT, which could lessen the appeal of this approach if you have a very small office. – Ryan Fisher Apr 8 '11 at 17:40
@Santiago - To reiterate what @Shane said, part of the give and take of SF is to accept answers on questions you've asked, mark up ones that you've found useful, etc. Please consider going back to your previous questions and do that. – GregD Apr 8 '11 at 17:44
Thank all for the recomendations, I didn't know that on SF. About role-based access control is an approach I though, but I really want to know your experiences like @Ryan comments configuring file server – Santiago Apr 8 '11 at 21:29
This is something we considered. They problem that we came across is that trying to get the business to define the roles and profiles that we should setup was impossible. Although we are talking about a large geographically distributed company here. I ended up creating a new folder structure and defining 'Finance' and 'operations' to work in a similar manner to the old system you describe. If there is a cross department area needed there is a 'Collaboration' folder that we provision access to (still access controlled though, nobody wants an open 'anybody' folder). – Patrick Jun 17 '11 at 9:59

What you are looking for, best practices style, is AGDLP. Wikipedia has an ok description of it.

The short version is to put people into Universal or Global groups based on their roles and named after the specific role. (Like putting groups Team1 and Team3 to into DataTransferAppUsers.) Then make Domain Local groups for the permissions (group Share_DataTransfer_RW should have Modify access to that share) and then put the universal groups into that share.

Don't be afraid to make the user groups specific and small and then nest them or combine the smaller groups into more general ones. Try to avoid sub-dividing the user groups into more than one or two different hierarchies. Keep people groups apart from role groups, role groups should only have groups in them. Try even harder to avoid EVER putting individual users into the Domain Local permissions groups.

User -> UserGroup -> RoleGroup -> DomainLocalPermissionGroup -> ACL

Now when you add a person you need only get him into a few UserGroups. When you add a new resource for an existing role you create 1 or 2 groups (readonly and/or readwrite) and apply that one role to it. When you create a new role, you just create one group and then look for resources it will use.

You thus use AD to tie everything together. The discipline comes from never, ever applying a User (Account in MS lingo) or Group of user directly to any ACL on a local system. This way you can trust there is nothing going on outside the view of the permission tree you build in AD.

Given a shared folder, \nyc-ex-svr-01\groups\bizdev; a business development group within the organization's Marketing department, represented in Active Directory as the (existing) global security group "Business Development Team Member"; and a requirement that the entire group have read-write access to the shared folder, an administrator following AGDLP might implement the access control as follows:

  1. Create a new domain local security group in Active Directory named "Change permission on \nyc-ex-svr-01\groups\bizdev".

  2. Grant that domain local group the NTFS "change" permission set (read, write, execute/modify, delete) on the "bizdev" folder. (Note that NTFS permissions are different from share permissions.)

  3. Make the "Business Development Team Member" group a member of the "Change permission on \nyc-ex-svr-01\groups\bizdev" group.

To highlight the advantages of RBAC using this example, if the Business Development Team required additional permissions on the "bizdev" folder, a system administrator would only need to edit a single access control entry (ACE) instead of, in the worst case, editing as many ACEs as there are users with access to the folder.

share|improve this answer

I would say by job profile, that's the best practice.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.