Authorization Manager and Role-Based Administration in Windows Server 2003 (Part 1)


Two important elements of network security are authentication (confirming the identity of a user or machine) and authorization (determining the level of access to be granted). Role-based security, at its simplest, merely refers to a type of authorization process that allows a user (or computer) to access some resources and not others, and/or to perform specific tasks, based on his/her/its “role” – for example, the user’s job title or position in the organization. Of course, this has been possible in Windows since the advent of Windows NT, through the use of built-in and custom-created security groups. Members of the Administrators group will have full system access, while members of the Users group will have much more limited access.

What’s different for software developers using the .NET framework (as opposed to COM+) and administrators using Windows Server 2003 (as opposed to NT/2000) is that Windows accounts are no longer the only way to define roles. The new implementation of role-based administration and security relies on the concepts of principals and identities. In this two-part article, we will discuss these concepts and show you how to use the Server 2003 Authorization Manager console to create role assignments. In Part One, we discuss the concepts and terminology and show you how to open the Authorization Manager tool, what it does, and how to create application groups.

First Things First: Concepts and Terminology

There are actually two types of roles that can be managed in the Microsoft role-based security model, authorization roles and computer configuration roles. Authorization roles are based on users’ jobs or positions and the tasks that need to be performed in those positions. Computer configuration roles are based what the computer is used for, e.g. web server, file server, remote access server, domain controller, etc. We will be discussing here how to manage authorization roles, so we will be talking about users rather than computers.

When we refer to identities, we mean information about authenticated users that includes the user name and the authentication type. Principals contain user identities as well as the user’s roles (thus from a developer’s point of view, these are nested objects, with the identity object nested inside the principal object.

The principal/identity object pair can either be based on Windows domain accounts, or on simple user names (with passwords) that are not related to the Windows domain.

Overview of the Authorization Manager Tool

The Authorization Manager can be used to set or change permissions and configurations at a high level, including making several changes simultaneously. It performs some of the same functions as other familiar tools, such as the ACL Editor and Delegation of Control Wizard (for user roles) and the Configure Your Server Wizard (for computer roles). However, Authorization Manager gives you more control and lets you go farther than these tools.

You can create a custom MMC and add the Authorization Manager snap-in, or you can open the predefined Authorization Manager console by typing azman.msc at the command prompt or Run box. The first time you open it, you’ll see the message shown in Figure A, advising you that no authorization stores have been selected.

Figure A

There are two modes in which Authorization Manager can run: developer mode or administrator mode. To create a new authorization store, you must put the Authorization Manager into developer mode (it starts in administrator mode by default). To do this, click the Action menu (or right click Authorization Manager in the left console pane) and select Options. Choose Developer Mode from the dialog box, shown in Figure B.

Figure B

Once you’re in developer mode, you’ll find that the choice New Authorization Store appears on the Action menu, as shown in Figure C. Click it.

Figure C

You can select one of two types of authorization stores:

  • An authorization store (AS) stored in Active Directory. This requires a domain operating at the Windows Server 2003 functional level (note that the default functional level for a Windows Server 2003 domain is Windows 2000 Mixed. In order to raise the functional level to Windows Server 2003, all domain controllers in the domain must be running Windows Server 2003. If you select to store the AS in Active Directory, you’ll need to designate the store name by its LDAP distinguished name, as shown in Figure D.
  • An authorization store stored in an XML file. If your domain must operate at a lower functional level (that is, if you have NT and/or Windows 2000 domain controllers), you’ll need to select this option. If you select to store the AS in an XML file, you’ll need to designate its location in the computer’s directory structure by its path (e.g., c:\Documents and Settings\Administrator\AuthStore1.xml). An XML store must be located on an NTFS partition.

Figure D

NOTE: To raise the domain functional level, open Active Directory Domains and Trusts, right click the domain name and select Raise Domain Functional Level. Then choose Windows .NET Server 2003. You must be a Domain Admin or Enterprise Admin (or have been delegated the authority) to do this.

If you create a new Authorization Store, you’ll also have to create or specify an application to use the store. To do this, select Action | New Application (still in developer’s mode). Roles that you define with Authorization Manager are specific to an application.

Application Groups

Although Windows group accounts (and user and computer accounts) are used in Authorization Manager, there is also a new type of group specific to Authorization Manager: application groups.  This is a group of users, the members of which will receive the authorization policy defined for the particular application.

An Authorization store contains one or more applications under it, and each application contains one or more stores under it. Groups can be defined at any of these three levels: at the authorization store, at an application, or at a scope.

When you open an Authorization Store, you’ll see a folder named Groups under the store name (and in the right console pane).  You can create a new application group by right clicking the folder and selecting New Application Group…, as shown in Figure E.

Figure E

You’ll be asked to type in a group name and description and to define whether the group will be a basic or an LDAP query group, as shown in Figure F.

Figure F

A basic group is made up of Windows user and group accounts, and/or other application groups. An LDAP query group’s membership can be dynamically calculated based on LDAP queries.

The new group will now appear in the right console pane when you click the Groups folder. Now you can define the members and non-members of this application group. Right click the group name in the right console pane, and select Properties. This opens the dialog box shown in Figure G.

Figure G

You can add other application groups to the group, or you can add Windows user or group accounts to it. Non-members are defined in the same way. If the same user is defined on both tabs (as both a member and a non-member), that user will be considered a non-member.

NOTE: You can delegate the administration of an Active Directory authorization store and its applications to any user by adding the Windows account in the Properties sheet of the store, on the Security tab. You can’t delegate administration for a store that’s stored in an XML file.


Next month, in Part Two of this article, we will discuss how to create role assignments within an application, how to configure role definitions, and how to create and work with scopes.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top