Question

Now I use the websphere MQ client connect to remote MQ Server(7.0 version) using c#, and occurs a problem of authority,Which is the user running the MQ client application have insufficient authority to access qmgr.Then I use the ‘setmqaut’ command to grand the user sufficient authority and it works.

I think it’s not very convenient and must be a better way.May via adding user’s IP in MQ Server? But I have no idea how to do it.

Any suggestions would be greatly appreciated.
Thanks

Answer 1

WebSphere MQ does not perform any authentication. Local applications are authenticated by the operating system and so their ID can be trusted. (By definition, if you cannot trust the local OS authentication then the entire server is compromised.) Just as with local connections, WMQ trusts that the ID connecting remotely is genuine. It is up to the WMQ administrator to determine what level of authentication to employ. In WMQ v7 there are two choices – authenticate with SSL/TLS channels, or use a channel exit to authenticate.

In either case, it is the channel’s MCAUSER value that decides what ID is used for authorization. If the MCAUSER is left blank then the channel will use the user ID that the client sends. In your case you received a 2035 error because the client sent an ID that was not in the administrative (mqm) group. Had your client sent the ID ‘mqm’ (or on Windows ‘MUSR_MQADMIN’), the connection would have succeeded. If your program is Java or JMS, the ability to select the ID presented is part of the API. Just tell the QMgr who you want to be.

If you are willing to allow remote connections to execute OS commands on the server, then just put the administrative ID in the channel’s MCAUSER. (For example, MCAUSER(‘mqm’) on UNIX/Linux or typically MCAUSER(‘MUSR_MQADMIN’) for Windows.) However, be aware that remote users with admin rights can remotely execute arbitrary OS command-line code using the QMgr. This is a feature of WMQ and not a bug, hence we NEVER recommend this in Production. In fact, I personally recommend that development environments enable security. Waiting until Production to figure out how to authenticate connections and what authorizations are needed often leads to unnecessary deployment delays.

If you want to use IP filtering to mitigate that threat, you can either move to WMQ v7.1 which includes this feature natively, or use an exit such as BlockIP2. Either of these solutions will allow you to create rules that filter incoming connection requests by IP address, user ID, etc.

Note that on a v7.0 QMgr all the channels are unprotected by default. So even if you filter incoming requests on one channel, if the others are left in their default state, anyone can still connect and execute commands as the administrator. For a comprehensive review of all this, please take a look at the Hardening WebSphere MQ presentation at t-rob.net. Scroll down to the v7.0 presentations.