Managing Configuration Information in Active Directory

 

When you add the Exchange System snap-in to a custom console, a Change Domain Controller dialog box appears. From this dialog box, you can select a domain controller from a domain in the forest of the Exchange Server 2003 organization, or you can accept the default configuration to connect to any writable domain controller. Access to Active Directory is required to get to the configuration information of an Exchange Server 2003 organization, which resides in the configuration directory partition, as explained in Exchange Server 2003 and Active Directory.

Note

You can manage an Exchange Server 2003 organization only from a computer that is a member of a domain that is trusted by the domain controllers in the forest containing the servers running Exchange Server 2003.

Binding to a Domain Controller

Exchange System Manager uses Active Directory Service Interfaces (ADSI) to communicate with Active Directory. ADSI relies on Lightweight Directory Access Protocol (LDAP). If you specify a specific domain controller in the Change Domain Controller dialog box, a direct LDAP connection to that domain controller is established when you open Exchange System Manager. Alternatively, if you accept the default configuration (no domain controller specified), ADSI performs a serverless bind to a domain controller.

Serverless binding is the process in which ADSI uses the locator service implemented by the Netlogon service to find the best domain controller to use. This domain controller is always located in the domain associated with the current security context of the user who connects to Active Directory. Each domain controller registers its host name in the Domain Name System (DNS) and its NetBIOS name using a transport-specific mechanism, for example, Windows Internet Name Service (WINS). The locator service locates the name, and then sends a datagram to the domain controller that registered the name. For NetBIOS domain names, the datagram is a mailslot message. A mailslot is a mechanism provided by the operating system for one-to-one or one-to-many interprocess communications (IPC). For DNS domain names, the datagram is an LDAP User Datagram Protocol (UDP) search. Each responding domain controller indicates that it is currently operational.

Note

NetBIOS is still required for Exchange Server 2003. Therefore, you must not decommission installed WINS servers in your network. For example, Exchange System Manager might select NetBIOS for remote procedure call (RPC)-based communication with an Exchange server, if defined in the RPC protocol binding order. The RPC protocol binding order is defined in a REG_STRING registry parameter named Rpc_Binding_Order, located under: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Exchange\Exchange Provider. The default value includes NetBIOS: ncalrpc,ncacn_ip_tcp,ncacn_spx,ncacn_np,netbios,ncacn_vns_spp. However, communication with domain controllers is based on LDAP and does not require NetBIOS or WINS.

As indicated in the following figure, the locator service prefers domain controllers in the local Active Directory site and connects to the first domain controller that responds. When the locator service sends a datagram to the domain controller, the domain controller looks up the Internet Protocol (IP) address of the client in the Configuration/Sites/Subnet container in Active Directory, to find a subnet object that corresponds to the client's IP address region. The siteObject property of the subnet object reveals the distinguished name of the site that contains the client, for example: CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=fabrikam,DC=com. The domain controller responds to the datagram with the distinguished name of the site that contains the client, together with an indicator of whether this domain controller covers that site. If the domain controller does not cover that site, and the locator service has not yet tried to find a domain controller in the client's site, the locator service tries again to find a domain controller in the local site. After a domain controller has been located, an LDAP connection to Active Directory is established, and the connection information is cached, so that subsequent connections from the same application do not require a repeat of the serverless bind algorithm. The bind cache contains connection handles to the appropriate servers, in addition to connection characteristics, such as encryption and authentication information.

Serverless binding to a domain controller

fc335feb-4f06-4c4c-91f0-7de47aea4518

Note

A serverless bind is the preferred connection method, because it balances requests from multiple clients between multiple domain controllers, and it is able to switch to another domain controller automatically when a domain controller becomes unavailable.

The Exchange Organization in the Configuration Directory Partition

Most of the configuration settings that you can manage using Exchange System Manager are stored in directory objects in the configuration directory partition in Active Directory. The hierarchy of configuration objects that appears in the console tree of Exchange System Manager closely matches the hierarchy of directory objects in the configuration directory partition. Only small differences exist. For example, in an organization with only one administrative group and one routing group, you can display the configuration objects in a hierarchy with or without administrative and routing groups. To do this, you select or clear the Display routing groups and Display administrative groups check boxes on the General tab in the properties of the Exchange organization object (that is, the root object in the console tree of Exchange System Manager). Nevertheless, administrative and routing group containers always exist in the configuration directory partition.

The following figure illustrates the hierarchy of directory objects from the configuration directory partition (displayed in Active Directory Sites and Services) compared to the hierarchy of configuration objects in Exchange System Manager (with administrative and routing groups enabled).

Hierarchies of directory and configuration objects

99bbd8ea-eeb3-4558-a862-f373d4c1631d

