The WebSphere MQ Explorer GUI provides a user-friendly way to administer your queue managers.
With a little work, you can use it as a read-only ‘viewer’ instead. If you have some staff who don’t have authority to make changes to the WMQ network, but need them to be able to monitor what is happening, this would let them use WMQ Explorer to do it. If your staff without authority to make changes are the ones with less WebSphere MQ experience, then this might be a useful approach.
In this post I’ll walk through the steps required to set this up for a single queue manager, and highlight a couple of potential problems to watch out for.
Steps to carry out on the machine hosting the queue manager
- Create a user – making sure that the user is not a member of the mqm group
- Start a channel listener for the queue manager
- Create a server-connection (SVRCONN) channel on the queue manager – setting the MCAUSER attribute to the username defined in step 1
- Use setmqaut to specify which objects you want the user to be able to see
What permissions do you need to grant?
Firstly, you need permission to connect to the queue manager:
setmqaut -m YOUR_QUEUE_MANAGER -t qmgr -p YOUR_USER_NAME +connect +inq +dsp
Next, you need to give permission to the queues that WMQ Explorer will need:
setmqaut -m YOUR_QUEUE_MANAGER -t q -n SYSTEM.DEFAULT.MODEL.QUEUE -p YOUR_USER_NAME +get +browse +inq
setmqaut -m YOUR_QUEUE_MANAGER -t q -n SYSTEM.ADMIN.COMMAND.QUEUE -p YOUR_USER_NAME +get +browse +inq +put
setmqaut -m YOUR_QUEUE_MANAGER -t q -n SYSTEM.MQEXPLORER.REPLY.MODEL -p YOUR_USER_NAME +inq +browse +get +dsp
setmqaut -m YOUR_QUEUE_MANAGER -t q -n 'AMQ.**' -p YOUR_USER_NAME +all
setmqaut -m YOUR_QUEUE_MANAGER -t q -n 'MQAI.**' -p YOUR_USER_NAME +all
Edit (3-Mar-2009): Deleted the last two lines as they create a security hole – please see this post from T.Rob for more details on why
Then, you could give access to all objects of a certain type – such as being able to display all channels:
setmqaut -m YOUR_QUEUE_MANAGER -t channel -n '**' -p YOUR_USER_NAME +dsp
You might want to include additional permissions, such as the ability to browse messages on queues, or inquire their attributes:
setmqaut -m YOUR_QUEUE_MANAGER -t q -n '**' -p YOUR_USER_NAME +dsp +inq +browse
See the System Administration Guide section on setmqaut for more detail on the options available.
Steps to carry out on the WebSphere MQ Explorer machine
- Right-click on ‘Queue Managers’ and choose ‘Show Queue Manager’
- Click on the ‘Add’ button
- Enter the queue manager name and click ‘Next’
- Fill in the hostname of the machine hosting the queue manager, the TCP port number for the channel listener you started, and the name of the server-connection channel you created
- Click Finish
Things to watch out for
Note 1: The WebSphere MQ Explorer user will only see the objects which they have the authority to see. So it’s worth being aware that in such a setup, the Explorer is no longer showing a definitive view of the objects on the queue manager.
Note 2: Attempts to view an object which the user isn’t authorised to display can result in an authorisation event. See the Monitoring WebSphere MQ section on ‘Event Monitoring’ for more information. To summarise, if a queue manager has authorisation events (AUTHOREV) enabled, every attempt to access something which a user is not authorised to will cause an event message to be put to the SYSTEM.ADMIN.QMGR.EVENT queue. So, for example, if a user does not have access to display queues, then one authorisation event message will be put to SYSTEM.ADMIN.QMGR.EVENT for each queue they cannot access every time the Queues view in WMQ Explorer is refreshed. This could result in a lot of messages, so you may want to disable AUTHOREV or take steps to handle these messages.
Note 3: If you want to look at queues with WebSphere MQ Explorer in this way, you will need to have Refresh Pack 6.0.2.0 or greater applied. A bug in the Explorer prior to this meant that the failure to display SYSTEM.AUTH.DATA.QUEUE (a queue which it is not possible to give a non-mqm user access to) prevented any queues from being displayed. This is documented more fully in APAR IC49051.
Note 4: When I talk about the WMQ Explorer, I’m referring to the Eclipse-based Explorer that comes with WebSphere MQ version 6. I’ve not tried this on the v5.3 Windows WMQ Explorer.
Note 5: In the examples above, I’ve used the -p option for setmqaut – specifying a specific user. I’ve done this for simplicity, but in practice using -g to specify a group is often easier to manage. See the Sys Admin Guide for the full syntax.

