AMQ9776: Channel was blocked - ibm-mq

Question

I need help, I have the following issue:
AMQ9776: Channel was blocked by userid
EXPLANATION:
The inbound channel 'TEST1.SRVCONN' was blocked from address '10.0.2.4'
because the active values of the channel were mapped to a userid which should
be blocked. The active values of the channel were 'MCAUSER(mqm) CLNTUSER(mqm)'.
And I have the following authorities records:
DISPLAY CHLAUTH(*)
37 : DISPLAY CHLAUTH(*)
AMQ8878: Ver detalles de registro de autenticación de canal.
CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(CHANNEL)
AMQ8878: Ver detalles de registro de autenticación de canal.
CHLAUTH(TEST1.SRVCNN) TYPE(ADDRESSMAP)
ADDRESS(10.0.2.4) USERSRC(CHANNEL)
AMQ8878: Ver detalles de registro de autenticación de canal.
CHLAUTH(TEST1.SRVCNN) TYPE(BLOCKUSER)
USERLIST(mqm)
AMQ8878: Ver detalles de registro de autenticación de canal.
CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(NOACCESS)
AMQ8878: Ver detalles de registro de autenticación de canal.
CHLAUTH(*) TYPE(BLOCKUSER)
USERLIST(*MQADMIN)
So I don't know what else I can do, I had been reading about this problem and I created the rule to connect to the channel and I granted privilege to the user. ¿What am I missing?

Answer 1

Note that for MQ v8 and later when MQ compares the MQ client user to the USERLIST of a TYPE(BLOCKUSER) rule or to the CLNTUSER on a TYPE(USERMAP) rule, it can be set to look at either the user the client process is running under or at the user that is presented in the MQCSP and successfully authenticated by CONNAUTH. To get the later behavior you must have ChlauthEarlyAdopt=y set in the Channels: stanza of the qm.ini. For new queue managers created under MQ v8.0 LTS and MQ v9.0 LTS the default would NOT be to set this and MQ will look at the user the client process is running under. For MQ v9.0.5 CD, MQ v9.1 LTS, and MQ v9.1 CD the default is to have it set and MQ will look at the user sent in the MQCSP and successfully authenticated by CONNAUTH.
Note the ChlauthEarlyAdopt setting was added at 8.0.0.5, prior to this it would always look at the user the client process is running under.
By default MQ comes with the following rule:
CHLAUTH(*) TYPE(BLOCKUSER)
USERLIST(*MQADMIN)
That rule blocks all users which MQ deems to have MQ Administrative authority from connecting to ANY SVRCONN channel on the queue manager.
You added the following two rules (note unless you add ALL to your DISPLAY command it will not show all attributes, so I can only discuss what you show):
AMQ8878: Ver detalles de registro de autenticación de canal.
CHLAUTH(TEST1.SRVCNN) TYPE(ADDRESSMAP)
ADDRESS(10.0.2.4) USERSRC(CHANNEL)
AMQ8878: Ver detalles de registro de autenticación de canal.
CHLAUTH(TEST1.SRVCNN) TYPE(BLOCKUSER)
USERLIST(mqm)
The first (TYPE(ADDRESSMAP)) will allow a connection from ADDRESS(10.0.2.4) to this channel and leave the user set to what is negotiated on the channel. But absent any other MAP rule that blocks connections by setting USERSRC(NOACCESS), this rule really does not do anything.
If you have a SVRCONN channel that has a blank MCAUSER then MQ will accept the username that is sent from the client. For most clients this is the user the process is running under, for Java and JMS it is very easy to send any user including a blank value. If both user sent by the client and MCAUSER on the channel are blank then the negotiated MCAUSER will be the user the message channel agent process is running under, on unix this would normally be mqm.
The second rule (TYPE(BLOCKUSER)) is actually telling MQ specifically to block any channel where the user is mqm is sent from the client, this is likely the opposite of what you were trying to accomplish.
If the client connecting is not an administrative application, then the best way to fix this would be to define another user and give that user permission to what it needs.
See my answer to the following question for more details on how to provide MQ permissions to a low privledge user: Authorization errors with MQ8 + JDk8
It would not be a good practice to allow applications to connect to a SVRCONN channel that has no security, you do not mention if you are using CONNAUTH or TLS certs to provide security on the channel, but if you are not you should use one or the other to lock down who can connect to the channel.