Exchange System Manager arranges the configuration objects from the configuration directory partition in the console tree, according to the following general categories:

  • Global Exchange objects   Global Exchange objects are objects that define Internet message formats and other settings that affect the whole Exchange organization. For example, the Mobile Services object defines settings for Exchange ActiveSync and Microsoft Office Outlook Mobile Access that apply to all recipients in the Exchange organization. The directory objects that correspond to these configuration objects reside in the Global Settings container, under the Exchange organization container in the configuration directory partition.

  • **Recipient objects   **Recipient objects define rules that determine the e-mail addresses that Recipient Update Service assigns to mailbox-enabled and mail-enabled recipient objects. Recipient objects also determine how server-based address lists are generated. Using the configuration objects in the Recipients container in Exchange System Manager, you can customize details and address templates to change the address book user interface in Outlook.

    The Recipients container in Exchange System Manager consolidates directory objects from a number of containers in the configuration directory partition. Address list definition objects and Recipient Update Service objects are in the Address Lists container, objects for details and address templates are in the Addressing container, and objects for policies that define e-mail addresses for mailbox-enabled and mail-enabled recipients are in the Recipient Policies container, under the Exchange organization object in Active Directory.

  • **Administrative and routing group objects   **Administrative and routing group objects do not provide access to any configuration parameters in Exchange System Manager. Instead, they are used to define the administrative topology and the message routing topology of an Exchange organization. For example, you use administrative groups to split the management of Exchange servers and resources. With routing groups, you can streamline message transfer between different sites and locations. For more information about administrative and routing group planning, see Planning an Exchange Server 2003 Messaging System.

  • Server objects   Server objects contain the settings that apply to individual Exchange servers in the messaging organization. Server objects also hold additional configuration objects for storage groups and messaging protocols. When displaying the properties of a server object, Exchange System Manager consolidates information from a variety of information sources on the various property tabs. Server configuration objects correspond to server directory objects in the configuration directory partition that resides in the Servers container, under an administrative group.

  • System policy objects   You can use system policy objects to simplify system administration by configuring parameters for multiple Exchange servers through a single configuration object, such as mailbox store, public folder store, or server settings. However, by default, system policy objects do not exist. To create a system policy, you first must add a specific System Policies container to your administrative group. To do this, right-click the administrative group, point to New, and then select System Policies Container. Then, to create either a Mailbox store policy, Public store policy, or Server policy, right-click the System Policies container and configure your policy. For more information about configuring the mailbox store, public folder store, or server properties, see the Exchange Server 2003 Administration Guide.

  • Folder hierarchies   Folder hierarchy objects can be found in the Folders container, under an administrative group. Each hierarchy object in this container refers to a particular public folder tree in the Exchange store. A public folder tree can be replicated across public stores on multiple Exchange servers. However, the hierarchy objects reside in the Folder Hierarchies container, under an administrative group in the configuration directory partition.

Note

The Tools node in Exchange System Manager does not correspond to a directory object in the configuration directory partition. The Tools node provides access to extension snap-ins, such as Message Tracking Center, which in turn might access objects in Active Directory to persist configuration information.

Exchange System Manager and Permission Settings

The permissions model of Exchange Server 2003 relies completely on the Microsoft Windows security model. The permissions model is structured on the Exchange organization object and administrative groups in the configuration directory partition. When you right-click the organization object or administrative group in the console tree of Exchange System Manager, you can select the Delegate control command to start Administration Delegation Wizard. Using Administration Delegation Wizard, you can assign to an Exchange administrator one of the three following roles:

  • Exchange Full Administrator   This role grants the administrator full control over the Exchange organization. However, the Receive As and Send As permissions are specifically denied. Therefore, an Exchange full administrator cannot impersonate another user in the Exchange organization. For example, an administrator who does not have Send As permission cannot send e-mail messages on behalf of another user.

  • Exchange Administrator   This role grants the administrator similar permissions to those of an Exchange full administrator but denies Modify Owner and Modify Permissions permissions. Therefore, an Exchange administrator can manage all settings of an Exchange organization, but cannot change the security settings.

  • Exchange View Only Administrator   This role grants the administrator permissions to Read All Properties, List Contents, Read Permissions, and View Information Store status. For example, Exchange View Only administrator permissions are required for mailbox administrators who must mailbox-enable or mail-enable user accounts, but who are not responsible for Exchange server management.

The following table lists the key differences among the various Exchange administrator roles.

Key differences between Exchange administrator roles

Administrator Role Modify Security Settings Manage Exchange Configuration Settings View Exchange Configuration Settings

Exchange Full Administrator

Yes

Yes

Yes

Exchange Administrator

No

Yes

Yes

Exchange View Only Administrator

No

No

Yes

Enabling the Security Tab for Objects in Exchange System Manager

Administration Delegation Wizard is used to grant roles to individual Exchange administrators or groups at the organization or administrative group level. However, Administration Delegation Wizard does not display all security settings and sometimes might even display an incomplete administrator list. This is because Administration Delegation Wizard tracks administrators to whom it grants Exchange administrator roles, in an attribute of the Exchange organization object in Active Directory. This attribute is named msExchAdmins. However, Administration Delegation Wizard does not track administrators with permissions inherited from higher-level containers in the configuration directory partition. For example, by default, Enterprise Administrators have full permissions across the entire configuration directory partition. This is because the full permissions setting is inherited from the root Configuration container to all child containers. However, Administration Delegation Wizard does not list these administrators as Exchange Full Administrators, because they are not listed in the msExchAdmins attribute. Permissions inheritance is explained in "Permissions Inheritance and Exchange System Manager" later in this topic.

