Dynamic Groups in Windows Server 2003 Authorization Manager

 

Mohan Rao Cavale
Microsoft Corporation

January 2003

Applies to:
   Microsoft® Windows Server™ 2003
   Authorization Manager MMC UI

Summary: Introduction of role-based authorization groups and utilization of the dynamic group capability of Windows Server 2003, Authorization Manager. (8 printed pages.)

Contents

Azman Dynamic Groups
Background
Role-Based Access Control in Authorization Manager
Application Groups
Creating a Dynamic Group Using AzMan
Creating a Dynamic Group Programmatically
Conclusion

Azman Dynamic Groups

The increasing adoption of distributed application development has led to a heightened appreciation of application security. In the context of software, security involves asking two things: "Who are you?" and "What can you do?"

The first question refers to authentication, the process of proving one's identity. Once the principle (any entity that can be authenticated, such as a user or machine) is identified, the next step is to authorize access to a specific set of network resources based on permissions.

Windows Server 2003, introduces an authorization policy that is role-based. Role-based authorization allows administrators to easily implement a security policy based upon a company's organizational structure. A significant feature provided by the new role-based model is the ability to create groups of users. The groups are similar to the groups existing in Active Directory, but are maintained for a specific set of applications, a single application, or a scope within an application. Domain administration rights are not required to create and maintain role-based groups. In addition, group membership can be dynamically determined as the application runs, rather than having to be explicitly set before application execution.

Background

On Windows NT® or Windows 2000 systems, authorization takes place through the mechanism of access control, using entries stored in Active Directory as well as Access Control Lists (ACLs) that define permissions for system objects. Each object has an associated list of trustees (user account, group account, or login session) with specific sets of rights for that object. In order for an administrator to support a given application role, the administrator must enumerate all objects in the system and grant application users the appropriate access to them.

In an effort to streamline administration, Windows NT Groups were introduced to the security model. Windows NT Groups are a convenient way to assign rights and permissions to several user accounts at one time. All users who belong to a user group are granted all of that group's permissions or access rights. When a user logs on to a Windows NT or Windows 2000 domain, the operating system creates a unique access token for that user. This token identifies the user and all of the user's associated groups. Each time the user requests access to a shared resource or the user's account runs a program, Windows NT checks the token against permission settings and returns a verdict that determines whether the access is allowed.

As the number of objects in a system grows, it becomes cumbersome to query access given to a particular user or group for every object. While inheritance appears to simplify this, the ability for each object to avoid inheriting makes it necessary to inspect each object to fully understand the authorization policy. Often there are simply too many objects to examine, and the state of access control with respect to a particular group or user is frequently not verified.

The security of applications using groups with ACL-based access control also depends on timely ** maintenance of access control lists and the security principles that use them. Windows NT Groups are created and maintained by domain administrators. Many enterprises require a significant organizational process to respond to a request to create a new group or to modify an existing one. In the lag time between a request for group change and the domain administrator satisfying the request, some users may be either wrongly denied, or granted, access to an application or its required resources.

Role-Based Access Control in Authorization Manager

Windows Server 2003, introduces a new role-based access control interface, Authorization Manager, which does not require domain administration rights. Applications using this role-based access are constructed to use logical roles (such as "Sales Manager") pertinent to the tasks performed by the application. Specific users can be assigned to roles, or users may be collected into groups which are then assigned to roles. Authorization administrators design roles as collections of tasks supported by an application, then assigns users and groups to those roles to grant them the ability to perform the tasks.

Application Groups

Users gain access to the application when domain user and group accounts are assigned to the logical roles exposed by the application. Additionally, Authorization Manager supports an intermediate layer of grouping through the creation of application groups that are maintained in the Authorization Store. Users can be assigned to an application group and that group can then be assigned to application roles.

To help developers and administrators build and maintain applications, Authorization Manager supports two types of application groups: the basic group ** and the dynamic group (LDAP-query group). Either type of group can be used to assign users to the logical roles exposed by an application.

Application Basic Groups

The application basic group is a collection of member security principles, similar to a traditional Windows NT group. Unlike a traditional Windows NT group, however, it also contains a non-member (or subtractive) list of security principles. This allows for exceptions (traditionally performed with deny ACEs) on access to objects. Security principles added to the non-member list will never be a member of the group, even if they are granted membership directly or indirectly in the member list. That is, if everyone is granted access with the exception of Bob, who is on the non-member list, Bob will therefore not have access).

