Active Directory: Role Based Access Modeling

2011-02-22 10 min read Active Directory Microsoft Networking Security System Administration Zachary Loeber

Much of my time is spend delving into the minutia of a particular technology to resolve issues or improve department processes. But sometimes understanding and implementing a technology is not the best “fix” for an issue. Sometimes it is a mindset or a model that needs to change. I came up with this security grouping model to address some of the pains of managing permissions across large groups of systems in our environment. Ok, I modified a long standing Microsoft recommendation of AGDLP (an abbreviation of “account, global, domain local, permission”) to meet our needs. Regardless here is a quick rundown of this security group model I devised if anyone is interested.

Essentially I did a simple recreation of RBAC (Role Based Access Control) that is used in Exchange. Actually I found out about this Exchange RBAC model out after I came up with this diagram and started implementing it in our company. I’m always late to the party it seems. Anyway, I use end user company position in a hierarchical model where higher up positions always have access to resources that lower positions are granted. (ie. A tech analyst 1 is granted rights to a particular resource so automatically tech analyst 2, team lead, and manager will have access to this resource as well). I also define a top level department group which contains all the other groups in the department for blanket permissions. I arbitrarily chose group naming convention where the first 3 letters denotes the type of group that is being defined. The naming convention is obviously flexible to the needs of your organization.

We also create duplicate department/position groups with “-SU” appended to the end of them for our privileged accounts which have access to the internal company servers and other infrastructure items which should not be accessed using general workstation credentials.

A couple of notes about this model:

This model is probably only scales well for small to medium companies due to how quickly you can end up with token bloat from too many nested groups. For larger companies some form of identity management software would probably be the best way to go.
As mentioned before, I blatantly ripped of the well-known concept of AGDLP. So the originality of my design is questionable.
This model depends on top down tiered approach to permissions based on company role. So, if you work with another person at the same level as you but with more/less access you will have to modify this model appropriately.
This model works exceptionally well if you have several environments in the same domain. You can assign all computers in an environment to a security group to which you can then use GPO preferences to apply your assigned permissions (sorry 2008 or above domain functional level only).
Although there is a bit of work involved in setting up the initial groups, you can do so progressively. I did whole sets of department groups as I was required to grant permissions and eventually a large quantity of them got completed.
Even if you don’t have a solid organizational tree most people know who they report to at the very least. You can use this information to change the organization tab in ADUC to update the manager of a person and start setting up department groups by title somewhat generically.
If titles or department names change, updating a group name in AD is a nominal task which will have zero impact on most environments (the only time I see it being an issue is if the group name is statically coded as an ldap string somewhere for linux integration, even then you would use a resource group for such a static encoding, not a security group name which refers to a specific department/title…right?).

At the very least you can use the included visio diagram in your documentation or sales pitch for a more organized security model for your company or as a template to model your own company standard.

<p class="MsoNormal">
  Essentially I did a simple recreation of RBAC (Role Based Access Control) that is used in Exchange, well I found this out after I came up with this diagram and started implementing it in our company. I use end user company position in a hierarchical model where higher up positions always have access to resources that lower positions are granted. (ie. A tech analyst 1 is granted rights to a particular resource so automatically tech analyst 2, team lead, and manager will have access to this resource as well). I also define a top level department group which contains all the other groups in the department for blanket permissions. I arbitrarily chose group naming convention where the first 3 letters denotes the type of group that is being defined. So res = resource and sec = security. The naming convention is obviously flexible to the needs of your organization.
</p>

<p class="MsoNormal">
  We also create duplicate groups with “-SU” appended to the end of them for our privileged accounts which have access to the internal company servers and other infrastructure items which should not be accessed using workstation credentials.
</p>

<p class="MsoNormal">
  A couple of notes about this model:
</p>

<p class="MsoListParagraphCxSpFirst" style="text-indent: -0.25in;">
  <span style="font-family: Symbol;"><span>·<span style="font: 7pt &amp;amp;"> </span></span></span>This model is probably only scales well for small to medium companies due to how quickly you can end up with token bloat from too many nested groups. For larger companies some form of identity management software would probably be the best way to go.
</p>

<p class="MsoListParagraphCxSpMiddle" style="text-indent: -0.25in;">
  <span style="font-family: Symbol;"><span>·<span style="font: 7pt &amp;amp;"> </span></span></span>As mentioned before, I blatantly ripped of the well-known concept of AGDLP. So the originality of my design is questionable.
</p>

<p class="MsoListParagraphCxSpMiddle" style="text-indent: -0.25in;">
  <span style="font-family: Symbol;"><span>·<span style="font: 7pt &amp;amp;"> </span></span></span>This model depends on top down tiered approach to permissions based on company role. So, if you work with another person at the same level as you but with more/less access you will have to modify this model appropriately.
</p>

