This guide started off on how to access a local QM on Linux using MQ Explorer.Then it morphed into a great little article on my experiences. In this article I cover how to allow connections from MQ Explorer and to secure what WMQ objects can be accessed. I thought it was about time I documented it. I always seem to forget all the parts required.

http://www-01.ibm.com/software/integration/wmq/explorer/

Upload to server and unzip

Run Setup.bin

Complete install, then install a JRE. To keep thing s simple you can install the WMQ JRE. I suppose you must have either trial version of WMQ or a full-version otherwise why would you be installing MQ Explorer to access a local Queue Manager?

Result:

Locate the download by following links on:

then navigate to /op/ibm/WebSphere_MQ_Explorer

Once MQ Explorer is running:

2538 (09EA) (RC2538): MQRC_HOST_NOT_AVAILABLE

Explanation

An MQCONN call was issued from a client to connect to a queue manager but the attempt to allocate a conversation to the remote system failed. Common causes of this reason code are:

• The listener has not been started on the remote system.
  
• The connection name in the client channel definition is incorrect.
  
• The network is currently unavailable.
  

This is usually due to the Channels defined.

Access is not permitted. You are not authorised to perform this operation (AMQ4306)

This should not be fixed with:

ALTER CHL(SYSTEM.ADMIN.SVRCONN) CHLTYPE(SVRCONN) MCAUSER(‘mqm’)

Specifying MCAUSER on the SVRCONN channel means that any application that connects using that channel will have the authority of the user specified on the channel, not the user id sent by the client application. If you specified mqm, which is mq’s adminstration user on unix/linux, this means any application connecting using that channel will have full authority on the queue manager.

The most common cause is that you are on a Windows machine and connecting as as specific user. most likely a domain user something like <Machine name>\<user name>

On my laptop (Windows Professional 7) I added my user account to the mqm goup on my Windows machine. We know that on Linux mqm group has access to the QM objects.

Note: Refresh security on queue manager once the SVRCONN channel types is added to the QM.

Next we also need to ensure that the user is given access

Viewing the logs, when trying to use MQ Explorer locally on the Linux machine. This can help use see what’s happening?

cd /var/mqm/qmgrs/TEST2/errors

There are several options at this point:

1. If the customer wants the required userID to have full privileges over all MQ objects, add the userID to the mqm group on the UNIX machine, again using the O/S facilities to do so. In this case there is no further action required.
2. An alternative method of giving full privileges is to set the MCAUSER attribute on the SVRCONN channel created at step 4 above to mqm. Do this by adding MCAUSER(‘mqm’) to the above runmqsc command. Again, no further action is required.
3. If restricted access to MQ objects is required, further commands are necessary as below

We want to use option 3 as it is best for enterprise security. (use options 1 and 2, if security is of no concern)

Grant specific authority over MQ objects to the required userID

Issue these setmqaut commands to grant minimal authority to the userID:

We need to create and equivalent user on the linux box to match the Widows user

My windows user is called SteveRobinson, and I cannot have a username in Linux that contains spaces. So what do I do now? Well create a group called mqexplorer on my Windows desktop, add <myuser> “Steve Robinson” to this group. then modify mqauth to allow access form anyone in this group.

Creating the new Windows sgroup

We also need to create a matching group on Linux

The purpose of these commands is:
1. Grant authority to access the qmgr
2. Grant authority to the client channel to get the command server reply messages
3. Grant authority to put messages onto the command server input queue

When we try to access we get the following error

I guess MQ Explorer (Windows) is using the first part of my Windows user name. Let’s create a Linux user called steve and set the password as steve and add to mqexplorer group and see what happens.

Ok, it is getting confused, so lets now manually tell MQ explorer to use steve

MQ Explorer cannot administer the queue manager because the user is not authorised to open the queue ‘SYSTEM.MQEXPLORER.REPLY.MODEL’. (AMQ4401)

MQ Explorer cannot administer the queue manager because the user is not authorised to open the queue ‘SYSTEM.MQEXPLORER.REPLY.MODEL’. (AMQ4401)

Severity: 10 (Warning)

Explanation: MQ Explorer uses the queue to administer this queue manager.

Response: Allow MQ Explorer to open the queue and retry.

Try again connecting from MQ Explorer on windows

OK we no successful connected, but lets try now with removing the QM named user

Summary

Basically if your user id on Windows is a non acceptable Linux format ( 8 chars), then you need to create a user on Linux and then assign setmqauth security on objects either by using principle name or group name (Linux user must be in group). Then we name the use in the Connect to QM wizard and when MQExplorer connects it uses that user.

Note: Below are the commands for setting access to MQ objects for a named user as opposed to group

setmqaut -m MYQMGR -t qmgr -p myuser +connect +inq +dsp

setmqaut -m MYQMGR -t q -n SYSTEM.DEFAULT.MODEL.QUEUE -p myuser +inq +browse +get

setmqaut -m MYQMGR -t q -n SYSTEM.ADMIN.COMMAND.QUEUE -p myuser +inq +put

There is no point in adding users to groups in Windows unless IBM WebSphere MQ is installed on windows.

As I have always mentioned in other articles WMQ security is based on users and groups and you just have to think a bit harder when it comes to remote access from a Windows client.

Using the tips and tricks above, you will see that you will find you can connect, but you will be limited in what you can administer. As I mentioned earlier you can open up security. This article was more about connecting with the least amount of access, without creating a security hole. Often in moist cases we give full access and leave it that. But when you do want to secure WMQ for MQ Explorer access, then this is a great little article to help you get ideas.

Appendix

If you are interested in a clever security exit, you can use BlockIP to lock and even audit access to a QM.

http://www.mrmq.dk/index.htm?BlockIP2.htm

Block IP

You can also use blockip open source security exit tool to secure WMQ.

Installation

Download block IP from the site mentioned below in the appendix section

Upload the appropriate version for you system. My example is Linux 64 bit

Linux (Intel 64 bit)

Just untar BLOCKIP2.TAR from Linux_x86_64 subdir in /var/mqm/exits64, and you’re almost ready to go.

cd /var/mqm/exits64

tar -xvf BlockIP2.tar

You will need to change the owner using root authority:

Alter the channel

alt chl(SYSTEM.ADMIN.SVRCONN) chltype(SVRCONN) +

scyexit(‘BlockIP2(BlockExit)’)

Example Log for access denied

cd /var/mqm/qmgrs/TEST2/errors

tail -f AMQERR01.LOG

Result:

References:

http://www.webspheretools.com/sites/webspheretools.nsf/bycategory!openview&restricttocategory=websphere%20mq&count=5000

http://www.websphereusergroup.org/middlewarenews/blog/2012/06/19/requirements_for_remote_administration_using_the_websphere_mq_explorer_-_middleware_news

http://www-01.ibm.com/support/docview.wss?uid=swg21250706