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:
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:
In Active Directory, Global Groups were created at CompanyABC to correspond to each of these groups, such as the following:
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:
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.
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.