XADM: Addressing Problems That Are Created When You Enable ADC-Generated Accounts

This article provides information about disabled accounts that the Active Directory Connector (ADC) creates and describes how to enable those disabled accounts.

General Information About ADC-Created Disabled Accounts

In general, you should not enable the disabled accounts that the Exchange 2000 ADC creates, and then use those accounts to log on. The ADC creates these accounts only to serve as placeholders, to represent mailboxes that are replicated from the Microsoft Exchange Server 5.5 directory. The ADC creates a disabled user in Active Directory for several reasons:

• The ADC cannot find a user account in Active Directory that is associated with the Exchange Server 5.5 mailbox.
  
  The ADC uses a set of object-matching rules to find the appropriate user in Active Directory to match with the Exchange Server 5.5 mailbox. The ADC tries to find a user object that has an objectSID or sIDHistory attribute that matches the "Primary Microsoft Windows NT Account" (also called the Assoc-NT-Account attribute) of the Exchange Server 5.5 mailbox.
  
  If the ADC cannot find a user in Active Directory with an objectSID or sIDHistory attribute that matches the Assoc-NT-Account attribute of the mailbox, the ADC creates a new disabled user in Active Directory. The ADC then sets the msExchMasterAccountSID attribute on the disabled user to match the Assoc-NT-Account attribute of the Exchange Server 5.5 mailbox.
  
  This ensures that the user account, presumably a Microsoft Windows NT 4.0 account, still has appropriate access to the mailbox if the mailbox is moved to an Exchange 2000 server.
• The mailbox in Exchange Server 5.5 is marked as a resource mailbox.
  
  To mark a mailbox as a resource mailbox, set Custom Attribute 10 to "NTDSNoMatch" on the mailbox in the Exchange Server 5.5 directory. This setting directs the ADC not to try to match a user by using the objectSID or sIDHistory attribute. Instead, the ADC creates a disabled user, and then sets the msExchMasterAccountSid attribute to SELF. This setting ensures that the resource account is accessible to other users who have permissions to the account.
• The user account in Active Directory that the ADC tried to match the mailbox with already has mail attributes. The legacyExchangeDN attribute of the user also does not match the Exchange Server 5.5 distinguished name of the mailbox that matched to the user.
  
  This issue may occur if you have multiple mailboxes associated with the same Windows NT account, or if some mail attributes were manually populated to the users in Active Directory. In this case, the ADC creates a new disabled user. If the Assoc-NT-Account attribute of the mailbox is already set as the msExchMasterAccountSID attribute on another user account in the forest, the ADC does not populate the msExchMasterAccountSID attribute of this user because the msExchMasterAccountSID attribute must be a unique value in the forest.

The ADC creates these disabled users for the following reasons:

• To make sure that all of the mailboxes in the Exchange Server 5.5 directory are represented in Active Directory, along with all of the mail attributes that are associated with the mailboxes. This ensures that the Exchange 2000 Global Address List is complete, even if the Windows NT migration to move all of the user accounts from Windows NT 4.0 to Active Directory is not 100 percent complete.
• To allow an administrator to move a user's mailbox from an Exchange Server 5.5 computer to an Exchange 2000 server, even if the user's logon account is not migrated to Active Directory yet and is still in a Windows NT 4.0 domain.

If you enable these disabled accounts, and then users use these accounts (without additional modification) to log on, issues will occur with public folders and delegation in Exchange.

The Exchange information store uses several Active Directory attributes to calculate permissions when you try to gain access to public folders and delegate mailboxes. Exchange 2000 information store access control lists (ACLs) are based on Security Identifiers (SID). This differs from Exchange Server 5.5, which uses Exchange Server 5.5 distinguished names for ACLs. Because of this difference, the information store must sometimes do conversions from a distinguished name to a SID and from a SID to a distinguished name. The Microsoft Outlook permissions dialog boxes also expect to use ACLs that are based on the distinguished name. The Active Directory attributes that the information store uses to calculate permissions are:

• msExchUserAccountControl
• objectSid
• msExchMasterAccountSid
• sIDHistory

The information store expects that disabled accounts will have a msExchMasterAccountSID attribute and that enabled user accounts will not have a msExchMasterAccountSID attribute.

If disabled accounts do not have the msExchMasterAccountSID attribute set, you may receive the following event message in the Application log: For additional information about how to properly set the msExchMasterAccountSID attribute to resolve these event messages in the Application log, click the article number below to view the article in the Microsoft Knowledge Base: Disabled account permissions are calculated by using the msExchMasterAccountSID value, instead of the actual SID value of the placeholder account. This is so that the user can continue to log on to the preexisting Windows NT 4.0 domain security context and still be granted rights to the user's Exchange 2000 objects.

Accounts that are created in Active Directory do not have the msExchMasterAccountSid attribute. Such accounts rely on their own security context (objectSID or sIDHistory) to be granted permissions in Exchange 2000 information store ACLs.

After a disabled account that the ADC created is enabled in Active Directory, two conflicting security contexts suddenly exist that may be examined in various circumstances. For example, when you open the permissions dialog box for a public folder, the information store must convert the SID-based ACL that is held on the folder to a distinguished name-based ACL for Outlook to use. If a user who was granted permissions on that folder is matched on the msExchMasterAccountSID attribute, but the account is an enabled account, the information store cannot properly resolve the SID in the ACL to a legacyExchangeDN attribute. Instead of displaying the proper user's name, the information store displays "NT User:Domain\User".

NOTE: If you want to use the Active Directory Migration Tool to import the SidHistory values, you may also want to modify the account samAccountName values on the ADC-created accounts before you start these steps. This ensures that when you run the Active Directory Migration Tool, the samAccountName values of the existing disabled users do not conflict with the newly migrated accounts.

Enabling and Removing ADC-Created Disabled Accounts

Microsoft does not recommend that you enable the disabled accounts that are generated by the ADC. However, if there is a critical business requirement that requires you to enable them, follow these instructions to enable and to use the ADC-created disabled accounts:

1. Use a Windows NT migration tool to merge the SID of the Windows NT 4.0 account into the Active Directory account as the sIDHistory value to preserve the permissions.
2. Enable the account.
3. Remove the msExchMasterAccountSID attribute.

Removing the "msExchMasterAccountSID" Attribute

You can remove the msExchMasterAccountSID attribute two different ways:

• Use the Active Directory Users and Computers Microsoft Management Console (MMC) snap-in:
  1. Start the Active Directory Users and Computers MMC snap-in.
  2. Click View, and then make sure that the Advanced Features check box is selected.
  3. Right-click the ADC-created user account that you enabled, and then click Properties.
  4. Click the Exchange Advanced tab, and then click Mailbox Rights.
  5. Under Name, view each entry. Find the account that has the Allow check box selected for Associated external account, and then click to clear the Allow check box.
• Use the Collaboration Data Objects for Exchange Management (CDOEXM) interface to modify the mailbox security descriptor.
  
  Beginning with Exchange 2000 Server Service Pack 2 (SP2), a new interface is exposed in CDOEXM. This interface is named MailboxRights. This exposure permits you to modify the mailbox security descriptor programmatically. You can use this interface to remove the "Associated External Account" right from a mailbox. Specifically, the right you have to look for and remove is:
  PRIMARY-USER 0x00000004
  For more information, click the following article number to view the article in the Microsoft Knowledge Base:
  302926  (http://support.microsoft.com/kb/302926/ ) You cannot programmatically change mailbox rights

NOTE: A fix for the Active Directory Cleanup Wizard (Adclean) is included in Exchange 2000 SP2 to resolve a problem with the way that the Active Directory Cleanup Wizard handles the msExchMasterAccountSid attribute. For more information about finding msExchMasterAccountSID on and removing msExchMasterAccountSID from multiple accounts, click the following article number to view the article in the Microsoft Knowledge Base: