Get Inside Active Directory Connector Synchronization

The Active Directory Connector (ADC) has existed since Microsoft Exchange 2000 Server's debut. The ADC's function is to synchronize information from the Exchange Server 5.5 Directory Service (DS) to Active Directory (AD) so that a mixed-mode Exchange organization containing Exchange 5.5 and Exchange Server 2003 or Exchange 2000 servers has one consistent view of user and configuration information.

Although the ADC has undergone many improvements since its inception (most notably Exchange 2003 Service Pack 1's—SP1's—support for cross-site mailbox moves), the ADC's core functionality remains the same. But not all the mechanisms that underlie that functionality are well understood. Studying these mechanisms will help you properly implement an ADC-based synchronization environment. In a subsequent article, I'll describe how to fine-tune the ADC.

Synchronizing Hidden Objects
You can hide objects in the Exchange 5.5 DS from the Global Address List (GAL). Hidden objects, which can include mailboxes, custom recipients, and distribution lists (DLs), have a Hide-From-Address-Book attribute value of 1. By default, Exchange Administrator doesn't display hidden objects in recipient containers. To see hidden objects, you must select Hidden Recipients from Exchange Administrator's View menu.

The ADC will synchronize hidden objects to AD, but unlike Exchange Administrator, the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in makes hidden objects visible by default. You can also see hidden objects from Exchange System Manager (ESM) when you browse an organizational unit (OU). However, end users can't see hidden objects in the GAL. To determine whether objects are hidden from client view, start the Active Directory Users and Computers snap-in, select Advanced Features from the View menu, click the Exchange Advanced tab, and see whether the Hide from Exchange address book check box is selected. Exchange 2003 users can't see AD objects (e.g., users, contacts, groups) for which this option is selected.

When the ADC synchronizes an Exchange 5.5 object that's hidden from the address book, the ADC sets that object's msExchHideFromAddressLists attribute to TRUE. Similarly, when the ADC synchronizes a hidden object from AD to the Exchange 5.5 DS, it hides the object from the Exchange 5.5 GAL, so the object isn't visible by default in Exchange Administrator. As you can see, hidden-object functionality isn't symmetrical between Exchange 5.5 and Exchange 2000 and later. A hidden object in Exchange 5.5 is hidden from the GAL and Exchange Administrator, whereas hidden objects in Exchange 2003 or Exchange 2000 are hidden from the GAL but are visible in ESM and the Active Directory Users and Computers snap-in. Understanding how the ADC deals with hidden objects helps you plan and implement a synchronization environment.

Processing Hidden DL Membership
In Exchange 5.5, you can control whether clients can view a DL's membership information. Start Exchange Administrator, click a DL, select Properties from the File menu, click the Advanced tab, and select the Hide membership from address book check box.

When the ADC synchronizes a DL from the Exchange 5.5 DS, the ADC reads the DS's Hide-DL-Membership attribute and sets the AD hide-DLMembership attribute on the synchronized object accordingly. When the DL's membership is hidden, this action effectively applies a set of access control entries (ACEs) to the corresponding Universal Distribution Group (UDG) in AD to deny access to view the membership. Although the ACEs prevent Exchange 2003 clients (e.g., Microsoft Office Outlook 2003) from enumerating the UDG membership, some security principals need access to the membership list. For example, Exchange 2003 needs to enumerate the membership to send mail to UDG members.

To facilitate this type of Exchange operation, as the ADC synchronizes a DL with hidden membership, the ADC reads the msExchServerGlobalGroups attribute from AD's Organization container entry. This attribute contains the list of Exchange 2003 servers in the organization that need access to the membership. The Exchange Enterprise Servers and Exchange Domain Servers security groups define this list of servers. (The DomainPrep utility creates these security groups.) The servers listed in the msExchServerGlobalGroups attribute can view the UDG membership, although the UDG is hidden from users in the GAL. By default, Exchange 2003 servers belong to the Exchange Enterprise Servers and Exchange Domain Servers security groups.

If you add to your Exchange organization a Windows Server 2003 domain that includes Exchange 2003 servers, the Recipient Update Service (RUS) will detect the change and update all UDGs that have hide-DLMembership set to TRUE with the new Exchange Domain Servers group's security principals so that the new Exchange 2003 server can access the hidden membership. Likewise, if you make other changes to the hide-DLMembership attribute on the synchronized object in AD, the RUS will detect your changes and update the ACE as necessary.

In reverse synchronization (i.e., from AD to the Exchange 5.5 DS), the ADC checks the AD object's hide-DLMembership attribute value and sets the corresponding Hide-DLMembership attribute on the new Exchange 5.5 DL. You can use the Active Directory Users and Computers snap-in to control whether UDG membership is visible. Start the snapin, right-click the UDG, select Exchange Tasks, and select Hide Membership. Understanding how the ADC handles hidden DLs lets you build a correctly functioning synchronization environment.

Dealing with Latency During Synchronization
Mistaking ADC synchronization latency for a failure in ADC functionality is a common error. Sometimes the ADC synchronizes Exchange 5.5 DLs to AD before synchronizing the discrete objects that constitute the DLs' membership. For example, you might be using one connection agreement (CA) to synchronize a new DL, and this synchronization might be scheduled to run before another CA that synchronizes mailbox objects in the DL. If the DL has membership objects that reference as-yet-uncreated AD objects, AD's referential integrity feature prevents the UDG from populating the membership for those phantom objects.

In this case, if no other precautions are in place, when the CA that controls the reverse synchronization runs, the partial AD UDG might alter the original Exchange 5.5 DL membership. AD's unmergedAtts attribute prevents this problem in the ADC and in AD. During the initial synchronization, if the ADC can't add objects to the UDG because the corresponding membership objects don't yet exist in AD, the ADC adds these objects to the unmergedAtts attribute. The ADC uses the unmergedAtts attribute on the subsequent reverse synchronization to ensure that no membership information is lost.

The Exchange 5.5 DS has no referential integrity mechanism. Therefore, when the ADC synchronizes a UDG object from AD to the Exchange 5.5 DS as a DL, the Members attribute is fully populated with all members, even if the member object doesn't yet exist in the Exchange 5.5 DS. Thus, Exchange 5.5 DLs don't have or need the unmergedAtts attribute.

Deleting Objects During Synchronization
The ADC has several methods for dealing with deleted objects during synchronization. You need to understand how these mechanisms work to ensure that you use the correct approach in implementing your ADC infrastructure. When you create a CA, you can tell the ADC whether or not to delete objects from the Exchange 5.5 DS and AD. Deletion settings apply in both directions. So, when you set the CA to delete objects then synchronize, the objects you've deleted from the Exchange 5.5 DS are automatically deleted in AD, and the objects you've deleted from AD are automatically deleted from the Exchange 5.5 DS during reverse synchronization.

If you choose not to delete objects during synchronization—perhaps because you want to review the deletions first—the ADC writes non-replicated deletions to a temporary file on the ADC server. Source object deletions that occur in the Exchange 5.5 DS write to a file named Win2000.ldf; deletions that occur in AD write to a file named Ex55.csv. By default, these files are located in ADCpathMSADCCAname.

To change the default location, edit the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSADCParameters registry subkey. Add an entry named Transaction Directory, set the value type to STRING, and set the value data to the full directory path (e.g., C:ADCLogs). This registry entry creates a parent directory for the deletion logs. Each CA creates its own subdirectory under the parent directory and writes a file named MSADC.inf to the subdirectory. The MSADC.inf file contains the name and globally unique identifier (GUID) of the CA associated with the subdirectory. After you review the proposed replicated deletions, you can use the Ldifde tool to apply the .ldf files to AD and the Admin /I tool to apply the .csv files to the Exchange 5.5 DS.

CAs and Authentication
For a CA to read or write object information from the Exchange 5.5 DS or AD, the CA must make an authenticated connection to both directory services over LDAP. To specify the credentials to use for the connection, right-click the CA within the ADC Manager snap-in, select Properties, then click the Connections tab and enter the credentials, as Figure 1 shows.

The accounts you use to access directory services must have the appropriate read or write access to the Exchange 5.5 DS containers or AD OUs that you specify. Using an Administrator account isn't advisable because this account is used for various purposes and often has restrictions that prevent you from easily determining the cause of any problems that arise. In addition, using the Administrator account violates the principle of least privileges—that account has more privileges than are necessary for accessing directory services. For authentication tasks, you need to use a dedicated account such as the Exchange Site Services Account when connecting to the Exchange 5.5 DS, or an account such as ADCService for Exchange 2003 account when working with the ADC.

The ADC stores the credentials for the accounts it uses to access AD and the Exchange 5.5 DS in the Local Security Authority (LSA) Global Secrets location. The LSA is a protected OS subsystem, represented in Windows Task Manager by the lsass.exe process, which runs in user mode. The LSA stores several types of secrets (e.g., local, global, machine). Local secrets are readable only on the machine that stores them, global secrets replicate between domain controllers (DCs), and only the OS can access machine secrets. All types of LSA secrets are stored in the registry's HKEY_LOCAL_MACHINESecurity container and are encrypted with a system-specific encryption key.

When you create a new CA, the ADC management program GUI initiates a remote procedure call (RPC) request to the ADC service and requests storage for the credentials on the local ADC server. Only the ADC service can read the password that's associated with the credentials stored in the LSA—the ADC management program GUI can't read the password. Therefore, you must reenter the password if you rehome the CA or change the source or target container. If you use the same set of credentials for multiple CAs, the LSA conserves space by storing only one set of credentials. This approach also saves time if you need to change the password associated with an account the CA is using. Changing the password on one CA changes the password for all other CAs that use the same credentials.

Certain permissions are necessary to be able to write the credentials of the LSA Global Secrets location. When you set credentials, the ADC management program GUI checks that you have write access to the AD object DC=domain name, CN=Configuration, CN=Sites, CN=Default-First-Site-Name, CN=Servers, CN=server name, CN=Exchange Settings, CN=Active Directory Connector server name, where domain name is the name of the Windows domain and server name is the name of the computer hosting the ADC. If a user has write access to this AD object, the ADC by default allows the user to set the CA credentials. You can set explicit access controls on this object to refine which users have access.

When you use the ADC management program GUI to modify credentials, a timestamp for that LSA entry updates with the current time. Also, when the ADC reads the password during synchronization and the timestamp is older than 7 days, the timestamp updates with the current time. The LSA has limited space; a Windows 2003 system can store only 4096 LSA secrets. In addition, an ADC server allocates only 64KB for the ADC service. When space runs out, Windows removes the oldest unused credentials. Similarly, credentials stored in the LSA expire when the credentials' timestamp is older than the current expiration limit in force. The expiration limit depends on the number of credentials stored, as Table 1 shows.

When you create a CA and set the replication schedule to Never, then 181 days later force replication, the replication attempt will fail (assuming that the size of the LSA hasn't already been exhausted, in which case the minimum number of days might be less than 181). To control the minimum number of days that credentials can remain in the LSA, edit the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSADCParameters registry entry. Set the value name to Password Expiration, the value type to REG_DWORD, and the value data to the minimum number of days you want credentials to remain in the LSA. Although the number of passwords stored in the LSA cache determines the expiration settings, credentials might expire earlier than the expiration settings if you exhaust the cache space. If you set a CA's replication schedule to Always or Selected times, the schedule will never expire because the timestamp will update every time the CA synchronizes.

Be Prepared
The ADC and other components such as the RUS perform numerous operations to ensure smooth cooperation between various directory services. Many administrators take the ADC's basic functionality for granted. However, if you want to fully understand your mixed-mode Exchange environment, you need to know how all the components work.

The ADC uses several detailed mechanisms whose operations subtly affect synchronization. You must fully understand these subtle effects to prevent unexpected behaviors in your environment.