role based access in AD

The organisation I work for (I work in risk not IT) is moving to a role based access control model for assigning permissions to users on our numerous file servers.

At present file server access is locked down via groups, i.e.:

\\fileserver\department\teamXYZ - would only be accessible via a domain group called “teamXYZ” (and IT support groups)

I must confess I don’t really see what is wrong with this approach? Or how it is bad practice? (feel free to explain - I am not a fan of changing something that isnt broke and works well).

But apparently we are going down the RBAC model, I wasn’t sure if AD actually has “roles”, I can see users and groups in ADUC, but can’t say I have ever seen a “role” object in AD?
But that aside, how is RBAC more secure than group based permissions, and from a risk perspective, are there any specific risks associated with RBAC, and compensating controls/best practices to mitigate the new risks associated with using RBAC models.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

TheBDPSr. Sys EngineerCommented:

RBAC tends to work best for large organizations with LOTS of file shares. The key for it to work successfully is to ensure that everything is documented.

Also you want to be sure that one user will not belong to multiple groups. If they are, every group the member belongs to will have to be authenticated against every time the user attempts to use the file share. This can cause delays in accessing file share. GPO's that map drive letters on long in etc. As you're probably aware window file share is most restrictive, so be very careful in creating your groups.

I personally am not a big fan of RBAC. I've seen it done wrong too many times. And if done incorrectly, can be a nightmare to try to decipher. I would rather do something like this.


If the path above is the file share. I would create a security group called:

Fileshare_Department_Team_FULL (only when really needed)

Then add the users to the security group above. I find it much easier to audit.

I've just found too many times an organization wants RBAC, but they don't want to commit to no "One Off's" So what ends up happening, is you have this nice clean model. With all these exceptions, that become a nightmare to audit.

You have to have executive or upper managements backing for this to be successful, and unfortunately, management changes. I personally go with what makes it easier for me to audit. There are a ton of tools out there to help with the creation of user accounts and the automatic assignment of security groups based on the title, group, location, etc. MS Orchestrator does a fantastic job of this.

I'd just go back and make sure you're going to RBAC for the right reasons. If it's about a simplified model, RBAC is more complicated IMO. I'm sure someone else will chime in though :)

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
If RBAC is done right, it has the advantage of being easier to manage and audit.

So let take an example of a role - a Sales Agent. You document all the permissions that Sales Agent would require. You then create a group in AD called sales_agent and add all the permissions to that group. You then add that group to everyone in the company who is a Sales Agent. So now they all have the same permissions.

If a new Sales Agent starts in the company, they just get added to the role and receive all the appropriate permissions. You no longer have to figure out what they will need and request them all.

It is also easy to audit - you just need to confirm that all the permissions for the role are correct, and then check that all the people in the role are correct - you no longer have to audit each user.

This is in an ideal world. Unfortunately it doesn't usually work out like this, as TheBDP above mentioned. What happens is that some of the agents need access to folders that others don't, e.g. they are senior agents. So what should happen is that the roles are redefined e.g sales_agent and senior_agent. However what will probably happen is that the permissions will be added directly to the accounts of those senior agents, which breaks the RBAC model.

Now you end up with users have some permissions via their role, and the rest added directly to their account. This can make management and auditing even harder than before!

So if it is done right, then it can be a good thing.
TheBDPSr. Sys EngineerCommented:
Completely agree with John, it can be a fantastic thing if done correctly!
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

pma111Author Commented:
Thank you.

So there is no such object as a role in AD, its essentially a group? I wasnt sure if there was an actual AD object called a role?
No, there is no actual object that is a role - you just use a group and call it a role
Rich RumbleSecurity SamuraiCommented:
The "role" is authority level or title. Administrator is a Role, Authenticated User is a role, Backup operator is a role. The backup operator has some rights that others don't have, but is also missing many rights that others may possess. The title and rights make the role essentially.
Also don't confuse AuthENtication with AuthORization. Authentication is proving you are who you say you are, and authorization is being allow/denied access to something.
The primary distinction with a role is it's function, a backup operator has a very specific function.
Roles are groups and groups are roles, even users are roles and vice versa.
Roles get confusing when inheritance and hierarchies become involved, as they can significantly affect the access a role has.

Have a look at AzMan from M$ if you want to develop appliactions (in .net) that are easily made into RBAC app's.
A newer approach from M$ is here

In AD there are lot's of roles, a service is a role, a computer, a user, a printer can all be roles technically. But Groups, especially the predefined ones, are the easiest roles to see.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.