3.2 Access control

 < Day Day Up > 



In its first-generation servers, Exchange implemented its own access control model through permissions placed on objects and held in the directory store. Now, Exchange 2000 and 2003 use the Windows access control model, and every object-databases, mailboxes, public folders, and so on- has an Access Control List (ACL) composed of Access Control Entries (ACEs) that link Security Identifiers (SIDs) to access rights. Table 3.1 lists some of the major differences between the current Exchange access control model and the model used by the first generation.

Table 3.1: Exchange Access Control Models

Access Control Model

Exchange 2000/03 and Windows 2000/03

Exchange 5.5

Objects controlled

Everything used by Exchange, including Store objects; has a Windows ACL.

Exchange maintains its own permissions for objects in its DS.

Granularity

Object

Container

ACE types

Grant and deny

Grant only

Valid holders

Any Windows security principal

Only Exchange objects can hold Exchange permissions.

Increased granularity is the most important difference between the two models. Exchange is now more capable of controlling how objects inherit access control lists from parent containers. For example, in Exchange 5.5, if you set permissions at the organization level, all sites inherit the same permissions. Now, you can decide whether permissions flow from one container to the next and both grant and deny permissions rather than just granting permissions. For example, you can allow an administrator to manage everything on a server except a specific mailbox store that holds confidential mailboxes. This type of granularity is not possible in Exchange 5.5.

As an example of how ACLs work in practice, when you look at the Mailbox Rights for a mailbox (Figure 3.2), you view a human-friendly version of the ACL that displays the accounts and the permissions that the accounts hold for the mailbox. In this case, you can see the account of the mailbox owner plus anyone who can connect to the mailbox for other reasons, such as an administrator who looks after someone's calendar or a service account.

click to expand
Figure 3.2: Mailbox permissions.

By default, Exchange does not display the Security property page for the organization or administrative groups. To force the page to display, edit the registry at:

Key: HKCU\Software\Microsoft\Exchange\ExAdmin Value: ShowSecurityPage (DWORD)

Set the value to 1 and restart ESM and you will be able to see the security information.

3.2.1 Administrative delegation

Exchange is a complex application that interacts with many other Windows components at different levels. Exchange also depends on the Windows security model to implement access control to different data, such as mailboxes, configuration data, and public folders.

To protect data properly, you need to use an account that holds extensive Windows administrative permissions to prepare the forest and its domains and then install the first Exchange 2003 server (Figure 3.3). The level of permissions required to perform various actions reduces in a controlled manner. Table 3.2 provides an overview of some important actions in the lifetime of an Exchange organization and the permissions you require to execute these actions, while Figure 3.4 illustrates the group membership that a "highly permissioned" account holds to prepare a forest for Exchange and then install the first server.

click to expand
Figure 3.3: Permissions on an Exchange organization.

Table 3.2: Permissions Required for Various Tasks

Action

Required Permissions

Run ForestPrep within the forest for the first time

Member of the Enterprise Admins group and Schema Admins group

Run ForestPrep subsequently

Hold Exchange Full Administrator permission for the organization

Run DomainPrep in a domain

Member of Domain Admins group

Install or upgrade first Exchange 2003 server in the organization

Hold Exchange Full Administrator permission for the organization

Install or upgrade first Exchange 2003 server in a domain

Hold Exchange Full Administrator permission for the organization

Install or upgrade first Exchange 2003 server in an administrative group

Hold Exchange Full Administrator permission for the organization

Install subsequent Exchange 2003 servers in a domain or administrative group

Hold Exchange Full Administrator permission for the target administrative group. Note that the machine account for the new server must be added to the Exchange Domain Servers security group by an administrator who can update this group's membership.

Upgrade an Exchange 2000 server that acts as a bridgehead server for a Directory Replication Connector

Hold Exchange Full Administrator permission for the organization

Install or remove Exchange 2003 server with SRS

Hold Exchange Full Administrator permission for the organization

Install Exchange virtual server in a cluster (after first installation)

Hold Exchange Full Administrator for the administrative group. Note that the installation program will allow you to select any administrative group, even if you do not hold the appropriate permission to install the virtual server into that group. If you select a wrong administrative group, the installation program displays an "Access Denied" error message.

click to expand
Figure 3.4: A highly permissioned account.

During the ForestPrep portion of the installation procedure, you are asked to nominate an account (that should already exist) to become the first holder of Exchange Full Administrator permission. You can then use this account to delegate administrative control over the organization or specific administrative groups to other accounts.