LDAP Query Groups

Often groups are created for collections of users that are identifiable by a particular attribute (or set of attributes) on their Active Directory accounts. For example, a Managers group could be created for all the members in Active Directory that have direct reports. This requires maintaining (keeping in sync) group membership with existing Active Directory information. If the Active Directory were updated to add direct reports to a user that previously had none, the Managers group would no longer be accurate until it too is updated.

To leverage the Active Directory properties and relieve administrators of maintaining the same information in multiple places, Authorization Manager provides the LDAP-Query Group. (LDAP refers to Lightweight Directory Access Protocol.) Membership in an LDAP Query group is determined using an LDAP query on a given user object. This frees administrators from managing memberships of these groups—membership is determined by the results of the query. Application administrators control membership by creating an LDAP Query group in terms of the properties on user accounts. That is, the Managers group is defined by an LDAP Query to determine all users with direct reports.

The following are some examples of LDAP queries that could be used to populate groups.

All adults

(age>=18)

All users in Germany

(country=Germany)

All adults in Germany

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

Creating a Dynamic Group Using AzMan

The Authorization Manager MMC UI (AzMan.mmc) is used to administer Authorization Manager applications. Using AzMan.mmc, the administrator can assign users and groups to application roles and create application groups.

Consider an application that allows all employees to submit expenses, but only allows managers to approve them. The company identifies managers by including the word "manager" in the user's title in the Active Directory information. The following LDAP query returns the set of managers:

(title=Manager)

Authorization Manager allows groups to be scoped to a specific application. The following two figures show how an administrator can create an LDAP Query Group using the Authorization Manager MMC UI. In the example, a new application group is created and scoped to the JetExpense application.

Figure 1 Creating a new application group

Each application group has a name (required) and an optional description. The group ** type (Basic or LDAP query) must be selected at the time the group is created.

Figure 2 Application group properties

On the Query ** tab, administrators can enter the LDAP query statement used to identify members of the group.

Figure 3 LDAP query for application group

Once the application group is created, it must be assigned to a role. Our sample application has a Manager role, which determines who has the authority to approve expenses. The actual members of the Manager role are determined by the users who are a part of the Managers group. The Azman.mmc user interface can be used to assign application groups to any particular role.

Figure 4 Assigning a group to a role

When the administrator chooses to assign an application group to a role, the list of application groups are presented, providing the ability to select any appropriate groups whose members are considered as part of the role.

Figure 5 Selection of application groups for a role

Creating a Dynamic Group Programmatically

The Authorization Manager also provides a programmatic interface to the authorization APIs.

The following code creates an authorization store and an application within that store.

'--- Initialize the admin manager object
Dim pAzManStore
Set pAzManStore = CreateObject("AzRoles.AzAuthorizationStore")

'--- Create a new store for expense app
' AZ_AZSTORE_FLAG_CREATE            = 0x1,
' AZ_AZSTORE_FLAG_MANAGE_STORE_ONLY = 0x2,
' AZ_AZSTORE_FLAG_BATCH_UPDATE      = 0x4,

pAzManStore.Initialize 1+2+4, "msxml://C:\AzPolicy.xml"
pAzManStore.Submit
'--- Create a Expense app
Dim App1
Set App1 = pAzManStore.CreateApplication("Expense")

With the application object an LDAP query group can be created.

'----- Create and LDAP query application group ------
'----- scoped to the application not the store ------
Set AppGroup = App1.CreateApplicationGroup("Purchasing Agents",VT_EMPTY)
AppGroup.Type = AZ_GROUPTYPE_LDAP_QUERY
AppGroup.Description = "Users with purchasing authority"
AppGroup.LdapQuery = _
  "(memberOf= CN=purchasers,OU=Distribution Lists,DC=enterprise,DC=com)"

'----- Persist the changes to the application group and then the app ------
AppGroup.Submit
App1.Submit

Finally the new group is assigned to the appropriate roles.

'--- Add Managers Group to Manager Role --------------------------
RoleB.AddAppMember("Purchasing Agents")
RoleB.Submit

Conclusion

Windows Server 2003, introduces Authorization Manager, which offers role-based access control. Administrators of role-based applications assign users or groups of users to the logical roles exposed by the application. The LDAP query group ** offered by Authorization Manager ** determines its group membership at runtime based upon Active Directory attributes, providing timely and accurate group membership while freeing administrators from the burden of maintaining duplicate information.