Exploring Windows 2003 Security: Authorization Manager
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
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