I’ve recently been working on a project that uses a WCF-NetMsmq receive location which points to a transactional private queue to receive messages into BizTalk Server 2010 (note that this is on a Windows Server 2008 R2 machine, experiences might differ slightly with different versions of the OS which come packaged with different versions of MSMQ). Until recently the receive location was configured with a security mode of None, and the queue was not set to be authenticated. To enable the receipt of messages from senders we had to activate the Send Message permission for the ANONYMOUS LOGON group, and to ensure that the BizTalk receive location was able to receive messages from the queue we provided Receive message permissions to the BizTalk Application Users group. If the ANONYMOUS GROUP did not have access to the queue then messages would end up in the transactional dead letter queue with an error message saying Access is denied.
This setup served us well while we were still doing development and unit testing the BizTalk application however we knew that at some point we were going to have to implement tighter security. The customer’s requirement was that queue should be locked down such that only specified AD (Active Directory) groups could send messages to the queue, and they wanted to control this through ACLs (Access Control Lists) on the queue.
In order to fulfil this requirement a prerequisite is that the Message Queuing Directory Service Integration feature is enabled on the server to enable authorization via the AD based ACL.
If this feature was not installed and messages were sent to an authenticated queue they would end up in the transactional dead letter queue with an error message saying “The signature is invalid.”
The next step would be to setup the ACLs on the private queue by right clicking on the queue in server manager, going to the Security tab and setting up your ACLs appropriately. At this stage I also removed the ANONYMOUS LOGON group’s permissions so that it was no longer possible to send messages to the queue without attached credentials. Back on the General tab of the queue’s properties, I now ticked the authenticated checkbox. Note that until this checkbox was ticked, a warning message was displayed advising that message senders could bypass restrictions specified in the ACLs.
Trying to send a message from our client application (which runs under a user profile that is permitted to send messages to the private queue) still results in the message being placed in the transaction dead letter queue with a signature is invalid type error message. Inspection of the Sender tab on the message shows that there is no SID (Windows Security Identifier) attached to the message which is quite obviously the cause of our problem.
One means of getting the credentials attached to the message is to enable transport security on our receive location with an MSMQ authentication mode of WindowsDomain. See this article for more details about MSMQ and Transport security.
Once this has been done we can republish the metadata service for this receive location, and either update the service reference for our client application which should update the application’s config file, or manually update the bindings section of the application’s config file such that the security mode is now set to Transport as below.
If the application tries to submit messages to the queue now it will do so successfully. If you try to inspect the properties of a message in the MSMQ private queue before it gets picked up by BizTalk and look at the sender tab you’ll see that the applications credentials are now attached to the message.
Trying to submit a message from the application if its credentials weren’t authorized will now result in an exception thrown within the application similar to the below.