2

I have a local MQ which my IIB connects to in client mode (i.e. not as a trusted application). I've set check client connection security on in the QM and now the IIB can't connect because it doesn't send a password and it's sending the wrong username (by default it uses the user that the process starts with). I've seen lots of documentation around setting dbparms mq::*. I could be wrong that but that only seems to affect the MQ Input and Output nodes ? Not the actual broker and it's config manager connections to MQ?

However, I've tried setting those values so that all client connection to my QMGR get a user/passwd but it still comes across as failing and I can see in the MQ logs that it's trying to connect using the userid that the IIB process was started with (and presumably without a password). So, how do I get IIB to ALWAYS send a user/passwd to MQ when connecting the node/config mgr to the QM using client connections??

Clarification: I have set mq::MQ -u -p and still the node attempts to connect to the QMGR using the ID that the MQSI process is started with and not the -u param. I have no execution groups and (of course) no flows in my broker so this can only be a core IIB component that's attempting the connection.

John H
  • 41
  • 5

2 Answers2

1

According to the IBM Integration Bus v10.0.0.10 Knowledge Center page "Connecting to a secured WebSphere MQ queue manager" you can set this in three ways:

  1. On each MQ Node by specifying a Security identity property.
  2. For all MQ connections to a named queue manager
  3. For all MQ connections.

The order of which ID will be used is the same as above, so if you have a ID setup for all queue managers, you can override it for a specific queue manager or a specific MQ Node.

If you have a queue manager you are already connecting to called for example IIBQM, you could specify the following command so that all connections to that queue manager would use the specified username and password.

mqsisetdbparms integrationNodeName -n mq::QMGR::IIBQM -u username -p password

The KC page tells how to set it all three ways. If you have any specific questions please update your question by clicking edit and add more details and I can update my answer.

JoshMc
  • 10,239
  • 2
  • 19
  • 38
  • Hi, I obviously didn't make myself clear - I have already done those changes and the broker is still attempting to connect to MQ on startup as the process owner user - not the user that I set in MQ::* - I don't think those parms work for anything other than MQ Nodes themselves - not the Broker itself?? – John H Sep 25 '17 at 10:26
  • What version of IIB? – JoshMc Sep 25 '17 at 12:21
  • 10.0.0.9 and MQ 9. – John H Sep 25 '17 at 13:05
  • Are you using "[file-based or queue-based authorization](https://www.ibm.com/support/knowledgecenter/en/SSMKHH_10.0.0/com.ibm.etools.mft.doc/bn28614_.htm)"? – JoshMc Sep 25 '17 at 15:30
1

Hurrah - I've worked this out !

Although, I had not enabled chcklocal or chckclnt MQ, the fact that I had a idpwldap authinfo set meant that MQ was going to LDAP to find out who the user was that I was logging in with (presumably so that it could check what group permissions it had). So, I had to put my local user into LDAP and set its group.

This got my broker working (with no execution groups or flows). Once I deployed my simple mqinput and MQ output node flow it failed due to authorisations using the same ID. I could then see that it was binding locally and not as a client (which i had first considered). Phew - all done. So, to review: the answer was to put the user id that the mqsi bip/bipbroker process runs under into LDAP. Then give various MQ permissions so that the broker NODE and it's MQ flow NODES could connect to MQ correctly and put/get etc.

thanks for your help - and maybe this will help someone else in the future when someone puts on MQ security and they have a local QM with IIB.

John H
  • 41
  • 5
  • If you use file based security the IIB should have no need to connect to MQ locally. If you want to use client connection for the queues that your flows put/get from then you need to specify the details like channel, hostname, port, and username and password. – JoshMc Sep 25 '17 at 16:31