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
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 StoreThere 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
Inside the Administrator and Developer ModesAuthorization 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.
Feature courtesy of ServerWatch.