Cross-forest MSMQ? You need to be trusting

  • Article

Let's assume you want to use a classic "resource domain/account domain" setup where:

  • DomainA in Forest1 (the resource domain) contains the MSMQ servers
  • DomainB in Forest2 (the account domain) contains the service account for the MSMQ application
  • There is a 1-way trust from resource domain to account domain

which provides you with the security you want - the forest boundary stops anyone in DomainA accessing the account information in DomainB.

This works fine for actions like connecting to a remote file share but not for sending MSMQ messages.

To explain why, I'll step through the security checks for these two actions:

File share:

  1. Client (Forest2 account) sends access token to the remote machine (in Forest1) that is hosting the share
  2. Remote machine reads the access token to determine the group membership of the client’s account (access tokens can get really large when group memberships are complex)
  3. Remote machine compares account plus group membership with the Access Control List of the share
  4. Permission is granted or denied accordingly

This means there is no need for the remote machine to contact Active Directory in Forest2. A one-way trust is adequate.

MSMQ:

  1. Client (Forest2 account) sends a message that contains the account's SID in the header to a remote machine (Forest1) that is hosting the queue
  2. Remote machine reads the account SID
  3. Remote machine queries Forest2 for the account’s group membership
  4. Forest2 domain controller replies with group membership
  5. Remote machine compares account plus group membership with the Access Control List of the queue
  6. Permission is granted or denied accordingly

This means the remote machine MUST be able to contact Active Directory in Forest2. A two-way trust is essential.

Workarounds

  • Use 2-way trusts
  • Use accounts in the same forest as the MSMQ machine
  • Give Everyone and Anonymous Logon special groups the permission to send messages to the queue 

Note: It is not a big task to spoof the SID in an MSMQ message so it is recommended that you use something stronger (certificates) than an Access Control List if you are really concerned about restricting who can, and cannot, access your MSMQ queues.

Note: This only applies to sending messages. Receiving messages will follow the same model as the file share discussed above so should work fine.