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.

回答1:

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.

回答2:

I made a little picture. Hopefully this makes it a little clearer.

回答3:

You can also resolve this By setting mcauser('mqm') .. i was able to overcome 2035 error.

Define channel (channel1) chltype (svrconn) trptype (tcp) mcauser(‘mqm’)

Esp thanx to my Bilal Ahmad (PSE)

来源：https://stackoverflow.com/questions/3933555/mq-security-getting-a-2035-on-one-queue

标签

ibm-mq