Professional Windows Server 1002003 Security A Technical Reference [Electronic resources] نسخه متنی

Authorization Manager Framework

The Authorization Manager Framework enables the development and administration of Role-Based Access Control (RBAC) programs. Developers use the Authorization Manager Framework's Authorization Manager RBAC application programming interface (API) to develop the application, including the definition of user roles. Administrators use the Authorization Manager Microsoft Management Console snap-in to manage the applications by assigning user groups to role definitions.

Before you can administer these applications, you must understand how they are developed and how they work. The secret to understanding and championing Authorization Manager is to understand that it moves the responsibility for partitioning access to information resources from the administrator to the application.

The Authorization Manager application is pre-programmed to respond to the role of the user interacting with the program. The role, defined as part of the application, is explicitly designed to provide rights and permissions that allow the role holder to do her job and no more. The role might be allowed, for example, to run only certain parts of the program and only read some data while having permission to write, delete, or otherwise manipulate other data. At first glance, this may appear to provide control over computer system resources to the developer. However, in a properly managed development environment, developers work from and are held accountable to specifications developed by the data owners. An application developed to print payroll checks, for example, might have roles such as payroll clerk and payroll manager. Payroll department staff must develop the specifications that define what each role is allowed to do within the program and what files and printers role users may access. Payroll management approves the design and tells IT which employees should be assigned which roll. The system administrator maintains application control by assigning the correct users to the application roles.

The ordinary application, by comparison, does a poor job of granting and denying access to resources. The ordinary application sees data storage as a gray landscape of objects that it can or cannot manipulate depending primarily on the security context of the user. If it needs to interact with the internal processes of the computer, the ordinary application switches context and operates as programmed in ignorance of the security context of the user. Thus, management of the ordinary application is fractured. Authorization to run the application is separate from the right to access resources. To manage ordinary applications, the system administrator must only decide who is authorized to run the application. She manages resources that the application might use separately. The administrator protects resources by determining what rights a user should be granted or denied and which objects a user should have permission to access. Application authorization and resource authorization are disconnected. In addition, while the administrator may grant a user permission to execute a specific program, she may not grant the user the right to run some part of the application while denying the user access to other parts of the application. There are exceptions to this. Both database applications and COM+ applications may have roles defined within their structure. Database administrators assign users to database roles.

In a well-defined and relatively static environment, the system administrator can manage the ordinary application and the burden of assigning rights and permissions. In the well-managed environment, data owners define who should do what with their data, and the administrator can mold the operating system authorization design to fit these requirements. In a relatively static environment, change is slow, so there is time to make these decisions for new applications and weigh the impact on older ones. Many organizations do not provide a well-defined or relatively static environment, though. Change often occurs rapidly, data owners and administrators sometimes don't communicate well, and applications are often adopted that require elevated privileges to run, not because of the way they must function, but because they were poorly written.

The secret to successfully adopting Authorization Manager is to realize that it will not solve the problems created by the past. It cannot be put to use to manage wayward applications or magically relieve the administrator of the burden of assigning rights and permissions. What Authorization Manager can do is provide the infrastructure for which applications can be developed to change the paradigm for the system administrator. For all Authorization Manager applications, the administrator does not need to assign individual users or groups access to objects; she merely has to respond to application owners' identification of which users should play what role in the application.

If this concept appeals to you, you will need to work with data owners and application developers to produce applications that can be managed by Authorization Manager. Writing applications that support RBAC is not within the scope of this book; however, managing such applications with Authorization Manager is. You may be asked to administer such an application, or you may be key in recommending that applications be written that are Authorization Manager-enabled and thus can provide RBAC.

NOTE: Authorization Manager on Other Platforms