39 comments
Comments feed for this article
February 9, 2007 at 8:34 pm
theoddissilent
Dale, this is great. Thanks! Now I can just give people a link to this post as I get asked this all the time.
Follow-on question, though…what’s the best way to get the WMQ Explorer if you don’t have the Windows install media? Is it still to download the full WMQ trial? Any thoughts on whether it will ever become available as a separate download or SupportPac?
February 11, 2007 at 11:33 am
AIXπ » links for 2007-02-10
[...] Using WebSphere MQ Explorer as a read-only viewer « a Hursley view on WebSphere MQ The WebSphere MQ Explorer GUI provides a user-friendly way to administer your queue managers. With a little work, you can use it as a read-only ‘viewer’ instead. If you have some staff who don’t have authority to make changes to the WMQ network, bu (tags: Howto MQ MQ_Explorer Hursley by:Dale_Lane) [...]
February 13, 2007 at 9:50 am
kim
Dale – quick question.. Can I set the MCAUSER to a group name (and then the mqauts granted by group??)
Thanks.
February 17, 2007 at 12:18 pm
protocol7 » Blog Archive » links for 2007-02-17
[...] Using WebSphere MQ Explorer as a read-only viewer (tags: eclipse ibm security wmq) [...]
February 19, 2007 at 1:28 pm
Dale Lane
Hi Kim – Nope, fraid not.
Dale
PS – Sorry for delay in answering – completely missed this question!
February 22, 2007 at 10:15 am
Steve W
Thanks for the info Dale, very informative.
Can you please explain what format the “YOUR_USER_NAME” field will take if a user is accessing a QM on a Linux machine from a Windows environment? Will the user have to be created on the Linux machine before they can access the QM?
February 22, 2007 at 2:20 pm
Dale Lane
If you are following all the steps in this post, then no – the user only needs to exist on the machine hosting the queue manager. This is because I put the username in the MCAUSER attribute of the channel I connect to – so it doesn’t matter who is connecting, anyone who connects to that channel is treated as that person.
If you left the MCAUSER field blank, then the username from the WMQ Explorer machine is used – so yes, you would need to be running Explorer as a user with the name which you have prepared the queue manager for with setmqaut.
Hope that helps.
Dale
February 22, 2007 at 8:22 pm
peterbroadhurst
To add to Dale’s answer, I’d say there are (at least) two distinct approaches to client validation in WMQ (from WMQ Explorer or otherwise):
1) Use the user identifier the app runs under on the client machine, and leave MCAUSER blank. In this case the userid the app runs under on the client needs to exist on the server (there’s probably room for a post on the complexities of this, especially going Windows UNIX/Linux).
2) Direct different groups of users down different SVRCONN channels, with a different MCAUSER set on each channel. This fits very well with an SSL security model – where the components of the distinguished name (DN) in the certificate can be used to categorise users, and the SSLPEER attribute of a channel can be used to enforce different user groups down different SVRCONN channels (again, reckon there’s room for a post here too).
February 27, 2007 at 2:34 pm
Dale Lane
Problems with the WordPress theme that we use on this blog means that the setmqaut commands included in this post can be truncated when displayed in some browsers.
If that is causing you a problem, zooming out can help. Otherwise, copying-and-pasting the lines to somewhere else should still work.
Sorry for the inconvenience!
Dale
March 22, 2007 at 6:17 am
Aarati
Dale — the article was extremely helpful. Thank you.
One question though – You had mentioned that if the MCAUSER is left blank, then the user passed in from the MQExplorer machine is used.
So…if I have a user mqm on a Linux machine that I run MQExplorer as, would I then have admin authority over the Queue Manager that I access ? Is that a security loophole ?
Can I use this to overcome the MQExplorer bug detailed in APAR IC49051 ? I have a 6.0.1.0 MQExplorer and I am wondering if I can get away without upgrading to 6.0.2.0…
March 22, 2007 at 9:45 am
Dale Lane
If you connect to a remote queue manager using a SVRCONN channel with a blank MCAUSER field, and you connect as a user called ‘mqm’ then yes – you would have admin authority over that queue manager (and not encounter the problems described in IC49051).
As for whether this is a security loophole – I don’t think so. WebSphere MQ provides a number of ways to secure the channels, but it is flexible enough that you can configure it a less secure way if that is appropriate for your needs.
Thanks for your comments – I’m glad the post was helpful.
Dale
May 30, 2007 at 3:28 pm
Marc
Dale,
The info above is great. I have tried to get this configuration to work, and have set all permissions as you mention above, but am still getting the error “Access not authorized. You are not authorized to perform this operation. (AMQ4036)”, when trying to connect through MQ Explorer.
Any thoughts?
I know the MQ Explorer works, as I can connect if I reset the MCAUSER to mqm, then everything is fine. So I know that I’m missing a permission somewhere, but as of yet, I can’t figure out where.
Thanks
marc
May 31, 2007 at 9:25 am
Dale Lane
The best way to start is probably to verify that all of the permissions were correctly defined – using something like this:
dspmqaut -m YOUR_QUEUE_MANAGER -t qmgr -p YOUR_USER_NAME
dspmqaut -m YOUR_QUEUE_MANAGER -t q -n SYSTEM.DEFAULT.MODEL.QUEUE -p YOUR_USER_NAME
dspmqaut -m YOUR_QUEUE_MANAGER -t q -n SYSTEM.ADMIN.COMMAND.QUEUE -p YOUR_USER_NAME
dspmqaut -m YOUR_QUEUE_MANAGER -t q -n SYSTEM.MQEXPLORER.REPLY.MODEL -p YOUR_USER_NAME
dspmqaut -m YOUR_QUEUE_MANAGER -t q -n 'AMQ.**' -p YOUR_USER_NAME
dspmqaut -m YOUR_QUEUE_MANAGER -t q -n 'MQAI.**' -p YOUR_USER_NAME
dspmqaut -m YOUR_QUEUE_MANAGER -t channel -n '**' -p YOUR_USER_NAME
dspmqaut -m YOUR_QUEUE_MANAGER -t q -n '**' -p YOUR_USER_NAME
May 31, 2007 at 2:00 pm
Marc
Dale,
Can you explain what the ‘AMQ.**’ and ‘MQAI.**’ are for? I do not have any queue definitions that begin with this, and I have searched the Admin Guide and can’t seemto find what these are for? I ahe setup the profiles, as defined above for this permission, but didn’t know what the purpose was.
thanks
marc
May 31, 2007 at 2:22 pm
Dale Lane
I added these to cover for temporary dynamic queues used by the WMQ Explorer when it makes a client connection to a remote queue manager.
For example, after connecting to a remote queue manager, if you click on “Show temporary queues” in the WMQ Explorer Queues View, you will see a queue with a name like AMQ.MQEXPLORER.620569853.
Kind regards
Dale
May 31, 2007 at 2:34 pm
Marc
That makes sense.
I am now able to connect to my QManager through MQExplorer, but when I go to queues I get an “access not authorized AM4036″ error. when I dsp the aut on all queues it is below….so am I missing something on the QM level:
$ dspmqaut -m QMNAME -t q -n ‘**’ -p myuser
Entity myuser has the following authorizations for object **:
get
browse
put
inq
set
dlt
chg
dsp
passid
passall
setid
setall
clr
thanks for your feedback. I am trying to figure out how to use MQ Explorer for a ‘end user’ tool, but must limit what they can do. I just need to get past how to set it up, and getting it to work properly.
marc
June 4, 2007 at 6:00 pm
Marc
Dale,
I have gotten the MQExplorer to work in my environment, as a read only tool. I have quickly discovered that it does NOT limit the ability to “manage authority records”, of any object. Is this a bug, or something that has a way to be limited? If it’s a read only tool, but anyone can go and change permissions to themselves, then it’s no longer a read only tool.
Any ideas?
thanks for your feecback.
June 6, 2007 at 10:57 am
Dale Lane
Marc
This is an interesting question…
It seems unlikely that the WMQ Explorer would be able to modify authority records if a user does not have access – under the covers it is just using plain PCF to send the commands, and if you don’t have access rights, then I would expect these to be rejected.
At first glance, the most likely explanations would appear to be either that your user does have permission to manage the authority records after all, or that perhaps the feedback being returned by the WMQ Explorer OAM plugin is incorrect (reporting that it has allowed you to change the permission, when in fact it was denied access to do that).
I haven’t had the chance to recreate this myself to identify which (if either) of these are the case. I will try and do this at some point, though.
Kind regards
Dale
June 7, 2007 at 8:14 pm
Marc
It is definately interesting.
I can go on my MQ server, directly, and run a dspmqaut on a queue with the -p myuser option, and get the output of ‘dsp’.
I can then go to MQExplorer, and right click on that exact same queue (including all system queues), and select
Object Authority –> Manage Authority Records.
This brings up the permissions for both mqm and ‘myuser’. I can then edit them as I choose, both the mqm user and the ‘myuser’.
I then go back to the actual MQ Server, and do a dspmqaut on the queue, and it shows the changes that were made in the MQ Explorer.
I also thought that maybe MQ Explorer plugin was incorrect, and just didn’t return the error that it was not authorized. But I was able to change authority on the queue, and then put/get/delete etc on that queue.
I’m using 6.0.22 Windows Explorer version. I can’t find anywhere that ‘myuser’ has any other authorities then the exact ones defined above and showing when a dspmqaut is done.
It’s kind of baffeling really.
Let me know if you can re-create.
Thanks
marc
June 16, 2007 at 2:50 pm
Joseph Gramig
I have tried this with a 5.3 CSD13 and 6.0.2.1 QMGRs. I cannot modify the security of 5.3 but I can create new MQ objects. I can see all other objects but have no greater rights than expected.
With 6.0.2.1, these scripts work as advertised and I could not modify any security or create any new objects. Good deal!
Now, my client asks “So how do I download and install MQ Explorer?”
Of course, my answer is “You cannot for free”. I have installed the MQ Explorer with just the MQ Client but used the DVD with the Eclipse environment and MQ Explorer. This combination prevents others from going over the license agreement for the QMGR (but I don’t know that the Explorer is licensed at all).
Anyway, sure would be nice if we could just download the MQ Explorer as an Eclipse package.
Joe
June 17, 2007 at 4:20 pm
Dale Lane
It’s an interesting point… could the WMQ Explorer be made available freely as is currently done with clients?
My involvement is purely on the technical side of things, and I have nothing to do with licensing. But if you think that there would be value in such an approach, then I would encourage you to raise this with your IBM Sales contact. I will also pass on the suggestion internally.
Thanks very much for your comments.
Kind regards
Dale
July 19, 2007 at 2:22 pm
Mandy
Hi Dale,
Firstly thanks for the detailed info in your article.
I have a question on the setmqaut command, I am not able to set permissions to give read only access for channels. I am using WMQ 5.3 CSD11 on a linux host where the qmgr exists and Explorer 5.3 on Windows XP
Mandy
July 19, 2007 at 2:24 pm
Mandy
PS : I did go through Sys Admin Guide but not able to find anything on restricting access to channels.
July 20, 2007 at 1:44 pm
Dale Lane
The WebSphere MQ System Administration Guide includes a nice table which details each of the valid permissions you can grant or revoke to a user for WMQ objects – including channels. This is probably the best place for you to start – and decide which permissions to deny (for example, I imagine you will want to remove access to delete or change the channel).
The syntax of the command will be similar to the one used in the post, just replacing +dsp with whichever permissions you want to grant or revoke (e.g. -dlt)
July 30, 2007 at 5:30 am
Using WebSphere MQ Explorer with SSL « a Hursley view on WebSphere MQ
[...] Explorer, security, administration by Dale Lane I’ve posted before about setting up WebSphere MQ Explorer as a read-only viewer using setmqaut and MCAUSER ids – a post which has proved quite useful to some [...]
August 8, 2007 at 4:29 pm
Greg
In reponse to Joseph Gramig:
[Now, my client asks “So how do I download and install MQ Explorer?”
Of course, my answer is “You cannot for free”.]
Since this is essentially security applied on the server connection channel as opposed to WMQ Explorer itself you could use other GUI tools, e.g. MMQMO71, to access your queue managers and the advantages described in the article above would still apply.
August 9, 2007 at 5:27 pm
Ryan
Hi Dale,
Thanks for the article!
I’ve followed each step you’ve outlined, but the user still can’t see any of the queues. I’ve refreshed security.
I’ve applied the setmqaut commands on the group mqr (read only). He’s connecting through a channel TEST.SVRCONN with the mcauser specified accordingly.
I have NOT executed this command:
setmqaut -m YOUR_QUEUE_MANAGER -t channel -n ‘**’ -p YOUR_USER_NAME +dsp
Is this needed for read-only?
August 13, 2007 at 9:37 am
Dale Lane
@Ryan – RE: not seeing any of the queues, have you seen “Note 3″ above? This is a known problem at some maintenance levels.
April 1, 2008 at 6:40 pm
Jim
Hi Dale,
If we have a workstation that has v6.0.2.3 of the MQ client and the Eclipse software running on it , is there a way we can copy the MQExplorer plugins and use MQExplorer on the workstation rather than installing MQExplorer on it?
April 3, 2008 at 9:07 am
Dale Lane
@Jim
Technically speaking, I imagine that it might be possible – I’m not aware of any dependencies on other plugins included in the WMQ Eclipse distribution.
I don’t know whether this would be a supported configuration if you ran into problems, though.
June 6, 2008 at 2:07 pm
tschne1
Hi Dale,
I’ve found your article to be very useful. For the record, here are steps I’ve taken to set up display only Explorer access on z/OS:
1) Define a new userid to be the MCAUSER for the SVRCONN channel that will get display only access (make sure the userid is not connected to a RACF group which has any access beyond that listed in the following bullets).
2) Grant the userid UPDATE access to the MQQUEUE class profile that controls access for each of these three queues (if these queues are currently protected by GENERIC profiles that provide access to many queues, you might need to define less GENERIC or fully qualified profiles so that access is limited to the queues listed here):
- SYSTEM.MQEXPLORER.REPLY.MODEL
- AMQ.* (the prefix of a temporary dynamic queue built from the previous queue)
- SYSTEM.COMMAND.INPUT (not sure, but the SYSTEM.ADMIN.COMMAND.QUEUE qalias might sometimes be used instead depending on the maintenance level).
3) Grant the userid READ access to the MQCMDS profiles that protect the DISPLAY commands
Regards,
Tom
August 19, 2008 at 4:23 pm
WebSphere MQ
[...] Using WebSphere MQ Explorer as a read-only viewer – Blog entry at a Hursley view on WebSphere MQ [...]
August 31, 2008 at 5:56 am
aprakao
Thanks for this tip. I followed the steps mentioned. I was successful. But my question is, when we add more queues onto MQ, those queues are not seen, until we manually go and run the setmqaut again.
How can we setup, auto refresh when the queues are added, then the queeus are seen on MQ explorer.
Any idea.
Thanks
Om
October 30, 2008 at 2:24 pm
senthildots
I am not sure if this is the right place where I can ask this question:
When I post a message to my IBM MQ queue, setting an expiry period of say 1 minute I see the message can be browsed in MQExplorer only for 1 minute and then it vanishes from MQ Explorer.
Is it possible to retain the expired messages also to be browsed through MQ Explorer?
Thanks
Senthil
November 3, 2008 at 5:41 am
usuresh80
Hi, I have a small Question, in Windows how to provide only read access to view MQ objects only for some user , both MQ explorer and Queue Manager are both running on the same server , with out adding the users to mqm group
Thx in advance
Suresh
February 28, 2009 at 3:21 am
The Deep Queue - Episode #8: The good news and the bad news
[...] of the items in the podcast suggests some corrections to scripts listed in the “Using MQ Explorer as a read-only viewer” post over at the Hursley View on WebSphere MQ blog. I have excerpted a portion of the [...]
July 26, 2011 at 5:02 am
WebSphere MQ: SYSTEM.DEFAULT.MODEL.QUEUE « The Wiert Corner – irregular stream of Wiert stuff
[...] Using WebSphere MQ Explorer as a read-only viewer [...]
January 23, 2013 at 4:00 am
Make MQ Explorer with Broker plug-in Read-only | Haiyan Business Technology Press
[...] testers and others read-only access to MQ+MB QA/Test environment. I searched and read this very good article on the same topic . However, it does not address how to provide read-only access to the broker objects within MQ [...]
February 13, 2013 at 10:41 am
WebSphere MQ: SYSTEM.DEFAULT.MODEL.QUEUE « The Wiert Corner – irregular stream of stuff
[...] Using WebSphere MQ Explorer as a read-only viewer [...]