MQ security - getting a 2035 on one queue

I have a application that is trying to put a message to a queue(LOG.TRANSACTION.IN) on a remote queue manager. The message ends up failing with a 2035 and is put on the DLQ on the local queue manager. On the local queue manager(QMLOCAL), the application puts the message directly on the SCTQ, since there is no remote queue definition. The application is running under an ID that has full access to MQ. I know that is not ideal, but that is for another discussion. We have an mcauser on the clusrcvr channel on the remote end(QMREMOTE) that has been granted access to the local queue. I thought I had the security worked out, but it appears that is not the case. Here is the security information

QMLOCAL: Entity application_id has the following authorizations for object SYSTEM.CLUSTER.TRANSMIT.QUEUE: get browse put inq set crt dlt chg dsp passid passall setid setall clr

QMREMOTE: Entity MY_MCAUSER has the following authorizations for object LOG.TRANSACTION.IN: put crt setall

Any help on this would be greatly appreciated.

There are a few possibilities here. Since the message ends up in the DLQ then we know that the problem is on the remote side. If your putting application generated the 2035 then the message would never be put.

This means that the MCAUSER in the CLUSRCVR channel is where the problem is. In order for it to work, it needs to have the following (Assume MY_MCAUSER is in group mqmmca):

setmqaut -m QMREMOTE -g mqmmca -t qmgr -all +connect +inq +setall
setmqaut -m QMREMOTE -g mqmmca -n 'LOG.TRANSACTION.IN' -t queue -all +put +setall

Unrelated to your 2035, the channel also needs
setmqaut -m QMREMOTE -g mqmmca -n 'SYSTEM.CLUSTER.COMMAND.QUEUE' -t queue -all +put +setall
just to function in the cluster. Depending on your version, the channel MCAUSER might also need access to SYSTEM.CHANNEL.SYNCQ (v7 variants).

An easy way to tell for sure is to enable authorization events.
ALTER QMGR AUTHOREV(ENABLED)

The authorization events tell you the ID that failed, the object it failed on (QMgr, queue, etc.), the API call being made and the options that were used.

Then install SupportPac MS0P into WMQ Explorer. This will format the binary PCF event messages into human-readable form and it will be really obvious what exactly the problem is.

In this case it is likely that either a) the MCAUSER lacks +setall on the QMgr or b) it's a v7 and the MCAUSER lacks the appropriate permission on the S.C.SQ as noted above.

I am installing the latest MQ explorer and will let you know about the security. The odd part is that we have the same permissions across the board, using the group MQMMCA with the permissions supplied from your website. This is the only instance in our enviroment where a queue manager is putting to a remote queue that is not either clustered or has a qr defined locally.

Matt 2010-10-14 18:27:17

Also, this is MQ 6.0.2.8 on AIX.

Matt 2010-10-14 18:36:17

T.Rob 2010-10-14 18:36:41

Ha! What timing. OK so at least it's not the S.C.SQ problem. You know about v6.0 end-of-service in September 2011, right? Please encourage a migration to v7 so you don't get caught with no support next year.

T.Rob 2010-10-14 18:38:16

We are in an active project to move to v7. It's a huge process!

Matt 2010-10-14 20:20:12

Ok, so now I'm a bit confused. I see the 2035 using Explorer and here's the output:Open Options: [out passid]

Matt 2010-10-15 17:16:05

Sorry, edit time ran out: Open Options: [out passid] User Identifier: generic_id (which has no access to the remote qmgr), Appl Type: UNIX, Appl Name: DataFlowEngine64. So this clearly makes sense why it is getting a not authorized. I guess the one thing that I have a question about is why is it still using this ID when it is coming across a channel that has an mcauser set? Context security is not enabled on the channel, so I would expect all of the messages to come in authorized with that mcauser.

Matt 2010-10-15 17:27:16

So, those messages listed above were on the remote qmgr. I was just able to get the messages from the local qmgr that was also getting messages sent to the DLQ, and see the following:Reason Qualifier: Open Not Authorized, Queue Name: LOG.TRANSACTION.IN, Open Options: out passid, User Identifier: MY_MCAUSER, Appl Type: Unix, Appl Name: amqrmppa, Object Queue Manager Name: QMREMOTE

Matt 2010-10-15 18:16:25

You sure you have those right? The channel's processID is amqrmppa so that should be the remote QMgr, not the local one. The DataFlowEngine64 is the broker's execution group so that should be the local QMgr. It makes sense that the broker would use passID. In your comment it looks like channe's using passid too and that seems wrong.

T.Rob 2010-10-15 20:51:43

If you have gotten local and remote reversed, is it possible the request is getting to the broker but it's the reply that's failing? Give the broker +passid on it's output queues (or the XMitQ if the app uses dynamic reply-to queues). That solves the problem on the borker side but not sure why you are seeing +passid from amqrmppa unless you mis-read it.

T.Rob 2010-10-15 20:57:18

I made a little picture. Hopefully this makes it a little clearer. http://imgur.com/92NJm.jpg

Matt 2010-10-18 13:03:51

Hi Matt, In the picture the top box shows a process name of amqrmppa and the ID MQMCA is the one I believe is in the MCAUSER of the CLUSRCVR. Since amqrmppa is the process that runs *inbound* channels, this all points to an authorization problem with the reply message, not the request. (Assumes flow is request from top to bottom, followed by reply from bottom to top.)

T.Rob 2010-10-21 01:10:21

On the bottom box, the process ID of DataFlowEngine64 indicates it is the broker having problems opening the output queue. I'm guessing the broker re-queues the output to the DLQ since normally local apps don't automatically requeue output messages. So all in all, I think the flow of messages top to bottom is working, it's the flow of replies that seems to be getting hosed.

T.Rob 2010-10-21 01:14:03

ansaurus

tags:

views:

answers:

MQ security - getting a 2035 on one queue

related questions