The Authorization Manager RBAC API can be obtained for Windows 2000 from http://www.microsoft.com/downloads/details.aspx?FamilyID=7edde11f-bcea-4773-a292-84525f23baf7&displaylang=en and can be used to develop Authorization Manager applications. Authorization Manager applications can only be administered using the Authorization Manager snap-in from a Windows Server 2003 server or a Windows XP Professional computer on which the Windows Server 2003 Administration Pack for XP has been installed. However, to create Authorization Manager stores in the Active Directory, the domain must be in Windows Server 2003 functional mode.

The following information can help you understand the basics of Authorization Manager and the steps that will need to be taken to use it.

Authorization Manager Basics

Authorization Manager provides a single interface that administrators can use to manage multiple applications. Authorization Manager-enabled applications, however, must be written to contain the necessary components to provide a deeper level of access control.

Application developers define the components that define the roles within the application. The application installation program populates the authorization policy, a set of rules that define the application roles. The authorization policy is stored in the authorization store and exposed in the Authorization Manager snap-in for use by the administrator. If the installation program does not deliver the authorization policy, components can be created directly in the Authorization Manager.

NOTE: Administrator's Role

The administrator's main responsibility is to assign Application Groups, Windows Groups, and Users to roles and to add users to groups, thus conferring upon them the appropriate role. However, administrators should understand how the process works so that they may understand the rights and permissions granted on their systems when a user is given a role.

To aid your understanding of how Authorization Manager applications work, the sections that follow both define the components and provide instructions on how they can be created in Authorization Manager. To perform many of these operations, you will need to change the operation mode of the Authorization Store from Administrator mode to Developer mode. Administrators cannot create applications, authorization stores, or operations and cannot change application names or version numbers. To change to Developer mode, add the Authorization Manager to an MMC console, and then do this:

A complete Authorization Manager application requires the development of the following components:

Authorization Store
The repository for the security policy.

Groups
Entities that can be assigned roles.

Application
Defines the relationship between the applications written to be managed by Authorization Manager and the authorization store.

Scope
A file folder or other resource used by an application.

Roles
A collection of related tasks that must be accomplished.

Tasks
A collection of operations.

Authorization Scripts
Scripts that check a user's authorization to perform a task.

Operations
Lower-level operating system.

Authorization Store

An Authorization Manager-based application reads its security policy from its Authorization Store during startup. The security policy consists of rules that indicate what a specific role can do. There is no default Authorization Store; instead, an Authorization Store is created for a specific purpose. Authorization Stores can reside in the Active Directory or in the NTFS file system (local or remote) in an XML file. Secure the file using ACLs. Table 4-1 illustrates the differences between the two types of stores.

An Authorization Store can be created programmatically, or manually in the Authorization Manager. When items such as groups, roles, operations tasks, and so forth are created in the Authorization Manager console, their information is added to the Authorization Store. To create a store, follow these steps:

NOTE: Delegation

Delegation in the Active Directory is a way of assigning administrative responsibility to users who are not members of the Administrators group. Delegation is accomplished by assigning user group permissions on Active Directory objects. Because an Authorization Store that is stored in the Active Directory is an object, you can delegate authority over the store and the objects within it. XML-based Authorization Stores are not in the Active Directory and do not support delegation.

Groups

Groups are used to assign roles to users. Roles are assigned to groups, and administrators place user accounts in groups. Special groups can be created in Authorization Manager, or Windows groups can be used. If Authorization Manager groups are used, they can be created just for use by an application or even a scope within the application. The group nomenclature is as follows:

Application Groups
A group of users in an Authorization Manager application. They can be created at all three levels in the console: Authorization Store, Application, and Scope. A group created in an upper level can be used at a lower level, but a group created at a lower level cannot be used at an upper level. Application groups are either Application Basic Groups or LDAP Query Groups.

Application Basic Group
Includes a list of members and a list of non-_members. A list of non-members is used to deny access to some subset of the larger, allowed access group. A group, therefore, might be provided access to the application but denied access to some subset of the application. Non-membership takes precedence over membership. Basic groups can be Windows Users and Groups or LDAP Query Groups.

