Exchange Server 2003 users in one child domain cannot access shared resources from another child domain in the same Active Directory forest

Consider the following scenario:

• You have a single Active Directory directory service forest that contains two child domains.
• You install Microsoft Exchange Server 2003 in the child domains.
• You create shared resources in one child domain, such as a shared calendar or a shared resource mailbox.
• You grant access to the shared resources for Exchange Server 2003 users in both child domains. For example, you grant the following rights for each shared resource:
  • Full Control
  • Take Ownership
  • Send As
  • Receive As

In this scenario, Exchange Server 2003 users who have mailboxes in the same domain as the shared resources can access the shared resources. However, Exchange Server 2003 users from the remote domain cannot access the shared resources. Additionally, Exchange Server 2003 users receive the following error message in Microsoft Office Outlook: When you perform a Network Monitor trace in the remote Exchange Server 2003 client, you receive the following error message:

This issue occurs if a well-known security identifier (SID) is added to the access control list (ACL) of the mailbox store or of the Exchange Server 2003 object in the remote domain. Because well-known SIDs are non-unique values, the Exchange Server 2003-based server that hosts the shared resource cannot correctly authenticate the user from the remote domain who requests access to the shared resource.

Note An SID is a unique name that is used to determine an object, such as a user or a group of users, in a network that uses one of the following operating systems:

• Microsoft Windows NT 4.0 and Windows NT 3.51
• Microsoft Windows 2000
• Windows XP
• Windows Server 3003
• Windows Vista

Windows grants or denies access and rights to ACL-based resources that use SIDs to uniquely determine users and their group memberships. When a user requests access to an ACL-based resource, the SID of the user is verified by the ACL. This verification is to determine whether the user can access the ACL-based resource or to determine whether the user is part of a group that can access the ACL-based resource.

Well-known SIDs are a group of SIDs that determine generic users or generic groups. The values of well-known SIDs remain constant across all operating systems. Therefore, these SIDs are named well-known SIDs. Well-known SIDs include built-in accounts and built-in groups. Additionally, well-known SIDs include label accounts, such as the Everyone group.

To resolve this issue, use the Dsacls.exe tool to dump the ACL for the mailbox store distinguished name (DN), the administrative groups DN, and the servers DN where the remote user mailbox resides. To do this, follow these steps:

1. Use the Ldp.exe utility from the Windows Server 2003 Support Tools to connect and bind to a domain controller in the remote domain.
2. In the console tree in tree view, expand Domain_name.
3. Expand Configuration, expand Services, expand Microsoft Exchange, and then expand Organization_name.
4. Expand Administrative Groups, expand Administration_group_name, expand Servers, and then expand Server_name.
5. Expand InformationStore, expand Storage_group_name, and then click Mailbox Store.
6. Right-click the mailbox store object, and then click Copy DN.
7. Start Notepad, right-click anywhere in Notepad, and then click Paste.
8. Save the Notepad file, and then exit Notepad.
9. In the console tree, right-click the Administrative Groups object, and then click Copy DN.
10. Start Notepad, right-click anywhere in Notepad, and then click Paste.
11. Save the Notepad file, and then exit Notepad.
12. In the console tree, right-click the Servers object, and then click Copy DN.
13. Start Notepad, right-click anywhere in Notepad, and then click Paste.
14. Save the Notepad file, and then exit Notepad.
15. Click Start, click Run, type cmd, and then press ENTER.
16. At a command prompt, type the following command, and then press ENTER:
    dsacls "DN_of_mailbox_store" > mailboxstoreACL.txt
    Note For example, type the following command, and then press ENTER:
    dsacls "CN=Mailbox Store (server_name),CN=First Storage Group,CN=InformationStore,CN=server_name,CN=Servers,CN=SC,CN=Administrative Groups,CN=domain_name,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain_name,DC=com" > mailboxstoreACL.txt

The ACL for a Greenfield Exchange Server 2003 mailbox store resembles the following ACL:



There are no well-known SIDs in this ACL. Compare these ACL values with the ACL values from the Exchange Server 2003 mailbox store. You may find a built-in account entry in the Exchange Server 2003 mailbox store ACL. If you do not find a built-in account entry in the Exchange Server 2003 mailbox store ACL, check the ACL of the Exchange Server 2003-based server and the ACL of the administrative groups from the dump files.

If you find an explicit access control entry (ACE) in the Exchange Server 2003 mailbox store, you may have disabled inheritable permissions for the object. Additionally, you may have manually added the explicit access control entry. If the built-in access control entry is present at the server level or at the administrative group level, remove the built-in access control entry from the ACL of the server and from the ACL of the administrative group.

Note Even if you resolve the permissions issue, you may still be unable to authenticate correctly when you access shared resources. This is because store permissions are cached for up to two hours. Therefore, if you still cannot authenticate, wait for two hours, and then retry. Otherwise, stop or restart the Information Store service on the Exchange Server 2003-based server that hosts the shared resources. This updates the store cache.