Why Windows Groups are not a RBAC Solution
Video Transcript
So the big word in security management these days is RBAC, Role-Based Access Control. The basic idea is you have a bunch of top level roles that represent job tasks, you put users into those roles, and a miracle occurs under the hood, and they get all the permissions they need to do their job. Folks will often ask, that just sounds like the same user group permission scheme we have used pretty much forever in Windows.
For example, here in Active Directory I might open up a global sales group and then add some people to it. So I have just added DonJ to the sales user’s global domain group, so how is that not role based access control? I can still drop down to an individual file, I can add a domain local group. Let’s see if I have one here. I can assign permissions to that domain local group. Just keep it with read. Then all I have to do is go back into Active Directory make sure that the domain local group, which is here, contains the domain global group where my users are. So if that domain global group represents a role, say, sales users, Then whatever local groups it is a member of it will pick up the permissions of those local groups.
That is sort of the idea of Role Based Access Control. It has a couple of problems though. One, Role Based Access Control also includes the idea of separation of duties. So it means that while an administrator would own the technical responsibility for making sure that the right permissions were assigned to this local group, a domain administrator would not have the ability to modify the membership of the role. Someone else would do that, some in HR, in other words, someone in the company who is deciding who is allowed to do these job tasks of a sales user. So that is one reason why this is not true RBAC.
Another reason is that once you start to grow beyond multiple domains and multiple forests this can get out of control really really quickly, trying to manage that using exclusively these native things. And look, Microsoft knows this is the case. Back in the Server 2003 time frame they created a product called Authorization Manager to create Role Based Access Control. Now that is a developer-centric tool. It is something developers would use to create role based enabled applications then it does not really apply to the broader operating system or server level stuff. But even applications like Exchange Server implement their own roles in order to create this sort of role based model.
So In a very very tiny environment you could probably use the built in stuff. The key is to remember that your roles do not represent necessarily sets of permissions, they represent a job task. Here is the difference. We are so used to thinking of our job tasks in terms of how we get them done that sometimes it can make thinking about RBAC a little bit difficult. For example, we know that in order to get such-and-such a job done the sales person is going to have to go in and update these files. So we think of the job task as being able to update those files, but that is not really the case. The job task would something like creating new customer records or updating an existing customer records. Then the underlying permissions might include those files they need to actually do that, or it might include databases or access to a SharePoint sight. How they get the job done, what resources they have to touch is not the job. RBAC is also about separating those.
You know you get into the situation where the new guy comes in and someone says “Just give him the same permissions as the old guy”. Well okay, what permissions would those be? And the reason we are stuck like that is because upper level management does not know what permissions they guy needs, they just know what job he need to do. That is the real beauty of RBAC because you can separate things out so that management can put people into things that they recognize as job tasks and then we administrators can make sure that those roles have the right permissions, well then we have really created a better security system all over.
-
About Don Jones
-
With more than fifteen years of IT experience, Don Jones is one of the world’s leading experts on the Microsoft business technology platform.
Security Explorer
Manage access controls and security on Windows servers, Exchange, SharePoint, SQL Server and workstations across the enterprise.