Lightweight Directory Access Protocol (LDAP) Query Groups
This is a dynamic group defined by an LDAP query. Any user attribute can be part of the LDAP query. For example, a query group could consist of all those users who live within the city limits of Chicago. Over time, this group might change. Other groups may be more volatile. An example would be all those users who had a birthday during the current month.

Windows Users and Groups
These are standard user accounts and groups, either default or custom. When a role is assigned to a group, you can choose Windows Users and Groups or an Application Group.

To add a group:

Application

The development of each Authorization Manager-based application determines how roles will function within the application. The assignment of roles and users to groups defines who can perform which roles. The application object in Authorization Manager is created within its Authorization Store and contains the objects that define the RBAC present in the application. An application can exist in only one Authorization Store, but an Authorization Store can contain multiple applications. Table 4-2 lists common tasks the Authorization Manager application supports and compares them to the processing within an ordinary application.

When you manage or participate in the development of an Authorization Manager application, you can manage roles in a different and very natural way. To create an Application object in the Authorization Manager, follow these steps:

Scope

Scopes are created within each application to restrict access to resources. A scope specifies resources such as file system folders, Active Directory containers, types of files (such as all *.doc files), URLs, and registry hives. You create Authorization Manager groups, role assignments, role definitions, or task definitions and assign them to the application scope rather than the application. (Operations, however, cannot be defined at the scope level.)

The groups created within the scope have access to the resources they define, while groups created in the application can be assigned access to resources in the entire application including the scope. Using scopes is a good way to restrict the access of some users while empowering others.

A scope can be an NTFS folder, an Active Directory container, a collection of files identified by a mask such as *.doc (a file-masked collection), a URL, and so on. These containers are identified in the Authorization Manager within the Application container.

To create a scope:

You must be careful when creating scopes to make sure they identify resources in a manner that the application can understand. Two things are important here. First, the resource should be identified by location, such as by using file paths, registry hives, or complete URLs, or by identifying existing Active Directory Organizational Units. Second, the application itself must be able to understand the resource. Web-based applications might have URLs as scope identifiers, while file-based applications might use file paths.

To effectively limit access to resources by using their location, follow these steps:

NOTE: Reasons to Use Authorization Manager Groups

You should use Authorization Manager groups for two reasons. First, using these groups provides more control over object access. Second, when Authorization Manager groups are used, the application may be more easily used in both workgroup and domain situations. This is because workgroup machines have different Windows groups from those that are available in the Active Directory. An application designed using Active Directory-based groups could not be used in a workgroup. Note, however, that an application developed specifically for an Active Directory environment may have no useful purpose in a workgroup. You should make your decisions on the types of groups to use based on the application requirements.

Roles, Tasks, Authorization Scripts, and Operations

In an Authorization Manager application, tasks, operations, and authorization scripts define roles. Tasks are composed of lower-level tasks, operations, and authorization scripts. Operations are single units of lower-level operating system functionality. For example, a Help Desk task might be "reset password" for users within a specific organizational unit (OU). A task created within the application might be named ResetPassword. An operation, also created in the application, includes a reference to a number identifying the actual code within the application that allows the user to reset passwords for users within his assigned OU. The operation is assigned to the task, and the task is assigned to the help desk role. Finally, when the role definition is complete, it is assigned to the group created to identify users who will be assigned the help desk role.

When the application is written, operations are programmed. During the development of an Authorization Manager application, the elements for each role are written. During the application's installation, the tasks and operations that define the role populate the Authorization Manager, along with the groups and other application components.

You may have to manually add roles, authorization scripts, tasks, and operations to the Authorization Manager. Just remember that they must correspond to the programmed application, and the numbers defined in the operations forge the links between the Authorization Manager and the application code.

Roles

