0
votes

clients connecting to our Websphere MQ 7.0 Server get error code 2035.

This is because each User connects with his own username. They are not able to changes this behaviour. Fixing this as a workaround is pretty easy. I just have to add the username to the mqm group (linux) and its working.

Problem is, i cant add all users to the mqm group. This changes all the time.

Is there a way to allow everyone to connect and send data?

2
MQ 7.0 has been out of support since September 30th 2015. 7.1 is also out of support and 7.5 goes out of support in 11 days. If the users connecting to MQ are not MQ admins, adding them to the mqm group is a large security issue. Do these users connect over the network as a MQ client to a SVRCONN channel or connect local on the same server in bindings mode.JoshMc
@JoshMc - Clients do connect via the Network as an MQ client to a SVRCONN channel. Is this still a security issue then, adding them to the mqm group? They dont have access to the server besides the SVRCONN channel.sebkoe
Yes it would still be a security concern. Any user in the mqm group has administrative authority. Remotely users can define, change, delete objects on the queue manager. Roger's answer provides examples of how to provide authority to specific application queues without the need to add the users to the mqm group.JoshMc

2 Answers

0
votes

As Mark said:

If you ignore the security implications of allowing anyone to access MQ resources

I suggest you learn how to properly do MQ security as it is REALLY easy. You can use the groups the users are already in or create new groups and add just those particular UserIds to it. Please do NOT put non-MQAdmin UserIds in the 'mqm' group. Bad security, very bad security.

Lets say you have a bunch of queues that begin with 'ABC' and the support team needs full access to. You can create a group called 'abc_rw' (allow read/write) and put all UserIds that need full permission. Hence, the setmqaut commands would be:

setmqaut -m {QM_NAME} -t qmgr -g abc_rw +connect +inq +dsp
setmqaut -m {QM_NAME} -n ABC.** -t queue -g abc_rw +allmqi +dsp

where {QM_NAME} is the name of your queue manager.

The 1st line sets the permission for the group 'abc_rw' to access the queue manager. The 2nd line gives the group 'abc_rw' access to all queues that begin with 'ABC.'.

That's it. Its just that easy. Don't forget to issue the REFRESH SECURITY command after you issue any setmqaut commands.

Now if the user uses a tool that lists the queues of a queue manager then you will need to give them permission to do that. Again it is easy.

setmqaut -m {QM_NAME} -n SYSTEM.ADMIN.COMMAND.QUEUE -t queue -g abc_rw +put +inq +dsp
setmqaut -m {QM_NAME} -n SYSTEM.DEFAULT.MODEL.QUEUE -t queue -g abc_rw +get +inq +dsp

The 1st line gives the group 'abc_rw' permission to put messages to the command queue which the MQ tool does to request the list of queues. The 2nd line gives the group 'abc_rw' access to use the model queue to create a temporary dynamic queue which is where the MQ tool will read the reply messages from.

0
votes

If you ignore the security implications of allowing anyone to access MQ resources, then it is possible to give that permission via the pseudo-group "nobody". On Unix platforms, every user is considered a member of that group even if it does not really exist.

So

setmqaut -t qmgr -m QM1 -g nobody +connect

will grant permission for all users to connect. And similar things can be done with wildcards ('**') for setting permissions on queues etc.