| < Day Day Up > |
|
The persons who should be granted permissions for Exchange objects need to be clearly defined in any corporate messaging environment. Assignment of Exchange permissions and roles should be carefully considered, and periodic audits should be conducted to review the list of individuals who hold Exchange permissions.
Any reasonably sized Exchange network is not managed by a single person but rather by a group of people who have been granted the necessary privileges to modify the contents of the Microsoft Exchange directory and components. The purpose of this section is to explain how permissions work in the Microsoft Exchange Administrator program.
Having defined roles for corporate messaging architects, messaging system managers, directory services managers, messaging system backup operators, administrators, and the help desk makes it necessary to grant the appropriate access rights to implement these roles. Specific rights and permissions are required to perform each of these roles. The type and breadth of tasks that can be performed by the administrator can be tailored by varying both the permission types and the objects to which the permissions apply. Granting excessive rights creates problems by allowing too many people to have access to potentially destructive features. Appropriate and carefully controlled assignment of rights and permissions will allow management and administrative tasks to be carried out productively without jeopardizing system security.
Permissions for Exchange are based on the Windows permission model. The Active Directory is the primary data structure for Exchange, and ' managing Exchange' really means managing the containers and objects found in the Active Directory. Windows allows permissions to be granted at the object level.
You use the Exchange Administration Delegation wizard to set permissions for the Exchange organization or administrative group. Other objects within the Exchange organization inherit these permissions.
By default, when an Active Directory object is created, it inherits permissions from its parent object. Later, if you need to modify permissions on all objects within a container, you only need to change the permissions on parent objects. All child objects will automatically inherit the new permissions. The inheritance feature ensures that the permissions assigned to a parent object are consistently applied to all child objects. Inheritance eliminates the need to manually apply permissions to child objects.
Exchange extends the default inheritance model to provide system managers with even more control over the permissions on Exchange objects and containers. The inheritance model for Exchange objects can be customized to specify which containers or objects will receive the permissions. The administrator can elect to apply the permissions to the container being modified, the container and all of its subcontainers, or only to the subcontainers.
You can set specific permissions for certain Exchange objects, but other objects always inherit the permissions set by the Exchange Administration Delegation wizard and cannot be customized. The objects for which permissions can be customized are address lists, Exchange servers, mailbox stores, and public folder stores. The following standard permissions are available for each of these Exchange objects:
Full control
Read
Write
Execute
Delete
Read Permissions
Change Permissions
Take Ownership
Create children
Delete children
List contents
Add/remove self
Read properties
Write properties
Delete tree
List object
Exchange further extends the default permissions model by using Exchange-extended permissions. Additional permissions specific to Exchange objects are given in Table 2.1.
Permission | Description |
---|---|
Administer information store | Used to specify the users who are allowed to administer the Exchange Information Store. |
Create named properties in the information store | Used to specify the users who are allowed to create named properties in the Exchange Information Store. A named property is a store attribute that can be accessed by name, such as display names. |
Create public folder | Used to specify the users who are allowed to create public folders under this folder. The Information Store service enforces this permission. |
Create top-level public folder | Used to specify the users who are allowed to add top-level public folders. The Information Store service enforces this permission. |
Modify public folder ACL | Used to specify the users who are allowed to modify the public folder access control list (ACL). |
Modify public folder admin ACL | Used to specify the users who are allowed to modify the administrative ACL for a public folder. |
Modify public folder deleted item retention | Used to specify the users who are allowed to modify the length of time that items deleted from the public folder are retained. The Information Store service enforces this permission. |
Modify public folder expiry | Used to specify the users who are allowed to modify the expiration date for items in the public folder. The Information Store service enforces this permission. |
Modify public folder quotas | Used to specify the users who are allowed to modify the quotas on a public folder. The Information Store service enforces this permission. |
Modify public folder replica list | Used to specify the users who are allowed to modify the public folder replica list. An administrator must be given this permission on the administrative group to which this public folder points and the public database to which the replica should be added. The Information Store service enforces this permission. |
Open Address List | Used to specify the users who can access the address list. |
Open mail send queue | Used to specify the users who are allowed to open the mail send queue, which is used for queuing messages being sent to or received from the Information Store. Generally, this permission is only granted to the Domain EXServers account. |
Read metabase properties | Used to specify the users who are allowed to read the Internet Information Services (IIS) metabase. The IIS metabase is the database that stores IIS configuration values. |
View information store status | Used to specify the users who are allowed to view Information Store information, such as logons and resources. |
You can use the Exchange System Manager (ESM) console to assign or remove permissions to an Exchange object or to modify existing permissions. Although permissions can be granted to both users and groups, it is best to restrict granting permissions directly to specific users. Instead, permissions should be assigned to Windows 2003 groups that contain the appropriate users. Assigning permissions to groups rather than an individual user reduces the future workload when people leave, arrive, or change roles.
Permissions are modified or granted using the following procedure:
Start ESM from the Windows Start menu by selecting All Programs →Microsoft Exchange →System Manager.
Right-click on the address list, server, mailbox store, or public folder store object to which you want to assign permissions and select Properties.
Select the Security tab to display the security properties (Figure 2.9).
Figure 2.9: Security properties tab
In the Name window, select the user or group to which you want to assign permissions. If the user or group does not appear in the list, select Add to add users to the list.
The user's current permissions are indicated in the Permissions window. The permissions currently granted to this user have the Allow check box marked. Permissions that are denied to this user have the Deny check box marked. If the permissions for this object are inherited from parent objects, the check box is shaded. Inherited permissions can only be changed at the parent object where the permission is defined. One of the following three steps can be used to change permissions:
If the permission is not inherited from a parent object, select or clear the Allow or Deny check boxes for the permissions you want to grant or deny this user or group.
If the permission is inherited, change the permission at the parent object where it is defined.
Clear the check box for Allow inheritable permissions from parent to propagate to this object. This will allow you to change the permissions, but the object will no longer inherit permissions from parent objects.
Select OK when all permission changes have been completed.
Exchange further extends the default permissions model with the Exchange Administration Delegation wizard. This tool greatly simplifies permission assignment by using Exchange administrator roles. A role is simply a collection of rights and privileges that defines a user or administrator's access to objects held within an Active Directory container.
In Exchange 5.5, when a user was assigned a role for a particular container, the user had the same permissions for all objects within that container. In Exchange 2000 and Exchange 2003, a system manager can specify user access by object class. For example, the administrator might grant a user access to Exchange servers without giving the user access to any other Exchange settings.
Typically, permissions are granted in the ESM console at either the Exchange organizational level or at an administrative group level. The objects that can be managed are determined by where you start the Exchange Administration Delegation wizard. If you select the Exchange organization before starting the wizard, the administrative permissions will be granted to all Exchange objects in the organization. Similarly, if you start the wizard after selecting an administrative group, then the scope of the permissions is limited to the objects in the selected administrative group. To limit administrative access to specific objects within an administrative group, use the wizard to set permissions for the entire administrative group and then reconfigure the permissions at the object level.
Exchange provides the following set of predefined roles:
Exchange Full Administrator. The Exchange Full Administrator role is designed for those administrators who need full control over the entire Exchange organization. Users who are assigned this role can fully administer all Exchange system information and can modify permissions. In addition to the permissions granted by the Exchange Administration Delegation Wizard, you must also manually make the Exchange Full Administrator a local system administrator for each Exchange server to be managed. Local system administrators can start and stop services and access the registry, the metabase, and the file system for administrative operations. Users who will be remotely managing an Exchange server must have administrative permissions on both the local system and the remote server.
Exchange Administrator. All permissions needed to manage mailboxes or perform normal day-to-day management are included in the Exchange Administrator role. If you use the predefined roles, the Exchange Administrator role would typically be assigned to administrators and system managers. It includes all of the permissions available with the Exchange Full Administrator role except for the ability to modify permissions. You must also manually make the Exchange Administrator a local system administrator for each Exchange server to be managed.
Exchange View Only Administrator. This role provides view-only access to the selected objects. It can be used in conjunction with other permissions to allow administrators to view organization information for administrative groups that they are not administering. In addition to the permissions granted by the Exchange Administration Delegation wizard, you must manually give an Exchange View Only Administrator permission to log on to the Exchange server locally.
Table 2.2 outlines the permissions for accessing the specified objects that are granted when you launch the Exchange Administration Delegation wizard from the Exchange organizational level.
Role | Description |
---|---|
Exchange Full Administrator | All permissions except Send as and Receive as for all Exchange objects in the organization container and subcontainers. |
Exchange Administrator | All permissions except Change permissions, Send as, and Receive as for all Exchange objects in the organization container and subcontainers. |
Exchange View Only Administrator | Only Read, List object, List contents, and View information store status for all Exchange objects in the organization container and subcontainers. |
Table 2.3 outlines the permissions for accessing the specified objects that are granted when the Exchange Administration Delegation wizard is started at the administrative group level. Permissions and other settings defined at the administrative group level are automatically copied to all objects placed in the administrative group.
Role | Permissions for Administrative Group Objects | Permissions for Objects in Organization Container |
---|---|---|
Exchange Full Administrator | All permissions except Send as and Receive as for objects in the administrative group and subcontainers. | Only Read, List object, and List contents permissions for objects in the organization container and outside of the administrative group container. |
Exchange Administrator | All permissions except Change permissions, Send as, and Receive as for objects in the administrative group and subcontainers. | Only Read, List object, and List contents permissions for objects in the organization container and outside of the administrative group container. |
Exchange View Only Administrator | Only Read, List object, List contents, and View information store status permissions for objects in the administrative group and subcontainers. | Only Read, List object, and List contents permissions for objects in the organization container and outside of the administrative group container. |
Note | By default, administrative groups and routing groups are not displayed. If you have not already enabled these, right-click on the Exchange organization and select Properties to display the organizational properties. Select the Display administrative groups check box to allow the administrative groups to be displayed, and select the Display routing groups check box to display the routing groups. You must restart the ESM after enabling display of administrative groups and routing groups. |
The Exchange Administration Delegation wizard can be used to assign roles using the following procedure:
Start ESM from the Windows Start menu by selecting All Programs →Microsoft Exchange →System Manager.
Right-click on either the Exchange organization object or an administrative group object and select Delegate Control to start the wizard.
The wizard displays an introductory screen. Select Next to continue.
The Users or Groups window (Figure 2.10) displays the users and groups who currently have assigned roles for the Exchange organization or selected administrative group. To remove an assigned role, select the user or group and then select Remove. To add a new user or group, select Add to display the Delegate Control window (Figure 2.11).
Figure 2.10: Exchange Administration Delegation wizard
Figure 2.11: Delegate Control window
Use the Browse button to find the user or group to which you want to assign a role.
Use the drop-down list to select the role for this user and then select OK to return to the Users or Groups window.
When you have completed all changes, select Next to display the summary screen.
When you have finished reviewing the summary of changes, select Finish to implement the new roles.
| < Day Day Up > |
|