Authorization Policy Storage

Applies To: Windows Server 2003 with SP1

When an application that uses Authorization Manager is initialized, it loads the authorization policy information from the store. Authorization Manager provides support for storage of authorization policy in Active Directory or in .xml files.

Active Directory Authorization Manager storage

To use Active Directory to store the Authorization Manager policy, the domain must have a functional level of Windows Server 2003. Active Directory in the Windows Server 2003 family contains schema updates for the Authorization Manager objects. When using the Active Directory store, Authorization Manager creates Active Directory objects for the store itself and child objects for each application group, application, operation, task, role, and scope. The scope object can contain tasks, roles, and groups that were created in that scope.

When using the Active Directory authorization policy store, applications control when application objects are loaded. When an application connects to the policy store, the stores global attributes (including store-level groups) are cached locally, along with header information for each application. When an application initializes its authorization policy using the OpenApplication method, the applications attributes, roles, tasks, operations, application groups, and header information for each scope are loaded into memory. Once an application is loaded, it remains cached in memory until the application object is freed. Scopes are loaded on demand; either the first time the scope is specified in a call to AccessCheck or when the scope is explicitly loaded using the OpenScope method. Once a scope is loaded, it remains cached in memory until the application object is freed.

Active Directory does not support enforcement of transactional writes on multiple objects or attributes, so it is possible that the store could be edited simultaneously by two administrative applications. In this situation, a store could become corrupted. Because of this, it is recommended that applications regularly back up their authorization store. For more information about Active Directory backup and restore tools, see "Active Directory" in the Windows Server 2003 Help.

Deployment considerations for Active Directory administrators

Application administrators can benefit from using Active Directory to store the authorization policy. The Active Directory store allows applications to take advantage of the existing domain infrastructure to provide the application with storage, availability, redundancy, and distribution of the authorization policy. Active Directory administrators who deploy Authorization Manager should consider the following information.

Domain mode requirements

The Authorization Manager Active Directory Store requires that the domain be in Windows Server 2003 functional level.

Authorization Manager Active Directory impact on infrastructure

Authorization Manager is a runtime that runs on the application server. It does not run any applications or services on domain controllers. Active Directory can be used to store the authorization policy data.

Applications that use the policy download application policy information when it initializes and downloads application scope policy as needed. When the application reads the policy information, the impact of the read on a domain controller will vary. The size of the authorization policy for an application or scope will vary with the number of roles, tasks, operations, and groups in the scope. Application groups vary in size, but it is recommended that you do not use application groups for large groups so that application performance is not affected. The size of the groups and roles can vary, but may be similar to Active Directory groups. The read of a group or role costs as much in processing time as the read for the members of an Active Directory group with the same amount of members. Application groups can have the same maximum size as Active Directory groups but are usually smaller than Active Directory groups because they are only used by an application. When possible, we recommend that people use Active Directory groups instead of application groups when groups with more than 5000 members are needed.

Proximity requirements

Applications need high-quality access to Authorization Manager policy. Even though individual applications may perform acceptably in low-bandwidth scenarios, unless they have small authorization stores, domain controllers should generally be within the local area network (LAN) of the application server.

Replication

The authorization policy store is replicated to all domain controllers in the domain in which the authorization policy is stored and Authorization Manager objects are referenced in each global catalog server in the forest.

A separate domain or forest could be used to store an Authorization Manager policy. You may choose to do this to minimize replication traffic within a domain, to minimize load on domain controllers in an account domain, or to have separate administrators manage the Authorization Manager policy store. Using a separate domain or forest requires that appropriate trust be established between the domain where user accounts are stored (the account domain) and the domain the Authorization Manager policy is stored in (the Authorization Manager storage domain.) The trust configuration that is required depends on what domain the accounts of the administrators of the Authorization Manager policy are in and which domain the application server and any back-end resource servers are in.

Deploying an Authorization Manager store in Active Directory

The following gives step-by-step instructions on deploying an Authorization Manager store in Active Directory.

