| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MCA user |
« View previous topic :: View next topic » |
| Author |
Message
|
| swann |
 Posted: Tue Nov 08, 2011 7:58 pm Post subject: MCA user |
 |
|
Acolyte
Joined: 21 Jun 2011
Posts: 50
|
Hi Friends,
To my understanding,a client connecting to a Queue manager through SVR connection channel should have his ID added where the QM resides with privileged connection authorities.If this is the case then we can just ignore the MCA user field.
Another assumption is If the MCA user field in the SVR connection channel is set to "mqm" then any user with his ID added in the system where QM resides , be overwritten and he has a full administrative authority irrespective of assigned authority.
Any corrections or the validations on the above notes will be greatly appreciated. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Tue Nov 08, 2011 9:29 pm Post subject: Re: MCA user |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| swann wrote: |
Hi Friends,
To my understanding,a client connecting to a Queue manager through SVR connection channel should have his ID added where the QM resides with privileged connection authorities.If this is the case then we can just ignore the MCA user field.
Another assumption is If the MCA user field in the SVR connection channel is set to "mqm" then any user with his ID added in the system where QM resides , be overwritten and he has a full administrative authority irrespective of assigned authority.
Any corrections or the validations on the above notes will be greatly appreciated. |
To your first point: not quite.
If you use a SVR channel, anybody who knows this server channel can connect. If no user information is passed the message will assume the authority of the agent (mqm) and as such your qmgr is open to everybody in admin mode....
To avoid this 2 things:
- Setting the MCAUser forces the user to the preset value regardless of whether the user has been defined to the system or not. The preset user on the channel's MCAUser field should have been defined to the system.
- Using SSL, ensures that only authorized users will be able to connect.
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Nov 08, 2011 11:58 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You never want to have a svrconn mcauser set to mqm, unless also secured by SSL peer level checking of identity.
BlockIP2 (which does far more than just allow IP checking) can be used to allow the id to be passed from the client, but block use of mqm (or others deemed unacceptable). This is a free exit. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 09, 2011 6:17 am Post subject: Re: MCA user |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| swann wrote: |
| To my understanding,a client connecting to a Queue manager through SVR connection channel should have his ID added where the QM resides with privileged connection authorities.If this is the case then we can just ignore the MCA user field. |
More or less. I'd call it "connection authority"; privledge implies some high level of control. The user will need connect authority on the queue manager just like he needs get or put on the queue manager.
Note that the user id is not validated by the queue manager. It's possible for an application to spoof it's identity and use a different user id. Likewise the user id passed can vary by OS & situation. Hence the suggestion by my worthy associate to use BlockIP2 or other additional security in this circumstance.
| swann wrote: |
| Another assumption is If the MCA user field in the SVR connection channel is set to "mqm" then any user with his ID added in the system where QM resides , be overwritten and he has a full administrative authority irrespective of assigned authority. |
Yes. Never put mqm in a SVRCONN. Unless you're certain you've got SSL locked down really tight. Perhaps not even then.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Nov 09, 2011 6:25 am Post subject: Re: MCA user |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
it's perfectly okay to create a specific SVRCONN that is designated and designed to act as an administration only channel, and thus has MCAUSER==MQM.
BUT, it must then have a very very tight SSL configuration, including a very exclusive SSLPEER value. And the certs that match that are then also handled under very tight controls as if they were the keys to the server room - which they are.
However, if you then leave the rest of the channels into this queue manager, regardless of type, without an SSL configuration, then it doesn't matter what you did with this svrconn. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 09, 2011 6:36 am Post subject: Re: MCA user |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
it's perfectly okay to create a specific SVRCONN that is designated and designed to act as an administration only channel, and thus has MCAUSER==MQM.
BUT, it must then have a very very tight SSL configuration, including a very exclusive SSLPEER value. And the certs that match that are then also handled under very tight controls as if they were the keys to the server room - which they are. |
You rapidly end up with diminishing returns in terms of security. If the server room has a single key (a channel with mqm), you then need to lock the key in a secure box (which everyone will know where it is) and hand out keys to the box to everyone who needs to use it, then track who has those keys, and handle the certificate expiration.
Is that administratively better or worse than having a known number of keys to the server room given to a known list of people?
| mqjeff wrote: |
| However, if you then leave the rest of the channels into this queue manager, regardless of type, without an SSL configuration, then it doesn't matter what you did with this svrconn. |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Nov 09, 2011 6:40 am Post subject: Re: MCA user |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| mqjeff wrote: |
it's perfectly okay to create a specific SVRCONN that is designated and designed to act as an administration only channel, and thus has MCAUSER==MQM.
BUT, it must then have a very very tight SSL configuration, including a very exclusive SSLPEER value. And the certs that match that are then also handled under very tight controls as if they were the keys to the server room - which they are. |
You rapidly end up with diminishing returns in terms of security. If the server room has a single key (a channel with mqm), you then need to lock the key in a secure box (which everyone will know where it is) and hand out keys to the box to everyone who needs to use it, then track who has those keys, and handle the certificate expiration.
Is that administratively better or worse than having a known number of keys to the server room given to a known list of people? |
It depends on how many queue managers there are, such that one choice allows me to manage them from a single machine and the other choice requires that I manage them individually from each machine. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
