| Concepts and Planning | << | >> |
|---|
Not only is the directory important to users and administrators, it is also crucial to Microsoft Exchange Server processes and third-party programs.
Users Access directory information through the Address Book. Users can also access directory information through LDAP.
Administrators Use the Administrator program to create, modify, or delete directory objects and to import or export directory objects.
Microsoft Exchange Server processes Access the directory to obtain information needed for certain tasks. For example, the system attendant uses connector configuration information to build the routing table.
Third-party programs Access the directory in a variety of ways, such as by manipulating the directory objects and by synchronizing the Microsoft Exchange Server directory with other directories.
You can control access to directory objects. Each object has an access control list, which is a list of Windows NT user accounts and groups associated with the object. This list is used to determine whether a user or process has been granted access to an object.
A set of permissions is associated with each account on the access control list. Permissions define the type of access that an account has been granted. These include, for example, whether the account has been given the right to modify the object.
These sets of permissions are presented in the Administrator program as roles. For example, typical users are granted the role of User on their mailboxes.
Microsoft Exchange Server also enables you to grant anonymous access so that users can access directory objects without having a mailbox or being a custom recipient in that organization. An anonymous user can log on to a Microsoft Exchange Server computer but is restricted to viewing and accessing directory objects that have been granted anonymous permissions. You can specify which directory objects and address lists to publish to anonymous users by using the Administrator program or Outlook.
When you configure permissions on a directory object, you select a Windows NT user account and specify the type of access it has. For example, if you grant Maria Black's user account Admin permissions on the site object, Maria Black can administer all the recipients in the site.
If you find that none of the predefined roles are appropriate, you can specify a custom set of permissions.
It isn't necessary to set permissions individually for every object in the directory. In general, objects inherit permissions from those defined for their containers. This means that permissions can be set once across different levels of the organization and can be inherited by many other objects. Permissions are inherited as follows:
The organization object Windows NT user accounts with permissions on the organization object can change the display name of the organization. Permissions on this object are not inherited by any other object.
Site objects Windows NT user accounts with permissions on the site object can modify the site object and all the recipients in a site. The Recipients container and all its objects inherit permissions from the site object. An administrator who adds users to the system could be granted Admin permissions on the site.
Configuration objects Windows NT user accounts with permissions on the configuration object can configure routing, replication connection, and other processes. The following illustration shows the permission inheritance on the configuration objects: