Active Directory Connector Redux

The Active Directory Connector (ADC) has been around since Exchange 2000 Server first hit the streets. You use the ADC to synchronize the Exchange Server 5.5 Directory Service (DS) with Active Directory (AD) so that a mixed Exchange organization containing both Exchange 5.5 and Exchange 2000 or Exchange Server 2003 servers has one consistent Global Address List (GAL) and one consistent set of configuration information.

The ADC has undergone quiet refinement over the years. The version that we use today with Exchange 2003 is much more powerful than earlier versions. Microsoft has silently applied many bug fixes to the ADC and has significantly enhanced behind-the-scenes functionality—most notably in the new support for cross-site mailbox moves, introduced in Exchange 2003 Service Pack 1 (SP1). Let's take a look at a few ill-documented or barely publicized aspects of the ADC that nevertheless have significant importance for Exchange administrators.

ADC Account Creation and Migration
During synchronization of mailbox objects, the Exchange 2000 version of the ADC uses a set of object-matching rules to try to find an object in AD that's related to an in-process Exchange 5.5 object. These rules attempt to match first on globally unique identifiers (GUIDs), then distinguished names (DNs), and finally on SIDs. If the ADC can find no matching object in AD, it creates a new object (typically a user object) in AD. The new user object is created with a samAccountName attribute (also the User logon name) that matches the Exchange 5.5 mailbox alias, as Figure 1 shows.

Although this functionality works well for many organizations, problems arise when the ADC creates accounts before any legacy Windows NT 4.0-to-AD account migration takes place. In such cases, the ADC might create an AD account with a logon name of neiln (as you see in Figure 1), but if an administrator subsequently uses the Active Directory Migration Tool (ADMT) to migrate the corresponding NT 4.0 account to AD, a naming clash occurs. Many organizations have NT 4.0 logon names that are identical to Exchange mailbox aliases. If a clash occurs, ADMT typically appends (or prepends) a numeric value to the samAccountName of the new object it has created. Thus, the ADC might ultimately create two accounts, with logon names of neiln and neiln-1. The standard approach in this case is to use the AD Cleanup Tool to identify the matching objects and merge them, but unfortunately the AD Cleanup Tool merges the ADC-created object into the ADMT-created object. Therefore, either you end up with user logon names that are changed to values such as neiln-1, or you have to change the logon names.

Furthermore, some organizations cut corners and use the ADC-created object as a legitimate logon account. Doing so is disastrous because unlike an ADMT-created account, an ADC-created object doesn't have a sIDHistory attribute; therefore, access to security resources such as printers, network shares, and groups would be lost after the migration. Only when you use ADMT (or another third-party account-migration tool) to migrate NT 4.0 accounts can you make the full security context available.

Other problems specifically related to Public Folder access and mailbox delegation might arise if users enable and use ADC-created accounts as "real" accounts. When an Exchange user attempts to access an Exchange Public Folder, the Exchange Store process uses AD attributes associated with the mailbox to determine whether the user has the correct permissions to access the Public Folder information. Only the ADC can populate the msExchMasterAccountSID attribute with a value: Accounts created in AD either through Exchange System Manager (ESM) or through ADMT won't have a value for msExchMasterAccountSID. Therefore, when a user continues to log on to an old NT 4.0 account (completely separate from AD), his or her permissions and ability to access Pubic Folder content or access another user's mailbox are determined by the value in msExchMasterAccountSID—not the SID associated with the ADC-created account.

However, for AD accounts that ESM or ADMT creates, the Store uses the object's security context (through either the objectSID or the sIDHistory) to calculate access to a resource. The Store process knows which approach to use because it assumes that an enabled object (i.e., an object created by ESM or ADMT) can use its security context, whereas a disabled object (i.e., an object created by the ADC) must rely on the msExchMasterAccountSID. Therefore, if a user utilizes an ADC-created account for logon, the appropriate security context might not be in place.

Some third-party NT 4.0-to-AD migration tools deal more gracefully with the existence of an ADC-created object whose samAccountName matches the NT 4.0 logon name of the migrated account. These tools recognize that the matching values are related and merge them during the NT 4.0 account migration. Therefore, no duplicate objects exist in AD and there's no need to subsequently run the AD Cleanup Tool.

samAccountName-Mapping Changes
In a simplification effort, Microsoft modified the behavior of the ADC when Exchange 2003 shipped. In the Exchange 2003 version of the ADC, the samAccountName is randomized when the ADC creates an AD object for an Exchange 5.5 mailbox. Instead of creating an AD account with a logon name matching the Exchange 5.5 mailbox alias, the ADC creates the AD account's logon name (i.e., samAccountName attribute) with a value such as ADC_SNWNIEAEHAIGTRWNV.

The effect of this randomized samAccountName format is twofold. First, when ADMT migrates NT 4.0 accounts to AD, the chances of a name clash are small because the NT 4.0 logon name is unlikely to be the same as the samAccountName of the ADC-created object. Therefore, the ADMT-created account will have a logon name that's identical to the NT 4.0 account logon name, and when the AD Cleanup Tool merges the two accounts, the desirable logon name will be retained—that is, neiln rather than neiln-1. Second, the problem of using the ADC-created account as the primary logon account is effectively eliminated. The long-winded and difficult-to-remember nature of this randomized account logon name is enough to discourage even the most technical of users from using it as a logon name.

