Processing requests for access to a secure environment can be accomplished by combining a number of different types of protection mechanisms. The first line of defense is typically based on authentication, the primary purpose of which is verification of credentials revealing the requester's identity. The next step is authorization, which determines rights and privileges granted to the requester. The third mechanism — access control — has been traditionally configured directly on a protected resource level and would come into play only when a requester attempted to use it.

In this article we will look into an innovative way of combining authorization with access control introduced in the Windows Server 2003, called Authorization Management.

The main problem with access control results from the fact that while setting access control on files and directories residing on NT File System (NTFS) partition (or registry keys) is straightforward, this is typically not the case when dealing with applications. Even though it is certainly possible to built such functionality into an application, this tends to not only increase its development time but also its administrative complexity and cost — resulting mostly from a disparity between the way applications are developed and managed. The concept of Authorization Management is supposed to help eliminate this disparity.

Authorization Manager is based on the idea of role-based access control, which means that it uses a set of custom-defined roles to define how authorization is performed. Roles correspond to the way applications function in a business environment and are defined through higher- and lower-level actions (called, respectively, tasks and operations), each associated with permissions required to perform them.

Defining and Assigning Roles

An example of a role in an Active Directory environment would be an Account Creator, responsible for the task of creating new user accounts, which involves a number of lower-level operations, such as writing individual user attributes, setting user passwords, assigning a user to appropriate groups, and so on. Once a role (with its associated tasks and operations) is defined, you can assign it to a user or group of users, which allows them to perform corresponding tasks. Users and groups are derived typically from Active Directory, although you can also define so-called application groups, specific to Authorization Management (they serve as containers for Active Directory groups and users).

It is possible to either take advantage of existing Active Directory groups or define Lightweight Directory Access Protocol (LDAP) queries specifying criteria, based on which group membership is dynamically evaluated. A role can also be limited to a particular scope, which is collection of resources affected by its tasks (obviously what constitute a scope would depend on the type of application — and they must be defined by a programmer of this application before they can be used by its administrator). In addition, in Authorization Management, you can also define scripts, called BizRules that affect granting or denying access based on dynamically evaluated conditions (such as time that a request to perform a particular task has been submitted). Information about all these components, such as roles, tasks, operations, groups, BizRules, and scopes is maintained in an authorization store.

Two Roads to the Authorization Store

There are two types of authorization store — Active Directory (in a Windows 2003 functional level domain) and the file system (in the form of XML files). When using an Active Directory-based authorization store, it is recommended that you create a separate container in the Program Data container within the domain-naming context (CN=Program Data residing directly in domain DC container).

As you can imagine, the majority of the work involved in making an application suited for Authorization Management needs to be done during the development stage by accommodating business logic into application design, so that tasks — corresponding to their roles, operations, and scopes — can be clearly defined. However, there is also some additional work that you, as system administrator, are responsible for. The majority of this work will involve use of Configuration Manager management interface.

Windows 2003 Authorization Manager is implemented as an executable running on a server where managed applications are installed. This executable automatically loads configurations obtained from the authorization store contained in Active Directory or an XML file when a corresponding application initializes. The management of configuration parameters is performed with the Authorization Manager MMC snap-in, located in the Administrative Tools menu (if you do not see it there, make sure to rerun the installation of ADMINPAK.MSI and select the option to install all Administrative Tools).

Page 2: Inside the Administrator and Developer Modes