IBM App Connect Enterprise default queue manger

Question

I've gone through this part of the official documentation of the IBM App Connect Enterprise but I can't still figure out how an integration node communicates with the default associated IBM MQ queue manager. It is obvious that the connection is locally bound (when on the same machine) but I can't figure out the following,

1. What channel does IBM App Connect Enterprise use to connect to the associated queue manager?
2. Which userid is used to connect?
3. Since the connection is locally bound, does the authentication not happen?
4. This page states "You cannot use a secured queue manager as the local default queue manager for an integration node or an integration server", what does it mean by a secured queue manager?
5. How can I verify that the given queue manager is successfully associated with the node? How can I test?

Goal: Associate a local default queue manager with an integration node without disabling channel authentication and in a secure way.

Answer 1

Below is the response to each of your points.

1. You can connect to MQ in binding mode or client mode. Find a link for binding mode and IBM link on types of connectivity. Binding mode is when your client is locally installed on the MQ server. If your client is remote, it has to use client connection by installing MQ client libraries locally on the client machine.

• What is meant by binding mode in WebSphere MQ?

• https://www.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q031720_.html

2. The user id to connect to MQ is the service account used to run IBM ACE which is the client application in this case.

3. IBM MQ can be configured to authenticate local connections as well. You can turn it on by setting CHCKLOCL to REQUIRED or REQDADM. This means that you cannot locally administer the queue manager by using runmqsc (error AMQ8135: Not authorized) unless the user specifies the -u UserId parameter on the runmqsc command line. With that set, runmqsc prompts for the user's password at the console. Similarly, a user running IBM® MQ Explorer on the local system will see error AMQ4036 when attempting to connect to the queue manager. To specify a user name and password, right-click the local queue manager object and select Connection Details > Properties... from the menu. In the Userid section, enter the user name and password to be used, then click OK. More details in the following link : http://ibm.com/support/knowledgecenter/en/SSFKSJ_9.0.0/com.ibm.mq.sec.doc/q113250_.html

4. Secured queue manager(QM) is where you don't allow connections to connect without the right authentication/authorization. Ideally, Queue manager created to get certain IBM ACE features should be used and limited to IBM ACE only. QM should be associated with the node.

5. You can run the following IBM IIB/ACE command to see the output with the queue manager name if associated :

    C:\Program Files\IBM\ACE\11.0.0.9>mqsilist -a 
    BIP1285I: Integration node 'ACE11_NODE' on queue manager 'QM11' is stopped.
   

In this case, assuming IBM ACE and QM are running on the same server, you can achieve the goal in two ways :

1. As a good principle, use this queue manager only for IBM ACE internal node's purposes. To protect Queue manager, don't define any svrconn channels on the queue manager. This way no remote client will be able to connect to the queue manager.

2. You can enable LDAP auth check(AUTHTYPE(IDPWLDAP)) on the queue manager. And then set the following parameters to CHCKLOCL(NONE) and CHCKCLNT(REQUIRED). Here all the clients would be forced to propagate a user/pass. https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.2.0/com.ibm.mq.sec.doc/q113250_.html

Answer 2

ACE connects to the default QM in bindings mode, so no channel is needed.

It will connect as the user running your ACE node.

Usually the user running the ACE node is made a member of the mqm group, so it has full access to the default QM. So for example, if you disable mqm access to the QM via bindings using connauth, that will cause problems, but I believe you can still secure the QM, you just need to grant the exact permissions the ACE user will need, if it’s not made member of mqm.

You can test it with a flow using an MQ input or output configured to use the default QM. Or a flow using a feature dependent on the default QM like a collector node.

Answer 3

There are 2 ways for an MQ client application to connect to a queue manager:

• If the MQ client application is running on the same server as the queue manager then it can connect in 'bindings' mode. The connection to the queue manager uses IPC - no network. There is no channel or channel authentication performed and the UserId used for the connection is the UserId that the MQ client application is running under.

• When the MQ client application is remote to the queue manager (not on the same server) then the only option is to use 'client' mode. For a client mode connection, the application must specify the channel name, remote host name and port # of the queue manager. The MQ client application should also be supplying the UserId and Password for authentication.