WebSphere MQ 7.1 Help Need - Access or Security

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?

回答1:

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.

回答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.