WebSphere MQ 7.1 help - access or security

Question

I want to create a queue manager and queue on a WebSphere MQ server, and I want to do two things 1) access the queue and queue manager using WMQ Explorer from the client window 2) write a stand-alone Java application that starts in the client window and places and receives message from the queue.

However, I get exceptions for authentication. Please let me know what I am doing wrong?

Linux server box:

I have installed WebSphere MQ v7.1
QM_TEST queue QM_TEST created ( crtmqm , strmqm commands)
A local Q_TEST queue has been Q_TEST ( runmqsc and define qlocal )
The channel SVRCONN ( DEFINE CHANNEL (TEST_CHANNEL) CHLTYPE (SVRCONN) TRPTYPE (TCP) ) is DEFINE CHANNEL (TEST_CHANNEL) CHLTYPE (SVRCONN) TRPTYPE (TCP)
the listener started ( runmqlsr -t tcp -m QM_TEST -p 1414 )

Linux Client Box:

I tried to show / hide the queue manager with the host name, ip address, queue manager name and 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 queues using Java code, underlined 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:

An error occurred: JMSWMQ2013: Security authentication is not valid which was provided for QueueManager 'QM_TEST' with the connection mode "Client" and the host name "hostname (1414)".

You can help? How to pass security authentication information? For now, this is normal if I can disable security. Just need to make it work?

Let me know if I need to provide more information.

---

UPDATE:
I created the user "mq-user" linux (user group mq-users). CHLAUTH is enabled (default). After creating the QM_TEST queue manager (using sudo mqm), I again ran the following mqsc commands 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 to an invalid error. Keep in mind that I am referring to the queue and queue manager from a third remote computer (client computer) registered as a third user. However, I understand that I can pass the credentials to "mq-user". I'm sorry that there are no clear step-by-step instructions, WebShere MQ 71. The info center is not enough for me.

What is still missing here?

Answer 1

With v7.1 WMQ, the default queue manager does not allow administrative connections. Therefore, if the identifier you are using is mqm or if it is in the mqm group on the MQ server, it will not have access. An easy (readable: NOT SAFE) way to address this is to delete the CHLAUTH record containing the rule. IBM has published TechNote about it here .

The long-term and best solution is to keep a CHLAUTH record that denies administrative access, and instead connect using a different user ID. Of course, this identifier must exist on the MQ server and be in the group that is authorized. For more information on this topic, see the slides and webinar recording here .

When you are ready to turn protection back on, you can find a lot of information about which setmqaut commands setmqaut use in t-rob.net where I archived presentations and security laboratories at IMPACT and European WSTC conferences.

Answer 2

T. Rob is 100% right. However, make no mistake, as you can disable protection. There is a reason IBM developed V7.1 to provide this level of security rigor. They actively address legislative and industry recommendations for PCI-DSS. Kudos to IBM.