3

I want to create a queue manager and a queue on the WebSphere MQ server and I want to do two things 1) access the queue manager and the queue using WMQ Explorer from a client box 2) write a Java stand-alone app that runs on the client box and puts and receives message from the queue.

However I am getting authentication exceptions. Please let me know what I am doing wrong?

Linux Server Box :

I have WebSphere MQ v7.1 installed
Queue manager QM_TEST created (crtmqm, strmqm commands)
Local queue Q_TEST created (runmqsc and the define qlocal)
SVRCONN channel defined (DEFINE CHANNEL (TEST_CHANNEL) CHLTYPE (SVRCONN) TRPTYPE (TCP))
started a listener (runmqlsr -t tcp -m QM_TEST -p 1414)

Linux Client Box :

Tried to Show/Hide the queue manager using hostname, ip address, queue manager name and the channel name; However I get the following error:

Access not permitted. You are not authorized to perform this operation. (AMQ4036)
Severity: 10 (Warning)
Explanation: The queue manager security mechanism has indicated that the userid associated with this request is not authorized to access the object.

Tried to access the queue manager and the queue using the java code, highlights given below:

public void sendMail(Mail mail) { MQConnectionFactory cf = new
MQQueueConnectionFactory(); Connection conn = null; try { //config
cf.setHostName("hostname"); cf.setPort(1414);
cf.setQueueManager("QM_TEST"); cf.setChannel("TEST_CHANNEL");
cf.setTransportType(WMQConstants.WMQ_CM_CLIENT);//WMQ_CM_DIRECT_TCPIP);
WMQ_CM_CLIENT

conn = cf.createConnection(); //fails here

However I get the following error:

Error occurred :JMSWMQ2013: The security authentication was not valid that was supplied for QueueManager 'QM_TEST' with connection mode 'Client' and host name 'hostname(1414)'.

Can you help? How do I pass the security authentication information? For now, it is OK if I can disable security as well. Just need to get this working?

Let me know if I need to provide more information.

UPDATE:
I have created 'mq-user' linux user (mq-users group). CHLAUTH is enabled (default). After creating the queue manager QM_TEST (using sudo mqm) I have executed the following mqsc commands again using sudo mqm:

DEFINE QLOCAL(TEST_QUEUE)
SET AUTHREC PROFILE('TEST_QUEUE') OBJTYPE(QUEUE) PRINCIPAL('mq-user') AUTHADD(PUT,GET)
SET AUTHREC OBJTYPE(QMGR) PRINCIPAL('mq-user') AUTHADD(CONNECT)
DEFINE CHANNEL (TEST_CHANNEL) CHLTYPE (SVRCONN) TRPTYPE (TCP)
SET CHLAUTH(TEST_CHANNEL) TYPE(ADDRESSMAP) ADDRESS('xxx.xx.xxx.*') MCAUSER('mq-user')
DEFINE LISTENER (TEST_LISTENER) TRPTYPE (TCP) CONTROL (QMGR) PORT (1414)
START LISTENER (TEST_LISTENER)

I still get AMQ4036 access not permitted error. Mind you, I access the Queue Manager and Queue from a third remote machine (client machine) logged in as a third user. However I realize I can pass 'mq-user' credentials. I wish there was a clear step by step instructions somewhere, WebShere MQ 71. infocenter is not clear enough for me.

What is still missing here?

arrehman
  • 1,322
  • 6
  • 31
  • 42

2 Answers2

7

With v7.1 of WMQ the queue manager will by default not allow administrative connections. So if the ID that you are using is mqm or if it is in the mqm group on the MQ server, it won't have access. The easy (read: NOT SECURE) way to address this is to delete the CHLAUTH record which contains the rule. IBM has published a TechNote about this here.

A longer-term and better solution is to keep the CHLAUTH record that disallows administrative access and instead connect using a different user ID. Of course, that ID will need to exist in the MQ server and be in a group that is authorized. For more on that topic, take a look at the slides and webinar recording here.

When you are ready to turn security back on, you can find plenty of information on what setmqaut commands to use at t-rob.net where I've archived the security presentations and labs from the IMPACT and European WSTC conferences.

T.Rob
  • 31,522
  • 9
  • 59
  • 103
  • Thank you so much Rob. I turned off the CHLAUTH (for now) and I was able to access the queue manager (and queue) via the MQ Explorer and also was able to put a message into it via a java app from the client machine. – arrehman Jan 16 '12 at 22:37
  • I would like to keep the CHLAUTH ENABLE as recommended. I can create a different user id. I guess this should not be part of mqm group? What do you mean by group that is authorized? What is the best practice? Create a 'mq_user' user and assign permissions to for that user to the queue manager and relevant queue objects within it? Also how do I pass this ID using JMS? Do you have an article or sample application for this? – arrehman Jan 16 '12 at 22:40
  • 1
    Yes, any ID that is in the mqm group will have full admin access. WMQ authorizes by group, not by ID (except Windows). For example, you issue `setmqaut` with the -p option on Linux. WMQ looks up the primary group of that ID and attaches the access control to that *group*, not the ID. This can lead to unexpected results so I always advise DO NOT USE the -p option! To pass an ID using JMS just specify it on the connection factory `cf.createConnection("id", "passwd")` and be aware *the password is not checked*. See the Hardening WebSphere MQ Security presentation p#10 at http://t-rob.net/links – T.Rob Jan 16 '12 at 23:54
  • I created a second QM, i disabled the CHLAUTH using ALTER QMGR CHLAUTH(DISABLED) But I am getting the same security errors. I thought this is what I did to the first queue that made it working. – arrehman Jan 18 '12 at 15:23
  • Did you enable authorization events and install SupportPac MS0P in your WMQ Explorer? If so you can look at the event messages and they will tell you which API call failed, the ID that was in use, the object the call failed on, etc. I suspect that you are connecting with a low-privileged ID and that you need to run the setmqaut commands on the new QMgr to to authorize the group. – T.Rob Jan 18 '12 at 17:03
  • Rob, Isn't that what I did with "SET AUTHREC OBJTYPE(QMGR) PRINCIPAL('mq-user') AUTHADD(CONNECT)", is this not sufficient? – arrehman Jan 19 '12 at 14:57
  • As for accessing the queues by turning of security, I am OK now. That is working. Struggling with getting the security back on and getting the connectivity working – arrehman Jan 19 '12 at 17:29
  • When granting access, always use group, not principal. Also, Java/JMS apps need connect and inquire on the QMgr, plus whatever put, get, browse, etc. on objects. The Java/JMS classes follow all of IBM's programming advice so they need inquire on the QMgr and all objects. That's how they know where the DLQ is, backout queue names and thresholds, etc. So connect on the QMgr, put, get, browse on objects as appropriate and inquire on everything. – T.Rob Jan 19 '12 at 19:54
  • Rod, thank you! I have this working finally. I was missing MCAUSER('mq-user' in the DEFINE CHANNEL command. Per the documentation I can pass principal as well. Two questions: 1) I am able to access these queues from java client *without* passing the userID, why? 2) Does access via MQ Explorer needs special treatment? (Getting access error on SYSTEM.MQEXPLORER.REPLYMODEL AMQ4401). Anyways thanks a lot for being there to help me. – arrehman Jan 20 '12 at 20:51
  • Although the docs show the -p option to authorize a user what actually happens is that WMQ looks up the user's **primary** group and authorizes that. Many people have accidentally authorized "staff" or "users" because of that. The WMQ client will pick up the user ID of the process that runs it and pass that unless it is overridden. That's OK for ordinary users with few rights but not for admins. Explorer uses model queues. Those require +dsp to work. Add +dsp and you should be OK. – T.Rob Jan 20 '12 at 21:40
  • Thank you, it works, security is enabled now. All queues are visible on MQ Explorer as well. – arrehman Feb 22 '12 at 19:51
  • Great! I'm so glad you got it working. Thanks for letting me know! – T.Rob Feb 23 '12 at 05:58
2

T. Rob is 100% correct. However, don't misread this as you can leave the security off. There is a reason why IBM designed V7.1 to have this type of rigor on security. They are proactively addressing legislative and industry guidelines for PCI-DSS. Kudos to IBM.

Maryellen Evans
  • 21
  • 2