<p class="MsoListParagraphCxSpMiddle" style="text-indent: -0.25in;">
  <span style="font-family: Symbol;"><span>·<span style="font: 7pt &amp;amp;"> </span></span></span>This model works exceptionally well if you have several environments in the same domain. You can assign all computers in an environment to a group to which you can then use GPO preferences to apply your assigned permissions (sorry 2008 or above domain functional level only).
</p>

<p class="MsoListParagraphCxSpMiddle" style="text-indent: -0.25in;">
  <span style="font-family: Symbol;"><span>·<span style="font: 7pt &amp;amp;"> </span></span></span>Although there is a bit of work involved in setting up the initial groups, you can do so progressively. I did whole sets of department groups as I was required to grant permissions and eventually a large quantity of them got completed.
</p>

<p class="MsoListParagraphCxSpMiddle" style="text-indent: -0.25in;">
  <span style="font-family: Symbol;"><span>·<span style="font: 7pt &amp;amp;"> </span></span></span>Even if you don’t have a solid organizational tree most people know who they report to at the very least. You can use this information to change the organization tab in ADUC to update the manager of a person and start setting up department gr
</p>

<p>
  Active Directory: Role Based Access Model
</p>

<p>
  Much of my time is spend delving into the minutia of a particular technology to resolve issues or improve department processes. But sometimes understanding and implementing a technology is not the best “fix” for an issue. Sometimes it is a mindset or a model that needs to change. I came up with this security grouping model to address some of the pains of managing permissions across large groups of systems in our environment. Ok, I modified a long standing Microsoft recommendation of <a href="http://en.wikipedia.org/wiki/AGDLP">AGDLP (an abbreviation of &#8220;account, global, domain local, permission&#8221;)</a> to meet our needs. Regardless here is a quick rundown of this security group model if anyone is interested.
</p>

<p>
  Essentially I did a simple recreation of RBAC (Role Based Access Control) that is used in Exchange, well I found this out after I came up with this diagram and started implementing it in our company. I use end user company position in a hierarchical model where higher up positions always have access to resources that lower positions are granted. (ie. A tech analyst 1 is granted rights to a particular resource so automatically tech analyst 2, team lead, and manager will have access to this resource as well). I also define a top level department group which contains all the other groups in the department for blanket permissions. I arbitrarily chose group naming convention where the first 3 letters denotes the type of group that is being defined. So res = resource and sec = security. The naming convention is obviously flexible to the needs of your organization.
</p>

<p>
  We also create duplicate groups with “-SU” appended to the end of them for our privileged accounts which have access to the internal company servers and other infrastructure items which should not be accessed using workstation credentials.
</p>

<p>
  A couple of notes about this model:
</p>

<ul>
  <li>
    This model is probably only scales well for small to medium companies due to how quickly you can end up with token bloat from too many nested groups. For larger companies some form of identity management software would probably be the best way to go.
  </li>
  <li>
    As mentioned before, I blatantly ripped of the well-known concept of AGDLP. So the originality of my design is questionable.
  </li>
  <li>
    This model depends on top down tiered approach to permissions based on company role. So, if you work with another person at the same level as you but with more/less access you will have to modify this model appropriately.
  </li>
  <li>
    This model works exceptionally well if you have several environments in the same domain. You can assign all computers in an environment to a group to which you can then use GPO preferences to apply your assigned permissions (sorry 2008 or above domain functional level only).
  </li>
  <li>
    Although there is a bit of work involved in setting up the initial groups, you can do so progressively. I did whole sets of department groups as I was required to grant permissions and eventually a large quantity of them got completed.
  </li>
  <li>
    Even if you don’t have a solid organizational tree most people know who they report to at the very least. You can use this information to change the organization tab in ADUC to update the manager of a person and start setting up department groups by title somewhat generically.
  </li>
  <li>
    If titles or department names change, updating a group name in AD is a nominal task which will have zero impact on most environments (the only time I see it being an issue is if the group name is statically coded as an ldap string somewhere for linux integration or something, even then you would use a resource group for such a static encoding, not a security group name which refers to a specific department/title).
  </li>
</ul>

<p>
  At the very least you can use the included visio diagram in your documentation or sales pitch for a more organized security model for your company or as a template to model your own company standard.
</p>

<p class="MsoListParagraphCxSpMiddle" style="text-indent: -0.25in;">
  oups by title somewhat generically.
</p>

<p class="MsoListParagraphCxSpLast" style="text-indent: -0.25in;">
  <span style="font-family: Symbol;"><span>·<span style="font: 7pt &amp;amp;"> </span></span></span>If titles or department names change, updating a group name in AD is a nominal task which will have zero impact on most environments (the only time I see it being an issue is if the group name is statically coded as an ldap string somewhere for linux integration or something, even then you would use a resource group for such a static encoding, not a security group name which refers to a specific department/title).
</p>

<p class="MsoNormal">
  At the very least you can use the included visio diagram in your documentation or sales pitch for a more organized security model for your company or as a template to model your own company standard.
</p>

<p class="MsoNormal">
  <p>
    </mce:style></div>