This new approach clearly has its advantages, but some third-party migration tools present problems. Some of these tools rely on the fact that the ADC-created object's samAccountName is identical to the logon value used for the NT 4.0 account and in fact match on this field during NT 4.0 account migration. With the new default behavior, the tools can no longer use this functionality. Although this updated functionality in the Exchange 2003 version of the ADC has been available for a while, many migration tools (e.g., Microsoft's ADMT) still suffer from this problem.

Although neither well documented nor well publicized, Microsoft provides a means with which to disable the samAccountName randomization feature in the Exchange 2003 version of the ADC. To disable randomization and reinstate the old behavior for a given ADC connection agreement (CA), you must set bit 15 of the msExchADCOptions attribute for the required CA. To do so, use a tool such as ADSI Edit and navigate through the AD hierarchy to the required CA, right-click the CA, select Properties, choose Both from the Select which properties to view dropdown box, and choose msExchADCOptions from the Select a property to view dropdown box. To set bit 15, add 32768 to the existing value (typically 4), then enter the new value in the Edit Attribute field, as Figure 2 shows.

After you set the attribute, any new objects that this CA creates in AD won't have randomized samAccountName attributes. Existing AD objects already created by the ADC will remain unchanged. You don't need to restart the ADC service for this change to take effect.

I'm not advocating that you disable samAccountName randomization, by any means. The new Exchange 2003 randomization behavior has many benefits, particularly when you're using the default Microsoft migration tools. However, some third-party approaches can benefit from the old behavior.

Also, note that even with the default Exchange 2003 ADC behavior, the samAccountName isn't always randomized. If you've identified the Exchange 5.5 mailbox as a resource mailbox (by setting the value NTDSNoMatch in Custom Attribute 10), the ADC-created account won't have a randomized samAccountName because the ADC assumes that you won't migrate a corresponding NT 4.0 account for it. And in cases in which the ADC matches the Exchange 5.5 mailbox with an account already created in AD, the ADC updates this account with the Exchange attributes. No new account is created—nor does the ADC modify the existing samAccountName in any way.

If the following conditions exist, the ADC will create a randomized samAccountName for a given Exchange 5.5 mailbox that it processes:

Exchange 2003 SP1 Enhancements for the ADC
One of the most welcome improvements in Exchange 2003 and the ADC is the ADC Tools Connection Agreement Wizard. This wizard analyzes your Exchange 5.5 environment and automatically creates appropriate CAs for your organization. This functionality is valuable, but it's also problematic because the wizard uses Microsoft's default values to create the CAs, and these values might not coincide with your particular requirements. Suppose you want to set specific values for whether the ADC actually deletes Exchange 5.5 object deletions or writes them to a file. Or suppose that, for a two-way CA, you want to first replicate from Windows instead of from Exchange 5.5.

If you're manually creating your CAs, you can use the ADC Manager GUI to set the aforementioned and similar attributes, but if you're using the wizard, you must use the default settings. Worse, if you use the wizard to create your CAs, they automatically start replicating as soon as they're configured because the Schedule property is set to Always. Microsoft has addressed these minor but troublesome problems in two new files—ca_defaults.xml and activate_cas.vbs—that install in the program filesmsadc directory when you install the Exchange 2003 SP1 version of the ADC.

The ca_defaults.xml file lets you set new default values for any CAs that the CA wizard creates. For example, if you want to prevent the CAs from replicating automatically as soon as they're created, you can modify the file's line

and set the value of activationStyle from 2 (Always) to 0.

You can control many other CA attributes by setting their respective values in this file before you run the wizard. For a list of the CA attributes that you can manipulate, take a look at the Microsoft article "Description of the changes to ADC Tools in Exchange Server 2003 Service Pack 1" (http://support.microsoft.com/?kbid=867627).

The activate_cas.vbs file has a particular purpose. If you set the activationStyle attribute to 0 so that CAs don't automatically start to replicate, you'll eventually need to enable them and thus set this attribute to a value other than 0. If you have a small number of CAs, you can perform this task manually, but if you have hundreds of CAs, the problem is more difficult. To this end, the activate_cas.vbs script simply sets the activationStyle attribute for all CAs to 2 (Always).

To run the script, ensure that you've changed directories to the program filesmsadc directory and execute the following command:

activate_cas NOW

Although there's more to the actual script, the few lines that specifically loop through the CAs and set the attribute are

while not caSet.EOFset ca = GetObject( caSet.fields("adsPath") )ca.put "activationStyle", 2ca.setInfocaSet.moveNextwend

Obviously, you could modify this script to set any number of attributes on the CAs and thus reconfigure multiple CAs in a bulk operation.

If you use these files, be aware that subsequent ADC updates or reinstallations will overwrite the existing versions of the files. Therefore, if you've customized the files in some way, you should save the modified versions before you apply the ADC updates, then replace the newly created files with your saved copies.

Necessary Evil
The new ADC functionality allows for smoother, incident-free migrations by using standard Microsoft tools such as ADMT and the AD Cleanup Tool. Clearly, however, there are circumstances in which the old behavior is desirable and might make your migration experience more pleasant. Also, some of the rough edges of CA deployment have been smoothed with the new customized configuration capabilities. The ADC remains a necessary evil, but at least it's a little easier to use.