Before you can control authorization by using roles, the roles must be defined. You do this by adding defined tasks and operations to the roles. Roles can be defined across multiple applications but managed from a single location. Roles can also be confined to specific applications and even to limited resources within the application.

The first step is to identify the roles required. To define roles, think of each one as an abstraction that corresponds to real-world operations and tasks. Help desk operator and systems administrator are roles that might be defined if the application were built to control systems operations. Payroll clerk, accountant, and accounting manager are roles that might be defined for an accounting application. During the development process, a specification based on the real-world tasks of each type of employee is identified. Each task is further broken down into smaller steps or operations.

A well-designed role is one that maps to a job category or responsibility. You can easily find loose role definitions in job titles, but you will need to search beyond the title to determine what it is that the individual actually does. Remember that many employees participate in discrete business functions, and job titles do not always map to specific roles within an application. The process of building a role within an application consists of the following tasks:

Selecting a name

Providing a definition

Specifying lower-level tasks, roles, and operations that are part of the new role. Authorization rules may be written in scripts such as VBScript. Tasks become part of a role definition and can be added or viewed in the Role Definition container.

While the approval for membership in a specific application role is not an administrative task, the actual assignment of a user account to a role is. As usual, understanding what access and rights you are conferring with this assignment is critical. You need to know when a user's access or activity is normal and approved, and when it might represent a breach of conduct, such as an attack upon the system.

NOTE: There's More Than One Way to Create the Role

You can, of course, create all operations first, and then create each task and assign operations to the tasks as you create them. You'd follow this operation by creating roles and adding tasks to them as you create them.

To create and define a role in Authorization Manager, you must create tasks and operations and assign them appropriately. The first step in creating a role in the Authorization Manager is to create the role definition. To do so, follow these steps:

Tasks

Roles are composed of tasks. Tasks are collections of operations, authorization scripts, and possible other tasks. Tasks must be well defined and must be associated with roles. Well-designed tasks represent recognizable work items. Examples of well-defined tasks are as follows:

Change password

Enable an account

Create a user

Submit an expense

Approve an expense

Sign a check

Examples of tasks that are not well defined are:

Manage employees

Supervise the accounting department

Help users with their computers

To determine which tasks should be defined for a specific role, you will need to identify the things that might define what a person performing a role does. For example, a network administrator might change the ACLs on a router. A help desk person might change passwords or reset locked out accounts. Like roles, tasks are defined in the Authorization Manager by identifying a name and description. A task consists of lower-level tasks or operations and authorization scripts.

To create a task, perform the following steps:

Operations

Operations are a set of permissions associated with system-level or API-level security procedures. Examples would be WriteAttributes or ReadAttributes. Operations are building blocks for tasks. Operations are set only at the application level, not at the Authorization Store or scope level. The definition of an operation includes a name, description, and an operation number. The operation number is used within the application to identify the operation. The operation number is critical because it ties all actions between the Authorization Manager and the application. Because tasks include operations, roles specify the tasks that can be accomplished, and groups are assigned roles, when you add a user to a group, you are giving the user whatever low-level operations make up the tasks assigned to the role.

WARNING: Prevent Operations Number Errors

The number must be an integer from zero to 2147483647. If you must manually enter the number, be sure that it is correct; an incorrect number will cause a bug in the application.

For example, if a number of operations defines the lower-level actions necessary to format the hard drive, and the operations make up the "format disk" task, which in turn is assigned to the Server Manager role, which is assigned to the Application Group ServerManager, then by putting a user in the ServerManager Application Group, you have given her the right to format the hard drive.

To create an operation, do the following:

Create Authorization Scripts

Authorization scripts are created to implement authorization rules. An authorization rule tests conditions to determine if a user has the right or permission required to perform a specific task. For example, users may belong to a group that has been assigned a role. The role is defined by tasks that empower a role member to complete some task, such as reading a file. An authorization rule can be used to take into consideration the operating systems rights and object permissions assigned to the user. If the file permissions do not allow the user to read the file, then he will not be allowed to, even though the members of his Application Manager Application group may normally do so. Scripts can be written in VBScript or Jscript and are usually written by programmers.

