Understanding Role-Based Access (RBAC)

Role-Based Access Control (RBAC for short), is an extremely efficient way of managing access to resources for users based on their role. For example, a person with the title Payroll Clerk would have completely different resource permissions than someone with, say, the title of Engineering Manager.
This article aims to describe the benefits, the use cases, and the implementation of Role-Based Access Control.  Read on for more.

The basics of Role-based access revolves around the concept of least-privilege access. Or more simply, granting only as much access as the user in a specific role needs. By defining the roles, assigning the roles a specific access to specific resources, and then assigning users into those roles, you can dramatically reduce confusion and security overhead.

When it comes to active directory, the important part to remember is the "directory". At the core, it's a listing of objects and information about them. It organizes objects into neat little categories and helps constrain those categories into easily defined buckets, or more accurately "containers".  Those objects can be anything from computers and people, to printers and email groups. You can almost think of containers as nested boxes. For now, we'll continue with that analogy.

Managing Active Directory can feel like being buried sometimes.

When thinking about the different resources you have in your infrastructure, there are a lot of questions that need to be answered. One of those questions is "Who should have access to this?"

Role-based access provides the means to answer that question in a dynamic way. You want a way to assign permissions to those resources, be it a file share, or a printer, or an internal web app, in a way that doesn't have your admins manually adding and removing people to and from the list of privileged users. Instead, you can say "let's give access to everyone in our Special Users group for $supersecretfileshare on $highlysecureserver".

To organize something like that, lets think of our boxes. Let's imagine you have a great big box, on the outside someone hastily scrawled "contoso.com" on it with a nearly dried up sharpie. Inside that box is a bunch of slightly smaller boxes with more scribbled labels: Workstations, Servers, Domain Controllers or even locations of your offices, maybe departments depending on your organization. Then you find the one that you're looking for. "Security Groups", and within that, even more boxes that have very specific labels on them, these boxes are different though. These boxes are special in that you can assign NTFS permissions to them.

A simple visual aid, which should help with understanding the "containers" concept a bit.

So lets say our box "Special Users Group" is one of these boxes. Inside contains a list of the members that have access to $supersecretfileshare on $highlysecureserver. Then we look at the fileshare itself. What kind of things are stored there? We probably want to restrict who can read,write,create,view, or modify files within the share. So we assign the read permissions of our resource ($supersecretfileshare) to our group (SpecialUsersGroup). We probably don't want all the users in that group to be able to change the folders, or create new files. Only some of them. With hierarchical RBAC, we can include a group listed as "Special User Content Admins" within that group, that has more permissions, such as create, and modify. So any users within Special Users Content Admins, will inherit the permissions of the group Special Users Group.

So lets take a step back and see what this looks like in practice:

Create the new group in the desired OU

Since I only have a single domain, I'm creating this as a Global security group. If I had users in another domain that required this access, I'd create this as a domain local group instead.

On the shared folders NTFS permissions, I added the two groups to the permissions. Notice that inheritance has been enabled.

For Special Users Group members, I've given them only enough to update files. They cannot create folders or modify the share in any other way.

For Special Users Content Admins, I've given the ability to create folders as well as delete files and read permissions.

When we check effective permissions for SalesUser1, we see that they have the desired permissions.

When we check effective permissions for SalesUser3 (a member of Special User Content Admins), we see that they have the permissions of the Special Users, as well as Special Users Content Admins.

This works because, as shown here, the memberships for Special Users group includes the members of Special User Content Admins.

A helpful command for showing all the members of a root-level group, this is useful for troubleshooting 

As a bonus, you can easily audit who has what permissions by simply asking active directory for the members of various group memberships.

By defining your resources, defining your roles, and then assigning resources to the roles, then people to the roles, you can constrain users to the resources they require and how they can interact with those resources.  This measure goes a long way in keeping your environment safe from data breaches with role-based access control.


Thanks for reading!