Public Folder Access Control in Mixed Mode

Public folder access control is complex in mixed mode because of the following differences between Exchange Server 2003 and Exchange Server 5.5:

• Where an ACL on a public folder in Exchange Server 5.5 contains a distribution list, the ACL on a replica of the folder in Exchange Server 2003 must contain an Active Directory security group. The conversions of the Exchange Server 5.5 distribution list to an Active Directory distribution group, and then to an Active Directory security group are automatic if your topology is configured correctly. For more information about group conversion, see "Types of Groups Used in Access Control Lists" later in this topic.

• Exchange Server 2003 and Exchange Server 5.5 use different attributes to identify users in access control lists:

  • Normally in Exchange Server 5.5, each user has a Windows NT Server 4.0 account (identified by its Windows NT Server 4.0 SID attribute) and an Exchange Server 5.5 mailbox (identified by distinguished name in the Exchange Server 5.5 directory). In access control lists, users (and groups) are identified by distinguished name.

  • In Exchange Server 2003, each user has an Active Directory account (identified by SID attribute) that includes mailbox-related attributes. These attributes link the user to the appropriate mail content in the Exchange store. In access control lists, users (and groups) are identified by the security identifier (SID).

    For more information about how Exchange Server 2003 tracks mixed-mode users, see "User Attributes Used in Access Control Lists" and "Avoiding Problems Caused by Unknown Users in Access Control Lists" later in this topic.

• Exchange Server 2003 and Exchange Server 5.5 use different formats to store permissions information. "User Attributes Used in Access Control Lists" later in this topic describes the basics of the conversion and when it occurs. For an in-depth examination of permissions formats and the conversion process, see Working with Store Permissions in Microsoft Exchange 2000 and 2003.

Types of Groups Used in Access Control Lists

Exchange Server 5.5 uses distribution lists for both message delivery and access control, whereas Exchange Server 2003 uses them only for message delivery. Exchange Server 2003 uses Active Directory security groups for access control. ADC replicates Exchange Server 5.5 distribution lists to Active Directory universal distribution groups (UDGs). When Exchange Server 2003 processes a public folder ACL and encounters a UDG, it immediately tries to upgrade the UDG to a universal security group. The universal security group then replaces the UDG in the ACL.

Exchange cannot convert a UDG to a universal security group under the following circumstances:

• The UDG resides in a mixed-mode Windows Server 2003 or Windows 2000 domain.

• A universal security group was converted manually to a UDG.

• The membership of the UDG has not been replicated to Active Directory.

User Attributes Used in Access Control Lists

This section concentrates on how Exchange identifies users for access control purposes, and how that information passes between Exchange Server 2003 and Exchange Server 5.5 so that a user has equivalent permissions whether accessing a public folder on a computer running Exchange Server 2003 or Exchange Server 5.5.

Because they are attributes of the public folders, access control lists replicate as part of the public folder hierarchy. Therefore, each public folder server, regardless of Exchange version, has a copy of the access control information for each folder even if it does not hold a content replica.

Replicating access control information in mixed mode involves three access control attributes for each public folder object: ptagACLData, ptagNTSD, and ptagAdminNTSD:

• ptagACLData   Holds user distinguished names and permissions in the MAPI-based format that is used by Exchange Server 5.5.

• ptagNTSD   Holds user SIDs and client access permissions in the Exchange Server 2003 format.

• ptagAdminNTSD   Holds user SIDs and administrative access permissions in the Exchange Server 2003 format.

During the conversion process, Exchange Server 2003 uses up to three attributes of the user account to identify the user and put the appropriate information in the access control list:

• SID   Unique identifier of the object in Active Directory. Sometimes, this may be the same as the SID of the original, unmigrated Windows NT Server 4.0 account. Frequently, however, this is a new value.

• LegacyExchangeDN   Distinguished name of the mailbox in the Exchange directory. Exchange Server 2003 uses this value to associate users with Exchange Server 5.5 mailboxes.

• msExchangeMasterAccountSID   If you are operating in mixed mode but the primary user accounts are still in the Windows NT Server 4.0 domain (the users log on using their Windows NT Server 4.0 accounts), Active Directory contains disabled accounts to represent the users. Each such account has an msExchangeMasterAccountSID attribute (also referred to as the Associated External Account attribute). This attribute contains the SID of the user's Windows NT Server 4.0 domain account.

Exchange Server 2003 handles the conversion process when the public folder hierarchy replicates. The access control attributes of each public folder must be converted.

For each folder access control list, when replicating from Exchange Server 2003 to Exchange Server 5.5, the conversion process does the following:

