RBAC Clarification

Regarding the role-based access model, in DG's security+ book, he describes that roles are often implemented as groups. My question is when would they not be implemented as groups and how & where are you assigning users under those circumstances?

Find more posts tagged with

Comments

RoyalTech

BTW, later in the same section DG states that "The use of roles, or groups..." which implies that they are one and the same.

ptilsen

I cannot imagine they would ever not be implemented as groups. In any LDAP system, if you are implement RBAC, you should be doing it using groups, even if it means numerous one-member groups, as it so often does.

What trips people up on this is the delegation of resources, which is also generally done with security groups as well (at least in AD environments). This can and should still be done with groups, with the "role" groups as member of the "resource" groups. In AD, these are both still security groups, the former being Global groups and the latter being Domain Local groups (although they could both be universal now, and in many cases are).

RoyalTech

Thanks, do you read it the same way as I am? That there is a way to assign multiple users to roles without using groups? It's possible that DG was simply talking about it in terms of groups as opposed to individual users, which, as you said, should not be done.

A second question on this same topic refers to using user templates for specific depts in an organization? Does doing this complicate things if a user created by one user template is moved to a dept that uses another template? The assumption I am making is that templates simply make the initial process of creating the user account easier and doesn't have any effect if that user changes depts.

ptilsen

I haven't read DG's book, but to his point there is theoretically any number of ways to implement RBAC. There's no reason you couldn't have role be field associated with the user object in the LDAP database, and implement RBAC that way -- that wouldn't be a way to do it in Windows, but it's something that's within the realm of possibility. I wouldn't dwell on it as it's unlikely to affect the test.

Yes, using templates or copying existing users can complicate things slight for moves. That being said, when doing a role/department move the user's group membership will have to be changed no matter what, so it's not a serious problem. As long as the proper group membership of a given role is well defined, it should be fairly easy.

RoyalTech

Thanks for the input. I still don't have a very good grasp on how users can be added to roles that aren't themselves groups, but simply saying what you did about the possibility it would happen helps. Thanks

Darril

RoyalTech wrote: »

Regarding the role-based access model, in DG's security+ book, he describes that roles are often implemented as groups. My question is when would they not be implemented as groups and how & where are you assigning users under those circumstances?

An example that jumps out is on Microsoft's Project Server. Instead of using groups, Project Server uses roles such as the Project Manager role, the Team member role, and so on. You add users into these roles and they gain the rights and permissions assosicated with the role. Similarly, SQL Server uses roles. For example a user in the db_datareader role can read data.

Conceptually they are the same but more people are familiar with groups so I focused the explanation on groups.

HTH

RoyalTech

I understand the idea of the Project Server but when I see the different roles created on the server, I still see groups in my mind. As you said, they are conceptually the same. While this may not be that important regarding the Sec+ exam, what is the difference between the Project Server's roles and the groups I am familiar with? From my perspective, they sure don't look any different.

ptilsen

Project Server calls them roles while other systems refer to them as groups. It's all the same; only the names have changed.

RoyalTech

OK, that's good. I'm the type of person that tends to tear things apart far more than is necessary at times/all the time and I think that's what I was doing in this case.