MSMQ Transport Security

Replies to This Discussion

Permalink Reply by Martin Wasznicky on June 17, 2014 at 6:42am

Hi,

You can make the permissions more restrictive...but you definitely want to test.  When you do test (i.e. by sending a message to the bus...and successfully receiving it) make sure you enable WCF tracing through the logging options exposed through the Configure Server button of the Neuron ESB Explorer. There are many errors that, Microsoft's WCF team, in their infinite wisdom decided NOT to expose to anyone using their bindings.  This is the only way you can capture some of these...so it's something you want to enable when configuring and testing your environment.  However, once you're done....disable it, as it will generate lots of data...

Let's start by the actual queues that Neuron will require.  There are Topic specific queues, and Party specific queues. Each Topic and Party will have a pair of queues associated with it.  One that supports transactions, and the other that does not. The ones that do not, always have their name appended with the extension "_nontransactional".

 

The naming convention for Topics is:

 

          'topicName'

          'topicName_nontransactional' 

 

The naming convention for Parties is:

 

          'partyName_topicName'

          'partyName_topicName_nontransactional' 

Our new request/reply queues are slightly different whereas they use the "nt" extension to denote non transactional queues. There will be a pair for every party:

          'partyName_topicName_req'

          'partyName_topicName_rsp''

          'partyName_topicName_nt_req'

          'partyName_topicName_nt_rsp''

by default, ALL the queues that Neuron ESB creates (or generates scripts for) have the following permissions:

 

          Everyone - Full rights

          physical machine (defined as machinename$) - Get Properties, Get Permissions

          Administrator - Full rights

          Anonymous Logon - Full rights.

 

There are two scenarios you have to consider when attempting to apply more restrictive permissions to the Neuron ESB queues.  The first one is enabling the Neuron ESB Service to read (not just peek) from the topic based queue and distribute (write) to the party queues.

 

To accomplish this, the best route is to run the Neuron ESB service under a domain user account that is also an admin on the local Neuron ESB machine. Then, on the remote (or local) MSMQ machine, you can add the new Neuron ESB Service account to the Security tab of the Topic queues and enable the following permissions:

 

          Delete

          Receive Message

          Peek Message

          Get Properties

 

Next, modify the existing ANONYMOUS LOGON account so that it ONLY has the following rights:

 

          Send Message

 

This should be sufficient for the Neuron ESB service to successfully receive messages from publishers and distribute messages to subscribers.  This should also be sufficient for scenarios where all Parties are running in the Neuron ESB hosting environment ( i.e. Adapters, client and service connectors). 

 

Lastly, remove the Everyone and the MachineName$ accounts from the security list of the Topic queues.

 

The Second scenario you have to consider is when the Neuron ESB Client API is being remotely hosted by another .NET application, either on the Neuron ESB Server (i.e. the Neuron Test Client is a good example) or remotely..in another user application on another machine.

 

IN this scenario, the Neuron ESB Client API will be running under either the remote users identity or under an assigned service account.  You can take two approaches.  The first approach is that you can put all these users in a domain group (i.e. Neuron ESB Subscribers) and then grant that group the following rights on all the Party queues:

 

          Delete

          Receive Message

          Peek Message

          Get Properties

 

The second approach is that you can grant each individual the above rights but only for their respective pair of Party queues.

 

In all cases though, the ANONYMOUS LOGON account must be given following rights to all Party queues:

 

          Send Message

 

let us know how it works for you.

• ▶ Reply

Permalink Reply by Lionel Orellana on June 18, 2014 at 6:57am

Hi Marty, thanks for the detailed explanation. I think not giving ANONYMOUS LOGON rights to Send Message is probably where I fell over. I have to try that (after we get our first release over the line).

However I'm still confused about the different security settings. 

In a Topic, what does it mean to use 'Transport' as the Security Mode and "WindowsDomain'' as the Authentication Mode? I understand the gist of Transport security here but I don't see what windows account is used when the topic is configured this way. The service account? How is that different to specifying None as the Security Mode?

Also, where do the security settings of the endpoint fit in? If the topic above has a dependency on an endpoint which is configured with Run As credentials, what account is being used for what???

*confused*

Lionel.

 

• ▶ Reply