1. Converts the Active Directory SIDs of users and groups to Exchange directory distinguished names:

   • If the user accounts in Active Directory are typical enabled accounts, Exchange searches for the SID in the SID attribute.

   • If the user accounts are disabled, Exchange searches for the SID in the msExchangeMasterAccountSID attribute.

   In either case, after identifying the user account, Exchange retrieves the user's LegacyExchangeDN value and puts that in the access control list.

2. Converts the Exchange Server 2003 permissions to Exchange Server 5.5 permissions.

3. Stores the converted access control information in ptagACLData.

4. Replicates ptagNTSD, ptagAdminNTSD, and ptagACLData to the computer running Exchange Server 5.5.

For each folder access control list, when replicating from Exchange Server 5.5 to Exchange Server 2003, the conversion process does the following:

1. Discards the incoming values of ptagNTSD and ptagAdminNTSD. This step protects against any changes that may have been made to these properties while they were under the control of Exchange Server 5.5.

2. Extracts the user and group distinguished names from ptagACLData and converts them to SIDs.

   Exchange searches for the distinguished name in the LegacyExchangeDN attributes of user accounts in Active Directory.

   • If the user has an enabled Active Directory account, Exchange uses the value of the SID attribute in the access control list.

   • If the user has a Windows NT Server 4.0 account and a disabled Active Directory account, Exchange uses the value of the msExchangeMasterAccountSID attribute in the access control list. This is the SID of the Windows NT Server 4.0 account.

3. Extracts the permissions from ptagACLData and converts them to Exchange Server 2003 permissions.

4. Stores the converted access control information in ptagNTSD. The original value of ptagAdminNTSD remains unaffected.

5. Discards the value of ptagACLData, unless a problem occurred during the conversion in Step 2 or Step 3. If a conversion problem occurs, Exchange Server 2003 keeps the ptagACLData value.

Access Control Replication in Context

This section uses two examples to help illustrate how the conversion process works.

Scenario 1: Single Domain with User Accounts in Active Directory

The simplest mixed-mode configuration is a single domain where the user accounts have been migrated from the Windows NT Server 4.0 Security Accounts Manager (SAM) to Active Directory. Although the mailboxes may still reside on the computer running Exchange Server 5.5, they will be associated with Active Directory accounts instead of Windows NT Server 4.0 accounts. The following figure shows such a configuration.

A simple mixed-mode topology with one domain

You can move to this configuration from your original Exchange Server 5.5 and Windows NT Server 4.0 system in two ways:

• Upgrade the Windows NT Server 4.0 primary domain controller (PDC) to Windows Server 2003, and promote it to be a domain controller for the existing domain.

  This operation installs and configures Active Directory, moving the Windows NT Server 4.0 accounts in the process. For each account, the SID attribute is preserved intact. (The SID of the Windows NT Server 4.0 account becomes the SID of the new Active Directory account.)

• Use Active Directory Migration Tool to migrate the user accounts from the Windows NT Server 4.0 primary domain controller to Active Directory. Make sure that the migration tool migrates the user's existing SID to the SIDHistory attribute. This operation creates and enables Active Directory accounts for the users.

In either case, after you configure Active Directory Connector, it finishes populating the Active Directory user accounts with mailbox attributes such as LegacyExchangeDN.

In a topology such as that shown in the figure above, consider a user named User1 who has an account in Active Directory and a mailbox in Exchange Server 5.5.

In this example, User1 was granted Author permissions to a public folder that has content replicas on both the computers running Exchange Server 2003 and Exchange Server 5.5. If User1 is referred to the replica on the Exchange Server 5.5 public folder server, the public folder access control list on that server identifies User1 by distinguished name (/o=Org/ou=Site/cn=Recipients/cn=User1). When the access control list replicates to the Exchange Server 2003 public folder server, Exchange Server 2003 converts the information. Exchange Server 2003 looks up the user account in Active Directory that has a LegacyExchangeDN value equal to /o=Org/ou=Site/cn=Recipients/cn=User1, and retrieves the SID value for that account. Exchange places this value in the public folder access control list to identify User1.

Either server can grant User1 appropriate access to the folder.

Scenario 2: Multiple Domains With User Accounts In Windows NT Server 4.0

A more complex mixed-mode configuration is a single Exchange configuration that has multiple domains. You can reach such a configuration by installing a new Windows Server 2003 domain that trusts the existing Windows NT Server 4.0 domain instead of upgrading or migrating the Windows NT Server 4.0 domain.

The following figure shows such a configuration. In this example, the mailboxes are still on the computer running Exchange Server 5.5, and the user accounts remain in the Windows NT Server 4.0 domain. Exchange Server 2003 has been installed in the new Windows Server 2003 domain.