1. Choose the Authorization Manager Active Directory store location.

   To deploy Authorization Manager in an Active Directory store, you must choose a location for the store. It is recommended that the administrator create a new organizational unit (OU) in the domains Program Data container and create a store object in the new OU. This recommendation is not enforced. If the application has data in a container other than Program Data, you can put the Authorization Manager store there.

   Authorization Manager cannot be placed in a non-domain naming context, which is also called an application partition.

2. Create an Authorization Manager store.

   Applications can create the Authorization Manager policy store in Active Directory themselves through the Authorization Manager API, or administrators can create a store using the Authorization Manager MMC. In order to do this, the user or application attempting to create a store must have Create Child Object permissions in the container that was chosen in the previous step and they must know the distinguished name of that container.

   For more information about creating a store using the Authorization Manager MMC snap-in, see Work with Authorization Stores in Authorization Manager Help.

3. Roles and authorization store access

   If the application administrator creates the store using a program, then they should already have permission to manage the store. If the store is created manually by an Active Directory administrator, permission to manage the store must be given to the application administrator who is using the store. Use the Authorization Manager MMC to grant the application administrator access to manage the authorization policy store. The authorization policy within the store is managed by the application administrator. The Authorization Manager Active Directory store allows the application administrator to delegate management of applications and scopes within the store.

   Since application service accounts that use the authorization policy must be able to read the policy store, the application service account must be included in the Readers role in for the appropriate store or application or scope within a store.

4. Enable the Windows Authorization Access group.

   Note

   This step is only needed if the application designers use either the InitializeClientContextFromName and InitializeClientContextFromStringSID methods to create client context objects within the application. Applications that use InitializeClientContextFromToken do not require this step. If you are not sure which APIs the application server will use, the application administrator or designer should know.

   These methods attempt to read the users token-groups-global-and-universal attribute in Active Directory to get the user's Active Directory group membership information. To read this information, the application service account must have Read access on this attribute on each user object.

   If the domain is configured for Pre-Windows 2000 Compatible Access mode (that is, the Everyone group is in the in the Pre-Windows 2000 Compatible Access group), then the Authenticated Users group will have access to call the InitializeClientContextFromName or InitializeClientContextFromStringSID methods by default. If the domain is set for Windows 2000 and Windows Server 2003 Compatible Access then, by default, only the Authenticated Users group will be in the Pre-Windows 2000 Compatible Access group. In this case, application service accounts will have the required access to call the InitializeClientContextFromName or InitializeClientContextFromStringSID methods. If the domain has been locked down (that is, Active Directory administrators have made the default access permissions more restrictive) it is possible that the Pre-Windows 2000 Compatibility Access group will be empty, in which case application servers may fail when calling the InitializeClientContextFromNameOfSID interfaces.

   In this situation, to grant access to the service account, it is recommended that, first, you add the service account to the Windows Authorization Access group, and then grant the Windows Authorization Access group access to each users token-groups-global-and-universal attribute if it does not already have that access. For more information about the Windows Authorization Access group (which is new for the Windows Server 2003 family), search for the term in the Microsoft Knowledge Base at https://support.microsoft.com.

Authorization Manager storage with XML files

Authorization Manager supports storage of the authorization policy in an .xml file that is stored on an NTFS volume. The XML store can be kept on the same computer as the server application using Authorization Manager APIs or it can be stored remotely.

In order to support renaming of objects, the XML format contains globally unique identifiers (GUIDs). Because of this, you should not edit the .xml file directly. Furthermore, the XML schema is not published currently. You can edit the store through the Authorization Manager MMC or through the Authorization Manager interfaces which are available to scripting languages, such as Microsoft Visual Basic Scripting Edition (VBScript) and JScript. The XML store does not support delegation because access to the XML file is controlled by the discretionary access control list (DACL) on the file which grants or restricts access to the entire contents of the file.

It is recommended that application administrators back up their authorization store regularly. The NTFS file system does not support applications issuing a sequence of separate write operations as a single logical write to a file when multiple applications write to the same file. (These operations are sometimes known as transactional operations.) Since an Authorization Manager policy store could be edited simultaneously by two administrative applications, a store could become corrupted.