| Author |
Message
|
| Api123 |
 Posted: Mon Aug 16, 2010 9:27 am Post subject: QMgr-to-QMgr security |
 |
|
Apprentice
Joined: 26 May 2010
Posts: 31
|
Hi All,
The objective is allowing only the defined MCAUSER on inbound MCA channel (RCVR) to put messages on a queue.
QM1: I’ve set MCAUSER on an inbound MCA channel (RCVR). Used setmqaut to give explicit access on (QM1, Local queue, and DLQ) to MCAUSER.
Qm2: I’ve application with MQEnvironment.UserId=”xxxx” connecting via SVRCONN with MCAUSER set on the channel, putting messages on remote definition queue (this is working). The issues is I’m able to put messages on QM1 via Q2 with different users (using the application) than the one defined on the RCVR channel.
These users are not member of mqm or Windows administrators group.
I’ve check the message contexts user identifier field, it confirms it’s not the MCAUSER. I'm finding, it's a little bit different to configure MCAUSER on the RCVR channel than SVRCONN channel. can you assist please. Thanks |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Mon Aug 16, 2010 10:41 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9396
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I'm finding, it's a little bit different to configure MCAUSER on the RCVR channel than SVRCONN channel. can you assist please. |
What do you find that is different?
_________________
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 |
|
|
| exerk |
| Posted: Mon Aug 16, 2010 10:50 am Post subject: Re: QMgr-to-QMgr security |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Api123 wrote: |
| ...it's a little bit different to configure MCAUSER on the RCVR channel than SVRCONN channel. can you assist please. Thanks |
No it isn't, it's exactly the same...
_________________
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 |
|
|
| Api123 |
| Posted: Mon Aug 16, 2010 11:16 am Post subject: |
|
|
Apprentice
Joined: 26 May 2010
Posts: 31
|
| I'll double check the configuration assuming MCAUSER on SVRCONN and RCVR channel is identical |
|
| Back to top |
|
|
| Api123 |
| Posted: Mon Aug 16, 2010 11:53 am Post subject: |
|
|
Apprentice
Joined: 26 May 2010
Posts: 31
|
| Still I can put messages with other users than the one defined on RCVR channel. What are possibilities that MCAUSER on RCVR channel is deemed ineffective? |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Aug 16, 2010 11:59 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Api123 wrote: |
| Still I can put messages with other users than the one defined on RCVR channel... |
What exactly do you mean? Are messages going to queues (via the RCVR channel) that the userid has no explicit authority to put to?
_________________
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 |
|
|
| Vitor |
| Posted: Mon Aug 16, 2010 12:00 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Api123 wrote: |
| What are possibilities that MCAUSER on RCVR channel is deemed ineffective? |
None. If you think otherwise, raise a PMR.
FWIW I don't think this is going to do what you think it's going to do.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Mon Aug 16, 2010 2:38 pm Post subject: Re: QMgr-to-QMgr security |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
| Api123 wrote: |
| QM1: I’ve set MCAUSER on an inbound MCA channel (RCVR). Used setmqaut to give explicit access on (QM1, Local queue, and DLQ) to MCAUSER. |
Did you set Put Authority (PUTAUT) to 'Context' for the RCVR channel?
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Aug 16, 2010 3:01 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The MCAUSER will replace any authorization passed in, provided of course the PUTAUTH is not set to something that overrides that.
MCAUSER only applies to messages being sent over the specific channel.
A running channel instance does not refresh itself instantly when a channel definition changes.
An MCAUSER on a receiver channel has no impact on authorities on the qmgr on the sender/server/requester side. |
|
| Back to top |
|
|
| Api123 |
| Posted: Tue Aug 17, 2010 6:23 am Post subject: |
|
|
Apprentice
Joined: 26 May 2010
Posts: 31
|
You guys are real help. Thanks All
Thank Roger,
Indeed PUTAUT was set to (DEF)
Now I receive the expected errors at
QM1:
AMQ9544: Messages not put to destination queue.
QM2:
AMQ8077: Entity 'test_A' has insufficient authority to access object 'TCP.MAP1.PCSQ01.001' |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Aug 18, 2010 3:40 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7717
|
And now anyone on QM2 can create a message with mqm in the MQMD Header and send to any queue they want on QM1. Don't use PUTAUT(CONTEXT) unless you have complete control of QM2 and everyone and anyone that connects and authenticates to QM2.
If the RCVR channel's MCAUSER is set to ABC123, then that channel will only be able to access queues that user ABC123 has authority to, and it will work with PUTAUT(DEF).
Either you did not restart the channel the first time after setting the MCAUSER, or user ABC123 has more authority than you realize.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Api123 |
| Posted: Wed Aug 18, 2010 9:09 am Post subject: |
|
|
Apprentice
Joined: 26 May 2010
Posts: 31
|
| PeterPotkay wrote: |
And now anyone on QM2 can create a message with mqm in the MQMD Header and send to any queue they want on QM1. Don't use PUTAUT(CONTEXT) unless you have complete control of QM2 and everyone and anyone that connects and authenticates to QM2.
|
Interesting. But users in mqm or administrators group in QM1 differ from QM2. We do not have control over QM2. My understanding if some one using an application used [MessageObject].UserId = "mqm" or MQEnvironment.UserId=”mqm” asuming mqm is a user with membership in mqm or administrators group only in Q2, still the message put should be rejected as the MCAUSER on the RCVR channel will only allow ABC123 who is not a member of the mqm or the Administrators group with in that domain. I have tested this scenario. Sorry Peter maybe I do not understand the concept here.
I’ve been reading some security pointers @ http://t-rob.net/
But still cannot grasp what’s the best practice to secure QMgr-to-QMgr for a small environment
| PeterPotkay wrote: |
If the RCVR channel's MCAUSER is set to ABC123, then that channel will only be able to access queues that user ABC123 has authority to, and it will work with PUTAUT(DEF).
|
Scenario: ABC123 and ABC100 both have permission (Queue manager, Local Queue, DLQ) . ABC123 is defined as MCAUSER in RCVR
if PUTAUT(DEF) then ABC100 still can put messages, no matter what I did to restart the channel or restart the queue manager
ABC123 is defined as MCAUSER in RCVR
if PUTAUT(CTX) then ABC100 put will fail. Channel restart will be required |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Aug 18, 2010 9:29 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Api123 wrote: |
| the message put should be rejected as the MCAUSER on the RCVR channel will only allow ABC123 who is not a member of the mqm or the Administrators group with in that domain. |
NO.
MCAUSER replaces the identity. It does not verify the identity.
ETA: I repeat myself. Again. |
|
| Back to top |
|
|
| Api123 |
| Posted: Wed Aug 18, 2010 9:42 am Post subject: |
|
|
Apprentice
Joined: 26 May 2010
Posts: 31
|
| mqjeff wrote: |
| Api123 wrote: |
| the message put should be rejected as the MCAUSER on the RCVR channel will only allow ABC123 who is not a member of the mqm or the Administrators group with in that domain. |
NO.
MCAUSER replaces the identity. It does not verify the identity.
ETA: I repeat myself. Again. |
What does this mean? What is getting replaced and with what?
If ABC123 is the MCAUSER defined for a RCVR channel with PUTAUT(CTX). User ABC100 tries to put a message vi that channel what happens? Can you explain please? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Aug 18, 2010 9:58 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Api123 wrote: |
What does this mean? What is getting replaced and with what?
If ABC123 is the MCAUSER defined for a RCVR channel with PUTAUT(CTX). User ABC100 tries to put a message vi that channel what happens? Can you explain please? |
If PUTAUT is set to CTX, then whatever value is specified in the MQMD.UserId field is used to authorize the user to the specified resource.
You do not have any control over the sender of the message, so this means that anyone at all can create a message with a UserID of 'mqm', and have full authority to everything on your queue manager.
I hope you understand that the above situation is bad.
If PUTAUT is left at Default, and you have set MCAUSER(ABC123), then every message, regardless of what is put into it, will be authorized against whatever permissions the user ABC123 has.
This is limiting, in that it means every application on the sending side has access to all queues that the user ABC123 has access to. But it's significantly better and a significantly smaller set than EVERY QUEUE ON THE QMGR. |
|
| Back to top |
|
|
|
|