Exchange topology with both Windows Server 2003 and Windows NT Server 4.0 domains, and user accounts in the Windows NT Server 4.0 domain

In this configuration, in addition to the SID, SIDHistory, and LegacyExchangeDN attributes, Exchange uses the msExchMasterAccountSID attribute (also known as the Associated External Account) to identify users and match them to mailbox or access control information. The msExchMasterAccountSID attribute contains the SID of the user's Windows NT Server 4.0 account.

In a topology such as that shown in the figure above, consider a user named User1 who has an account in Windows NT Server 4.0 in Domain1 and a mailbox in Exchange Server 5.5. User1 also has a disabled account in Active Directory in Domain2.

In this example, User1 was granted Author permissions to a public folder that has content replicas on servers running both Exchange Server 2003 and Exchange Server 5.5. If User1 is referred to the replica on the Exchange Server 5.5 public folder server, the public folder access control list on that server identifies User1 by distinguished name (/o=Org/ou=Site/cn=Recipients/cn=User1).

When the access control list replicates to the Exchange Server 2003 public folder server, Exchange Server 2003 converts the information. As in any other case, Exchange Server 2003 looks up the user account in Active Directory that has a LegacyExchangeDN value equal to /o=Org/ou=Site/cn=Recipients/cn=User1. Exchange finds User1's Active Directory account, but that account is disabled. Instead of retrieving the SID from the SID attribute, Exchange retrieves the SID from the msExchMasterAccountSID attribute. Exchange puts this value, the original Windows NT Server 4.0 SID, in the public folder access control list to identify User1.

The multiple domains produce a noticeable side effect. If an administrator or user tries to modify User1's client permissions on the public folder while connected to the computer running Exchange Server 2003, the permissions dialog box lists the user in the format "Domain1\User1" instead of just "User1."

Avoiding Problems Caused by Unknown Users in Access Control Lists

An unknown user (sometimes referred to as a zombie user) is a user that is listed in an ACL, but that does not have an account. The most common way that an unknown user situation arises is as follows. When the topology was purely Exchange Server 5.5, an Exchange Server 5.5 user who had been granted permissions on Exchange Server 5.5 public folders was deleted. Later, the public folder replicates to Exchange Server 2003 with references to that user still in the ACL. Exchange Server 2003 cannot process the ACL because it cannot locate the user in Active Directory. Until the problem is resolved, only the folder owner will be able to access the folder. This restriction protects the folder from access by users that have been explicitly denied permissions on the folder. Exchange will also log a 9551 event when it has set folder permissions to "owner only." For more information about the 9551 event, and other events that might occur when you replicate information between Exchange Server 2003 and Exchange Server 5.5, see Troubleshooting and Repairing Exchange Server 2003 Store Problems.

For detailed information about how Exchange converts ACLs when folders replicate from Exchange Server 5.5 to Exchange Server 2003, see "Anatomy of Object Level Access Control" in Working with Store Permissions in Microsoft Exchange 2000 and 2003. In particular, see the subsection "Special Considerations for Coexisting Exchange 2000 and Exchange 5.5 Servers."

The best way to avoid having unknown users is to run the Exchange Server 5.5 utility DS/IS consistency adjuster before you begin replicating public folders to Exchange Server 2003. This will remove unknown users from the ACLs.

In some circumstances, Exchange Server 2003 might treat unknown users in different ways:

• If the folder has replicated from Exchange Server 5.5 before without problems but an unknown user suddenly appears in the ACL, Exchange ignores the unknown user and processes the rest of the ACL normally. The assumption in this circumstance is that a user has been deleted in Exchange Server 5.5, or a new user was added in Exchange Server 5.5 and has not yet been replicated to Active Directory. The problem will likely resolve itself on the next ADC replication interval.

• If you have removed all of the Exchange Server 5.5 servers and switched Exchange Server 2003 to native mode, Exchange assumes that the user has been deleted and removes the unknown user from the ACL.

Sometimes, you can set a registry key that tells Exchange to drop unknown users from the ACL while Exchange is in mixed mode. It is recommended that you only set this registry key when it is necessary (for example, if you have a small subset of unknown users, and they can all be safely eliminated from public folder ACLs). Otherwise, if the user was temporarily unknown because of a replication delay (as described in the preceding list), you will lose the permissions information for that user.

For detailed steps about how to temporarily ignore unknown users on an Exchange Server 2003 server that holds public folder replicas, see How to Temporarily Ignore Unknown Users on an Exchange Server 2003 Server that Holds Public Folder Replicas.