Define Tasks

Define the task by assigning operations:

Define Roles

Finally, you must define the role by assigning it a list of tasks it may perform:

Assign Roles to Groups

Finally, assign roles to groups:

Authorization Manager Basics Summary

Within Authorization Manager and within specific applications, each role is assigned the right to exercise tasks and operations. The role is assigned to a group, and the group becomes the interface that you, as administrator, will use to assign Windows accounts or groups authorization to use an application and work with resources. Instead of managing resources for the application, you will manage actions and workflow. For example, instead of using the Delegation of Control wizard or directly assigning a user account or group the reset password permission on the OU, you will simply add the user's account to the group in Authorization Manager that has been assigned the help desk role.

If access to objects and the rights to run parts of the application are defined, then the administrative role is simple. Instead of hundreds of discrete actions in which you create Windows groups and assign them rights, permissionss on Active Directory objects, file objects, registry hives, and other resources, you simply place user accounts or Windows groups into the groups that define the roles.

NOTE: Administrators Need to Know

Administrators are not responsible for building Authorization Manager applications, defining roles, scripting tasks, or authorizing operations. These are developer functions and can be carried out programmatically or by using the Authorization Manager in Developer mode. The administrator's main responsibility is to assign Application groups and Windows groups and users to roles and to add users to groups, thus conferring upon them the appropriate role. However, administrators should understand how the process works so that they may understand the rights and permissions granted on their systems when a user is given a role.

The Authorization Store contains the information required to build the security policy for the application and physically represent it in the Authorization Manager. When the Authorization Store is located in the NTFS file system, it is represented in an XML file. Figure 4-17 is the XML file created by adding the objects defined in the exercises in this section.

Auditing Authorization Manager

Event auditing for Authorization Manager Applications can be configured and events will be recorded in the Security event log. Two types of auditing of Authorization Manager are possible:

Runtime Auditing
Audits are generated when policy defined in the Authorization Store is used. Auditing can report success, failure, or both. Client context and access checks are audited. Runtime auditing can be defined for the Authorization Store and the application. It cannot be defined at the scope level.

Authorization Store change auditing
Audit records are generated when the Authorization Store is modified, regardless of location. Active Directory-based Authorization Store change auditing can be defined for Authorization Store, application, and scope. XML Authorization Store change auditing can only be defined at the Authorization Store level.

To turn on auditing, use the check boxes on the Auditing tab, as displayed in Figure 4-18. If auditing of a specific type is not available, the check box will not appear. If the success and failure boxes do not appear, auditing is being managed at a higher level. To change it, you will have to find where it is being managed (locally or Group Policy at the domain or OU level) and modify it there first. All applicable object auditing will be inherited. For example, object access auditing specified on a file in the file system that is a resource in an Authorization Store is inherited. To define auditing the following must apply:

You must have the Generate security audits privilege.

You must have the Manage auditing and security log privilege.

Object access auditing must be turned on either using Group Policy or Local Security Policy as appropriate.

Authorization Manager Administration

The administration of Authorization Manager-enabled applications is an easy task if administrators understand how it works and how Authorization Manager applications work. The primary task is to assign users to the groups used in the roles. The administrator may have to participate in the assignment of groups to roles and other tasks if the applications do not programmatically do so. However, like most administrative tasks, simple actions disguise complex operations. The knowledgeable administrator will understand these consequences, audit the activity, and restrain from duplicating or obviating the results by using her power to distribute access to resources and rights that should be left managed by the application.

It may be prudent to limit the number of administrators who can work with Authorization Manager. You can do so by defining the groups and users that may have Administrative access to Authorization Manager. Add or remove groups and users from the Security tab of the Authorization Store properties, as shown in Figure 4-19.