Deploying a Role-Based Access Control Model for ISA Server 2004

For many years, Microsoft has provided for ease of administrative delegation in its products, for better or for worse. Unfortunately, however, this concept has been misused and abused and generally misunderstood. Too often, access is simply granted ad hoc, and to individual users, resulting in a mess of security permissions, orphaned SIDs, and potential security risks.

What is needed is a best practice strategy for securing access to resources, including ISA Server itself. Ideally, this strategy should involve granting access only when a person's role dictates that he should be allowed access to that resource. For example, if Susan is an accountant, then it would stand to reason that she should not have access to Human Resources file servers. What should happen is that the role of Accountant should be defined, and the resources that that role needs to perform that job should also be defined.

Exploring the Concept of Active Directory Access Groups and Role Groups

A best practice approach that utilizes role-based access control for ISA Server 2004 Administration, and administration of an IT environment in general, can be deployed in a relatively straightforward approach, using Active Directory Groups to delegate administration and to define membership in particular roles.

This administrative concept logically divides groups into two types, as follows:

• Access Groups Access groups are Active Directory groups that are created to control a certain level of access that is granted to a particular resource, such as a file share, printer, server, or any other network resource. For example, a group could be created called AG-ISAFullAdmins that would be granted Full Admin rights to an ISA Server. For the most efficient replication and application, these types of groups are typically Domain Local Groups.

• Role Groups Role groups are Active Directory groups whose members share the same roles within an organization. These groups are then added into the membership of an access group to allow the members of that role to have the type of access they need to do their job. An example of a role group would be RG-IT-SecurityAdmins, which would be added as a member of the AG-ISAFullAdmins access group. Role groups are best created as Active Directory Global Groups.

NOTE

The terms access group and role group are not official Microsoft terms, but are useful descriptors to help understand this concept.

Illustrating a Role-Based Access Approach

To illustrate this concept, take fictional CompanyABC. CompanyABC has several job types within the company, such as the following:

• Human Resources Officer

• Marketing Analyst

• Accountant

• Information Technology Engineer

• Manager

• Security Admins

• IT Helpdesk

• Salesperson

In Active Directory, Global Groups were created at CompanyABC to correspond to each of these groups, such as the following:

• RG-HROfficers

• RG-MarketingAnalysts

• RG-Accountants

• RG-ITEngineers

• RG-Managers

• RG-IT-SecurityAdmins

• RG-IT-Helpdesk

• RG-Salespersons

CompanyABC spent the time auditing what each role needed to access. They determined different types of access requirements for each role. For example, they determined that the Security Admins required full control of the ISA infrastructure, whereas the Helpdesk needed only to monitor ISA, as well as to perform multiple other tasks within the organization. Access groups were created and directly given the particular rights on the resources through use of the various Administrative Control wizards. For example, the following access groups were created for ISA:

• AG-ISA-FullAdmins

• AG-ISA-BasicMonitoring

• AG-ISA-ExtendedMonitoring

To allow the Security Admins to be full ISA Admins, the RG-IT-SecurityAdmins group was added as a member of the AG-ISA-FullAdmins group. For the Helpdesk resources to monitor ISA, they were added into the AG-ISA-BasicMonitoring group.

With this type of model in place, when a new employee comes into the organization into a particular role, or when an employee changes his role, only the role group membership needs to be changed, which automatically grants access to the resources that job requires. It also makes it very easy to audit administrative access to an environment.

This concept is very useful for administering an ISA Server environment, and can also be extended for use with the administration of other components in an environment.

NOTE

For ISA Servers that are not domain members, local groups on the ISA server can be used in the same type of capacity. The only downside to this type of configuration is that it becomes more difficult to scale this configuration because groups and users have to be duplicated between individual servers.