| Author |
Message
|
| Sathyan |
 Posted: Fri Feb 28, 2014 4:00 am Post subject: Issues connecting the broker when MCAUSER is blank |
 |
|
Newbie
Joined: 04 Jul 2013
Posts: 5
|
We are trying to implement access restriction in our Message broker environment. The access for the developers is planned by using the Server connection Channel with MCAUSER as blank so that the access will be taken from the access provided to the particular user opening the toolkit. It worked for my user id. But when trying to connect the broker from other user id, i am getting the error"The remote broker is not running.". I am not sure what is missing. Please help me..  |
|
| Back to top |
|
 |
| McueMart |
| Posted: Fri Feb 28, 2014 5:09 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
| What does the Queue Manager error log tell you? Is it showing some permissions errors for the SVRCONN you are using? |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Feb 28, 2014 6:33 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
A blank MCAUSER field on a channel is a massive security exposure.
The way to solve this is to use BlockIP2 exit (or equivalent CHLAUTH rules) to block the use of blank ids on the connection, block privileged ids such as mqm, but allow other ids to pass through as themselves.
The MCAUSER field itself is set to NoBody (although BlockIP2 would override this).
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Feb 28, 2014 6:41 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
There are two levels of security when working with IIB.
There are the necessary permissions to connect to the Integration Node's queue manager itself. And then there are the necessary permissions to interact with the Integration Node and any Integration Servers it hosts.
These are two separate permission sets. In later levels of IIB/WMB, both sets of permissions are expressed with MQ permissions, granted or removed by setmqauth.
If you leave the MCAUSER blank, then the ID that gets passed to MQ from the *Toolkit* *only* is the ID that is running the Toolkit. This is a "good idea", from a Toolkit point of view, but a "bad idea" from an MQ point of view. MQX/MBX do not necessarily pass the same information along, and any MQ app can connect to the channel and pass any ID that it wants.
Regardless, whatever ID is finally presented to MQ is the ID that is used to determine what tasks the user can do in both MQ and IIB. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Feb 28, 2014 6:58 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Using the blockip2 approach that I mentioned, works fine with WMB or IIB (as well as closing the exposure).
The non-blank, non-mqm id that is mapped through by the exit is then used to check authorities by WMB against the MQ OAM.
You don't need to have a blank MCAUSER field for this approach to work.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Feb 28, 2014 7:12 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
Using the blockip2 approach that I mentioned, works fine with WMB or IIB (as well as closing the exposure).
The non-blank, non-mqm id that is mapped through by the exit is then used to check authorities by WMB against the MQ OAM.
You don't need to have a blank MCAUSER field for this approach to work. |
I'm quite sure I agreed with you. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Feb 28, 2014 7:21 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
@zpat
blockip2 would only secure the channel if it was mapping an SSL Cert to an ID at the MQ server. Or, somehow securely authenticating the remote user and also mapping it to an ID at the MQ server.
For WMQ, you can never trust the ID being sent. With SSL, you are trusting the cert being sent because you know who issued it, who has it and that everybody kept it secure (whether they did or didn't, but that is trust for ya).
imho anything else is just wishful thinking... |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Feb 28, 2014 7:25 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I realise that it does not verify the non-blank, non-privileged, user id - without also using SSL.
But it's a lot better than nothing and having a blank MCA user field.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Feb 28, 2014 7:41 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
I'm sure "Target" felt that way a few months ago...
"Something is better than nothing"="false sense of security"
Here is one way to evaluate it:
What is the cost of the use of the data if it is stolen?
- To you
- To your customer
- To any future customer of yours
Your employer is also your customer...
I'm just trying to make the point to causal readers that security is not simple and needs to be taken seriously. |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Feb 28, 2014 7:44 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
This thread recommended a blank MCAUSER - now that is really not a good idea because it allows privileged users (like mqm) to access.
My recommendation is to block unverified privileged users. I don't see how that is anything other than good advice.
Yes, it does not go all the way to verifying everyone - but I didn't tell them NOT to do that.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Feb 28, 2014 7:46 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| JosephGramig wrote: |
I'm sure "Target" felt that way a few months ago...
"Something is better than nothing"="false sense of security"
Here is one way to evaluate it:
What is the cost of the use of the data if it is stolen?
- To you
- To your customer
- To any future customer of yours
Your employer is also your customer...
I'm just trying to make the point to causal readers that security is not simple and needs to be taken seriously. |
To which, the most frequent response is "...What are the odds of that happening?!"
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Feb 28, 2014 8:12 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| zpat wrote: |
| This thread recommended a blank MCAUSER |
I don't see anyone, particularly myself, doing that. |
|
| Back to top |
|
|
|
|
