Exploring Windows 2003 Security: Authorization Manager

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.

Windows Server 2003 offers an innovative way to provide access to a secure environment. In the latest installment of our security series, we look at Authorization Manager’s roles-based approach to combining authorization with access control.

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).

Inside the Administrator and Developer Modes

Authorization Manager can operate in two modes — administrator and developer. You can switch between them by choosing the Option item from the Action (or context-sensitive) menu when the Authorization Manager top node is selected. Administrator mode permits managing existing applications. Developer mode includes all capabilities granted in administrator mode, but also allow for creating new authorization stores and new applications.

Administrator mode is the default and you should treat it as such, switching to developer mode only when necessary. Note that a number of actions might require appropriate privileges (e.g., the capability to create an Active-Directory based authorization store depends on having sufficient permissions to a target container).

Steps for Setting Up an Application

In order to set up a new application with Authorization Manager, follow the following steps:

• Start by creating an authorization store. This can be done programmatically or with the Authorization Manager MMC snap-in operating in developer mode. To switch to it from the default administrative mode, highlight the top level node in the tree pane of Authorization Manager, click on Options menu and select New Authorization Store option from the Action (or context-sensitive) menu. This will display the New Authorization Store dialog box, from where you can specify the LDAP path of the Active Directory-based store or file system path of XML file. As mentioned before, when using the Active Directory authorization store, you should create a new container under Program Data, by typing CN=MyAuthorizationStore,CN=Program Data,DC=MyDomainName, where MyAuthorizationStore would be your arbitrary choice and MyDomainName would be LDAP path of your domain’s naming context (e.g. DC=serverwatch,DC=com). This would result in the creation of MyAuthorizationStore being displayed in the Authorization Manager tree window pane. When creating an XML-based authorization store, keep in mind that a volume hosting it needs to be formatted with NTFS.
• Once the authorization store is created, you should ensure that its managers have appropriate permissions. This typically involves assigning the Administrator role to their Windows accounts using the Security tab on the application Properties dialog box (for Active Directory-based authorization store) or Security tab on the authorization store Properties dialog box (for an XML-based authorization store). Note also that a service account used by an application to run needs to have assigned the Reader role (from the same Security tab).
• The next step is the creation of an application within the authorization store. As before, this can be done programmatically or with Authorization Manager MMC snap-in in developer mode. The new Application option appears in the Action (and context sensitive) menu whenever an existing authorization store is selected. You are prompted to provide the application name (which has to match the name of the managed application) and, optionally, its description and version information.
• After these preliminary steps are completed, you are finally ready to install the application on the server. The installation process would typically take care of defining a set of operations and tasks, displayed in the Authorization Manager created previously under the application node. Installation commonly creates also some pre-defined roles, although an administrator has capability to define new ones, possibly better matching custom requirements. The roles are based on either the existing set of tasks or new tasks (using operations included in the application by its developer).
• Both pre-defined and custom-created roles will not take effect until they are assigned to corresponding application or Windows groups (or users). To complete the process, right click on the Role Assignments folder under the application node in the Authorization Manager MMC snap-in and choose Assign Roles item from the Action (or context sensitive menu). This will allow you to select the role definitions for which you want to create assignments. These roles will appear under Role Assignments folder. For each of them, in turn, you can specify corresponding Application or Windows group.

When an application that was configured using Authorization Manager is launched, it loads its configuration information from the authorization store (Active Directory or XML file) and applies its rules whenever a user connects to it. User credentials are evaluated against the role assignments and, depending on the outcome, permission to perform a task requested by the user is granted or denied.

We will look into more specific examples of using Authorization Manager in the next article, when discussing URL authorization, which we will cover in addition to other improvements relating to Internet Information Server 6.0.