Services: DevOps Thought Leadership | JEE Consulting
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.
Upload to server and unzip
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?
Preparing... ########################################### [100%]
1:MQSeriesJRE ########################################### [100%]
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
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.
1 : DEFINE CHANNEL(SYSTEM.ADMIN.SVRCONN) CHLTYPE(SVRCONN)
AMQ8014: WebSphere MQ channel created.
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?
AMQ9776: Channel was blocked by userid
The inbound channel 'SYSTEM.ADMIN.SVRCONN' was blocked from address '127.0.0.1'
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)'.
Contact the systems administrator, who should examine the channel
authentication records to ensure that the correct settings have been
The ALTER QMGR CHLAUTH switch is used to control whether channel
authentication records are used. The command DISPLAY CHLAUTH can be used to
query the channel authentication records.
02/05/2013 09:50:25 AM - Process(9716.12) User(mqm) Program(amqrmppa)
AMQ9999: Channel 'SYSTEM.ADMIN.SVRCONN' to host 'localhost (127.0.0.1)' ended
The channel program running under process ID 9716 for channel
'SYSTEM.ADMIN.SVRCONN' ended abnormally. The host name is 'localhost
(127.0.0.1)'; in some cases the host name cannot be determined and so is shown
Look at previous error messages for the channel program in the error logs to
determine the cause of the failure. Note that this message can be excluded
completely or suppressed by tuning the "ExcludeMessage" or "SuppressMessage"
attributes under the "QMErrorLog" stanza in qm.ini. Further information can be
found in the System Administration Guide.
----- amqrmrsa.c : 898 --------------------------------------------------------
There are several options at this point:
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
setmqaut -m TEST2 -t q -n SYSTEM.DEFAULT.MODEL.QUEUE -g mqexplorer +inq +browse +get
setmqaut -m TEST2 -t q -n SYSTEM.ADMIN.COMMAND.QUEUE -g mqexplorer +inq +put
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
AMQ5653: The user 'steve' is not defined.
The system call getpwnam("steve") failed with errno -1.
Create the user 'steve' and retry the operation.
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.
The specified entity is not authorized to access the required object. The
following requested permissions are unauthorized: inq
Ensure that the correct level of authority has been set for this entity against
the required object, or ensure that the entity is a member of a privileged
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)
Severity: 10 (Warning)
Explanation: MQ Explorer uses the queue to administer this queue manager.
Response: Allow MQ Explorer to open the queue and retry.
AMQ8077: Entity 'steve ' has insufficient authority to access object
Try again connecting from MQ Explorer on windows
OK we no successful connected, but lets try now with removing the QM named user
----- amqzfubx.c : 624 --------------------------------------------------------
02/05/2013 10:53:49 AM - Process(8945.74) User(mqm) Program(amqzlaa0)
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.
If you are interested in a clever security exit, you can use BlockIP to lock and even audit access to a QM.
You can also use blockip open source security exit tool to secure WMQ.
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.
tar -xvf BlockIP2.tar
You will need to change the owner using root authority:
Example Log for access denied
tail -f AMQERR01.LOG
AMQ9536: Channel ended by an exit.
Channel program 'SYSTEM.ADMIN.SVRCONN' was ended by exit 'BlockIP2(BlockExit)'.
----- amqrexta.c : 3297 -------------------------------------------------------
Steve Robinson has been working in IT for over 20 years and has provided solutions for many leading brands around the world. Steve specialises in JEE, DevOps and Thought Leadership.
In January 2013, I was awarded the prestigous 'IBM Champion' accolade.
IBM WebSphere Application Server 8.0 Administration Guide
WebSphere Application Server 7.0 Administration Guide
Contact | Articles | Shell Scripts | Java Code | JACL | Jython | WebSphere MQ | WebSphere Message Broker | WebSphere Blog | © Copyright 2006-2013 Robinson (UK) Limited