Unable to connect to queue manager in WebSphere MQ 7.1

Question

I've installed WebSphere MQ 7.1 on Linux platform, after which I installed WebSphere Message Broker 8.0.0.1. Now when I try to create an execution group, I get an exception: Reason code 2035. This exception states that the user is unauthorised to connect to the queue manager. I have this user added in the mqm group. I did not face any such issue when I was working with MQ 7.0.x. I searched a lot and came to know that there is user ID blocking in MQ 7.1. But, I want this user to be able to create execution group, how can I do so? Please advise.

Answer 1

MQ security has been improved a lot in MQ v7.1 and is different from what it used to be in earlier MQ versions. In MQ v7.1, by default all SYSTEM.channels are blocked. If you are trying to use any of these SYSTEM. channels then you will get 2035 which is MQRC_NOT_AUTHORIZED. The recommended way is to create your own SVRCONN channel for broker and create channel authentication records to allow the user to access queue manager.

Please see this link for detailed answers from T.Rob on similar issue.

Update:

A SVRCONN channel defines the endpoint of a queue manager meaning the connection information required by the clients to connect to a queue manager. Client applications use this type of channel to send and receive messages to/from a queue or a topic.

Message Broker toolkit is GUI that you can use to administer message broker, for example creating execution groups, creating flow, deploying bar files etc. Toolkit is available on Windows and I guess it's available on Linux.

I got to know that MB toolkit requires SYSTEM.BRK.CONFIG channel which is a SVRCONN channel to connect to queue manager. I am thinking this is the channel you will need to authorize to allow Message Broker to connect to MQ. Can you check if this is the case and if so create channel authentication record for that channel?

Answer 2

If you create a new QMgr at V7.1 or above, it comes with the following default CHLAUTH rules:

SET CHLAUTH(SYSTEM.ADMIN.SVRCONN)           TYPE(ADDRESSMAP)
    DESCR(Default rule to allow MQ Explorer access)
    ADDRESS(*) 
    MCAUSER( )                              USERSRC(CHANNEL)

SET CHLAUTH(SYSTEM.*)                       TYPE(ADDRESSMAP)
    DESCR(Default rule to disable all SYSTEM channels)
    ADDRESS(*)
    MCAUSER( )                              USERSRC(NOACCESS)

SET CHLAUTH(*)                              TYPE(BLOCKUSER)
    DESCR(Default rule to disallow privileged users)
    USERLIST(*MQADMIN)

The one on the bottom tells the QMgr "if someone tries to connect over a SVRCONN using an administrative user ID, block the connection in all cases."

To allow a connection from Broker Toolkit you have two choices as follows:

1. Remove mqbrkrs from the mqm group. This allows it to connect without firing the CHLAUTH rule that blocks admin users. You will of course be required to grant authorization for the mqbrkrs group to all the broker and application queues to which it needs access since it is no longer an MQ admin.
2. Override the CHLAUTH rule to allow the broker toolkit to connect as an admin on the SYSTEM.BROKER.CONFIG channel.

As a security specialist, I favor the first option. It is unavoidable that the MQ admin can administer the broker. However it is possible to avoid allowing the broker (and by extension all the broker flows) to administer the QMgr.

If, however, you wish to take the second route you'll need to override the CHLAUTH rule that blocks admin access. There are several ways to do this. You could delete the rule but that opens all your channels to admin connections. A more precise approach is to provide a rule just for the channel on which the administrator is to connect. For example:

SET CHLAUTH(SYSTEM.BKR.CONFIG) TYPE(BLOCKUSER) +
    USERLIST('*NOACCESS')

Since WMQ applies the most specific rule, the default rule is overridden by the new one but only for the SYSTEM.BKR.CONFIG channel. The BLOCKUSER rule syntax allows us to specify who to deny but not who to allow and it takes user IDs rather than group IDs. In order to allow admin access it is necessary to specify some ID that is not *MQADMIN. I picked *NOACCESS because it cannot be an actual user ID and is a reserved word used by WMQ elsewhere. You could as easily used any user ID such as nobody or even mqm. (Blocking mqm would allow mqbrkrs but not mqm however since mqbrkrs is in the mqm group it would not restrict mqbrkrs from administering the QMgr.)

Finally, note that any channel which allows admin access should be strongly authenticated. If the only CHLAUTH rule you set is the one above, then anybody with a network route to the QMgr can connect on that channel by asserting the mqbrkrs user ID on the connection. Once connected, they would have full control over the QMgr and the ability to remotely, anonymously execute commands using the mqm or mqbrkrs user IDs. At the very least add a CHLAUTH rule to filter conenctions on this channel by IP address. Or, even better, use SSL and filter connections by the certificate distinguished name.