Application Administration

Applies To: Windows Server 2003 with SP1

After installing an application, the job of the administrator is to add any new roles required, verify the permissions on the initial roles (if present), and assign users to roles. If the application creates a complete set of tasks with meaningful names, the administrator's job of setting up initial roles is much easier.

The point of role-based access control is make administration more intuitive and manageable. To do so, administrators must devise a strategy for deploying roles within the application that resembles the user job descriptions. Once the roles are established, the administrative focus is primarily managing memberships within the roles, so it is very important that you verify each role's permissions. Generally, it is safer to grant each role only those permissions that are needed immediately and then add permissions as needed, rather than granting too many permissions and then removing unneeded permissions later.

Managing scopes

Often, the applications manage the creation of scopes and the administrator then creates and manages the roles within a scope. This way, the administrator does not have to know the applications scope syntax and the application logic that is used to associate user access request to a scope.

When applications allow administrators to create scopes, the application must provide documentation so that the administrator understands how to create scopes that are named correctly, since scopes are defined by each application and the application will map each access request to the appropriate scope.

Scopes allow administrators to group application resources into physical or logical collections and specify different authorization policy in each scope. Since tasks and role definitions can be created so that they are global to the application (in other words, visible to all scopes), roles that are created for different scopes can use the same global role definition and have different memberships. This prevents the need to redefine the permissions in each scope. Such a technique is useful when a role or task, such as Administrator or Full Control will have the same permissions in each scope but different people assigned to it.

Important

Authorization Manager applications have a default scope. Permission that is granted to roles in the default scope apply in all scopes in the application. For this reason, the applications default scope should only be used for role assignments that apply to all scopes in the application.

Role inheritance

Since the process of establishing roles involves assigning user permissions, it requires special attention. To minimize the validation and analysis that is required, a hierarchal role model can be designed that leverages the work that was done on establishing existing roles when creating new roles.

Figure 3: Role hierarchy

Role definition involves tasks and operations that define the permissions for a role. Using role definitions allows roles to be defined hierarchically, using existing roles to create new ones.

Delegation of administration

When using the Active Directory Authorization Manager policy store, Authorization Manager supports delegation of administration at the authorization store, application, and scope levels. This allows higher-level administrators to give limited access to others to manage some subset of the authorization policy. The store, application, and scope objects can each have a set of Administrators and Readers. Administrators of a store, application, or scope can perform all operations that are needed to manage the authorization policy within the delegated scope, and Readers can only read the authorization policy. Additionally, users who have been delegated authority of a scope or application must be added to the Delegated User administrative role of the store. This allows the delegated user to view groups that are created at both the application and the store level.

When a scope has been delegated (because one or more principals are in the scopes Administrator role), BizRules cannot be added to tasks or role definitions that were created in the scope. Delegated scopes can use BizRules that are attached to tasks and role definitions at the application level. Store-level administrators can also globally prevent all BizRules from running by setting the ScriptEngineTimeout store level value to 0. After doing this, AccessCheck assumes that existing BizRules will return as false and access will not be granted through task or role definitions containing a BizRule.

Using Authorization Manager application groups

Authorization Manager introduces two types of groups which can be used by Authorization Manager applications to facilitate applications that need to maintain groups of security principals: application basic groups and LDAP query groups. (These are discussed in more detail later in this paper.) Authorization Manager application groups can be global to an Authorization Manager policy store and can be used by all applications within the store, specific to an application and used by all scopes in the application, or specific to a single scope. Some applications need to manage groups of users without having to depend on updates to domain groups that may be managed by different people. Domain administrators may have requirements to keep the number of groups low without managing application-level groups. Latency may exist between the application administrators request and the actual changes to the Active Directory groups. Additionally, some groups are only needed for certain applications and, if the application can manage the group memberships, the domain administrators does not have to.

Application basic groups

An application basic group is similar to a traditional Windows domain group in that it is a collection of member security principals, but it is unlike traditional groups in that it also contains a non-member or subtractive list of security principals. This allows for exceptions that traditionally use Deny access control entries (ACEs) on objects. Security principals that are added to the non-member list will never be a member of the group, even if they are directly or indirectly granted membership in the member list. Application basic groups store security identifiers (SIDs) for each member and nonmember, so growing application groups will result in growth of the Authorization Manager store. Since applications load portions of the authorization store into memory, large group and role memberships can increase the time required to initialize an Authorization Manager store, application, or scope object.

As application groups become very large:

• Performance for initialization of stores, initialization of applications, and calls to AccessCheck are affected.

• The application requires more memory.

• There is more load on domain controllers when applications initialize and refresh the loaded policy.

• The membership of the application groups tend to change, which requires more frequent refreshing of the cache.

Because of this, it is strongly recommended that, as application groups grow to around 2000 members, that they be converted to Active Directory groups. (For more information about performance, see Performance, later in this paper.) A users Active Directory group memberships are determined when the user logs on or when the user context is created and do not affect the time required to initialize an Authorization Manager store, application, or scope.

LDAP query groups

Often, groups are maintained in Active Directory for collections of users that have similar attributes on their Active Directory accounts. For example, users who work in a given cost center may be in a group for the cost center, even though the cost center information is maintained as an attribute on each users account in Active Directory. When the user moves from one cost center to another, the administrator must update both the cost center group and the cost center attribute on the user object. To leverage the users properties and relieve administrators of maintaining the same information in multiple places, Authorization Manager provides the LDAP query group.

Membership in an LDAP query group is determined by using an LDAP query on a given user object. This allows applications to use these user attributes as groups in roles and frees administrators from managing memberships of these groups. Application administrators control membership by creating an LDAP query group in terms of the properties on user accounts. The following are some examples of coding for LDAP query groups.

All members of the Managers group:

(memberOf= CN=Managers,OU=Distribution Lists,DC=nwtraders,DC=com) 

All members over 18 years old.

(age>=18) 

All users in Germany

(country=Germany) 

All users over 18 years old in Germany

(&(age>=18)(country=Germany)) 

LDAP query groups require that the connected users account is maintained in Active Directory, but they are also supported when using the XML-based Authorization Manager policy store. LDAP query groups are evaluated when AccessCheck is called, therefore, the AccessCheck call will take more time to complete when the LDAP query is used to populate roles, because evaluating the query will require a LDAP search in Active Directory. While membership in an LDAP query group is cached for the life of the client context, initial AccessCheck calls are slower if many LDAP query groups must be evaluated.

Enterprise-wide roles

Since Authorization Manager roles are defined in terms of the permissions that a role will require within an application, a role cannot span across applications. To have roles in distinct applications have the same memberships, use common groups to populate application roles. This can be done using Windows groups or application groups if the applications are managed in the same Authorization Manager policy store. These groups are visible to each application and can contain the members for roles that are defined in multiple applications. Then, in each application, these groups can be assigned as members of the roles. By using Active Directory global or universal groups to contain role membership, application roles can have similar memberships across applications and Authorization Manager policy stores in an organization.