As we have seen, Exchange uses a hierarchical structure for its organization. The organization is the top level for permissions, followed by the administrative group and then an individual server. Permissions flow from top to bottom, so if you have rights over the organization, you can pretty well do what you want to any server. Behind the scenes, rights are instantiated as entries in Windows Access Control Lists placed on various objects. Windows allows a fine degree of granularity within its security model, so Exchange uses a role-based model to delegate permissions within the organization. In this respect, a role is a collection of rights necessary to perform actions on Exchange data. You delegate roles to users with the Exchange Administration Delegation wizard.

You begin the delegation process by deciding on the level at which to delegate access, selecting either the organization or an administrative group. Figure 3.5 shows the menu revealed when you right-click on an administrative group. Selecting the "Delegate Control" option invokes the Administration Delegation wizard.

click to expand
Figure 3.5: Delegating control over an administrative group.

When the wizard starts, it displays a list of the users who already hold administrative permission for the selected object. Some of the users inherit their permissions from the organization, while others have already been delegated permissions for this level. If you look at the top left-hand screen in Figure 3.6, you can see the Windows accounts, the roles they currently hold, and whether they inherited the role.

click to expand
Figure 3.6: Running the Delegation wizard.

You can now select one of the existing holders or add a new account or group to delegate control over the object. Best practice is to use groups whenever possible, because it is easier to maintain permissions when they are group based. In this case, we select a user account (top right-hand screen) and then select the role we want to delegate. You have three options:

  • Exchange Full Administrator means that the account or group has full permissions over the object, including the right to delegate access to other accounts or groups. You should restrict this role to as few people as possible, especially at the organization level. You need Exchange Full Administrator permission to install the first Exchange server in an organization, and you need this permission to be able to remove a server that hosts SRS.

  • Exchange Administrator means that the account or group holds the permissions necessary to perform all of the administrative operations for the selected object. For example, it can mount or dismount stores, stop and start Exchange services, and so on. This role is best for people who perform day-to-day management of Exchange servers. To administer an Exchange server, your account must also be a member of the computer's local Administrators group. You also need Exchange Administrator permission to be able to install or remove an Exchange server in an administrative group or to install a service pack on a server.

  • Exchange View Administrator means that the group or object can examine all aspects of Exchange data for the object through ESM, but it cannot modify settings or add new data. This role is generally appropriate for people who need to monitor Exchange servers.

After selecting the object to delegate control to and the role to delegate, click on OK and then on Next to have the wizard execute the option.

If you examine the properties of the object after delegation and then click on the Security tab, you can see the effect of delegation in terms of the permissions that the user or group now holds. If you then click on the "Advanced" button, you can gain a better insight, because ESM then reveals the set of Exchange-related permissions that are most important in administrative terms. Figure 3.7 shows a selection of the permissions. As you can see, because we delegated the Exchange View Administrator role, the account does not hold many rights to work with Exchange data. Table 3.3 details the permissions held by each role. Note that even if you are an Exchange Full Administrator, you still do not have the right to access a user's mailbox and send email on his or her behalf; Exchange denies these rights explicitly by default. Of course, you can grant yourself these rights later on.

click to expand
Figure 3.7: Examining permissions after delegation.

Table 3.3: Exchange Administrative Permissions

Permission

Exchange View Administrator

Exchange Administrator

Exchange Full Administrator

Read properties

X

X

X

Write properties

-

X

X

List object

X

X

X

Add public folder to admin group

-

X

X

Create public folder

-

X

X

Create top-level public folder

-

X

X

Modify public folder admin ACL

-

X

X

Modify public folder deleted items retention period

-

X

X

Modify public folder expiration period

-

X

X

Modify public folder quotas

-

X

X

Modify public folder replica list

-

X

X

Open mail send queue

-

X

X

Read metabase properties

-

X

X

Remove public folder from admin group

-

X

X

Administer Store

-

X

X

Create named properties in Store

-

X

X

View Store status

-

X

X

Receive as

-

Deny

Deny

Send as

-

Deny

Deny

Change permission

-

-

X

Take ownership

-

-

X

Generally, the Administration Delegation wizard does a good job and you should not have to alter rights afterward. In fact, it is best practice never to change permission on an object unless you have a good reason, and you should document all changes, just in case. Note that there is currently no way to "undelegate" Exchange permissions using the wizard or other utility. If you need to remove administrative access for an account, you must manually edit the access control lists on the Exchange objects. This is one reason why it is best to delegate access to groups, because you can then simply remove the user account from the group. In addition, an account that holds the Full Exchange Administrator role is required to reinstall an Exchange 2000 server if this is necessary in a disaster recovery scenario.



 < Day Day Up > 



Microsoft Exchange Server 2003
Microsoft Exchange Server 2003 Administrators Pocket Consultant
ISBN: 0735619786
EAN: 2147483647
Year: 2003
Pages: 188

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net