Moreover, if you assign a security group the Exchange Full Administrator role at the organization level, later you cannot use Administration Delegation Wizard to downgrade members of that group to the Exchange View Only Administrator role for a specific administrative group. This is because Administration Delegation Wizard does not deny permissions granted through security settings inherited from parent containers. If you use Administration Delegation Wizard to assign individual members the Exchange View Only Administrator role for an administrative group, Administration Delegation Wizard lists these accounts as Exchange View Only Administrator accounts. However, these accounts retain their Exchange Full Administrator role, which is inherited through their group membership from the organization level. To examine actual security settings, you must enable the Security tab for the organization and administrative group objects in Exchange System Manager. To do this, set the ShowSecurityPage registry parameter, as shown in the following table.

The ShowSecurityPage registry parameter

HKEY_CURRENT_USER\Software\Microsoft\Exchange\ExAdmin

Value Name

ShowSecurityPage

Data Type

REG_DWORD

Value

1

Description

This setting affects only the user who is currently logged on. If the ShowSecurityPage value is not present or is set to 0, the Security tab appears on the following objects only:

  • Address lists

  • Global address lists

  • Mailbox stores

  • Public folder stores

  • Top level public folder hierarchies

If the ShowSecurityPage value is set to 1, the Security tab appears on all objects in Exchange System Manager. Changes occur immediately. You do not have to restart Exchange System Manager.

Warning

Incorrectly editing the registry can cause serious problems that may require you to reinstall your operating system. Problems resulting from editing the registry incorrectly may not be able to be resolved. Before editing the registry, back up any valuable data.

Permissions Inheritance and Exchange System Manager

If you examine the security settings for an Exchange organization, in Exchange System Manager on the Security tab, you notice that security settings are assigned to several system accounts and groups, in addition to those accounts that you specifically assigned an Exchange administrator role. The following table lists these default accounts and their permissions.

Default accounts with permissions in an Exchange organization

Account Permitted Denied

ANONYMOUS LOGON

  • Create Named Properties in the Information Store

  • Create Public Folder

  • Execute

  • List Contents

  • List Object

  • Read

  • Read Permissions

  • Read Properties

None

Authenticated users

  • Read Properties

  • List Object

None

Domain Admins (root domain)

  • Read

  • Write

  • Execute

  • Delete

  • Read Permissions

  • Change Permissions

  • Take Ownership

  • Create Children

  • List Contents

  • Add/remove Self

  • Read Properties

  • Write Properties

  • List Objects

  • Create Public Folder

  • Create Top Level Public Folder

  • Modify Public Folder Admin ACL

  • Modify Public Folder Replica List

  • Open Mail Send Queue

  • Read Metabase Properties

  • Administer Information Store

  • Create Named Properties in the Information Store

  • View Information Store Status

  • Receive As

  • Send As

  • Receive As

  • Send As

Enterprise Admins

  • Full Control

  • Receive As

  • Send As

Everyone

  • Create Named Properties in the Information Store

  • Create Public Folder

  • Execute

  • List Contents

  • List Objects

  • Read

  • Read Permissions

  • Read Properties

None

Exchange Domain Servers

  • Full Control

None

Most permissions settings are inherited by the Exchange organization object from parent containers in the hierarchy of the configuration directory partition. For example, Enterprise administrators are granted the Full Control permissions at the root container of the configuration directory partition. Because permissions are by default inherited by all child objects in the configuration directory partition, including the Exchange organization container, Enterprise Administrators are also Exchange Full Administrators.

You cannot use Exchange System Manager to examine security settings for parent containers in the configuration directory partition, but you can examine the actual settings using the ADSI Edit tool. Figure 4.4 shows the security settings for the Enterprise Admins group, as they are applied to the configuration container. The following figure also illustrates that these settings are applied to the configuration container and all child objects, including the Exchange organization.

Security settings for Enterprise Administrators as they appear in ADSI Edit

8a102c76-058e-416c-9a0d-9e15f46682ed

Permissions inheritance is a feature that facilitates the assignment of permissions in the configuration directory partition of Active Directory. For example, in Exchange System Manager, Administration Delegation Wizard relies on permissions inheritance to assign Exchange administrator roles to accounts and groups at the organization and administrative group level. When it assigns the Exchange Full Administrator role to an administrator account at the organization level, Administration Delegation Wizard grants the account Full Control permissions at the parent container, named Microsoft Exchange (Figure 4.4). Therefore, full control is applied to both the child container, named Active Directory Connections, and the Exchange organization. However, accounts assigned administrative permissions at the administrative group level are granted Read permissions at the organizational level also, so that these administrators can display the configuration information in Exchange System Manager. For more information about Administration Delegation Wizard and permission assignments in an Exchange organization, see the Exchange Server 2003 Security Hardening Guide.