|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
MCA_USER attribute in channel |
« View previous topic :: View next topic » |
Author |
Message
|
Neha Agarwal |
Posted: Mon Sep 02, 2013 2:15 am Post subject: MCA_USER attribute in channel |
|
|
Newbie
Joined: 02 Sep 2013 Posts: 1
|
Should we define SVRCONN channel with blank MCAUSER or with application user id in MCAUSER?
I'm not sure which one is preferred. |
|
Back to top |
|
 |
exerk |
Posted: Mon Sep 02, 2013 2:47 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
The second - it's more secure. Ideally, the model SVRCONN should be altered so that it contains a 'null' userid, one that cannot exist on the platform, e.g. for UNIX, one that contains spaces, mixed case characters, and anything else that will ensure it can't be defined.
I have seen nobody used as an MCAUSER on UNIX but I strongly discourage it as I've also seen that account in the mqm group, presumably because someone didn't understand what the MCAUSER was for.
Moving this to the Security forum... _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon Sep 02, 2013 4:52 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
A channel with a blank MCAUSER but with properly configured SSL and/or a Security Exit and/or CHLAUTH records is a lot more secure than a channel with a non blank MCAUSER value of 'mqm' and no SSL, Exit or CHLAUTH.
Use SSL, a Security Exit and /or CHLAUTH to determine who can use the channel, then use a value in the MCAUSER to determine what they can do. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
gbaddeley |
Posted: Mon Sep 02, 2013 3:47 pm Post subject: |
|
|
 Jedi Knight
Joined: 25 Mar 2003 Posts: 2538 Location: Melbourne, Australia
|
exerk wrote: |
The second - it's more secure. Ideally, the model SVRCONN should be altered so that it contains a 'null' userid, one that cannot exist on the platform, e.g. for UNIX, one that contains spaces, mixed case characters, and anything else that will ensure it can't be defined.
I have seen nobody used as an MCAUSER on UNIX but I strongly discourage it as I've also seen that account in the mqm group, presumably because someone didn't understand what the MCAUSER was for. |
'nobody' seems to be a defacto standard, but I have switched to using '*NOACCESS' as it has no connotation on UNIX. This value also fits into the context of '*NOACCESS' as used in CHLAUTH rules in MQ V7.1 and later.
All the default "inbound" channel objects that have MCAUSER attribute should be altered to set MCAUSER('*NOACCESS') MAXMSGL(1) when a queue manager is created. This improves security and forces the MQ admin to think about the consequences of setting MCAUSER and MAXMSGL when a new channel is defined.
Ref. table 6.1 in IBM Redbook Secure Messaging Scenarios with WebSphere MQ
Code: |
ALTER CHANNEL('SYSTEM.AUTO.RECEIVER') CHLTYPE(RCVR) +
MCAUSER('*NOACCESS') MAXMSGL(1)
ALTER CHANNEL('SYSTEM.AUTO.SVRCONN') CHLTYPE(SVRCONN) +
MCAUSER('*NOACCESS') MAXMSGL(1)
ALTER CHANNEL('SYSTEM.DEF.CLUSRCVR') CHLTYPE(CLUSRCVR) +
MCAUSER('*NOACCESS') MAXMSGL(1)
ALTER CHANNEL('SYSTEM.DEF.RECEIVER') CHLTYPE(RCVR) +
MCAUSER('*NOACCESS') MAXMSGL(1)
ALTER CHANNEL('SYSTEM.DEF.REQUESTER') CHLTYPE(RQSTR) +
MCAUSER('*NOACCESS') MAXMSGL(1)
ALTER CHANNEL('SYSTEM.DEF.SERVER') CHLTYPE(SVR) +
MCAUSER('*NOACCESS') MAXMSGL(1)
ALTER CHANNEL('SYSTEM.DEF.SVRCONN') CHLTYPE(SVRCONN) +
MCAUSER('*NOACCESS') MAXMSGL(1) |
_________________ Glenn |
|
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
|
|
|
|