Creating and Configuring Websphere MQ for Oracle SOA MQ Series Adapter

Question

I've created a Queue manager called QM_MQ_TEST

crtmqm QM_MQ_TEST
strmqm  QM_MQ_TEST
runmqsc QM_MQ_TEST

DEFINE CHANNEL(QM_MQ_TEST) CHLTYPE(SVRCONN)

define listener(TCP.LISTENER) trptype(tcp) control(qmgr) port(1414)

ALTER AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(NONE)

SET CHLAUTH(QM_MQ_TEST_SVRCONN) TYPE(ADDRESSMAP) ADDRESS(*) USERSRC(CHANNEL)
SET CHLAUTH(QM_MQ_TEST_SVRCONN) TYPE(BLOCKUSER) USERLIST('nobody')

Still I could see below error in QM logs.

06/11/2015 12:19:26 PM - Process(10886.618) User(mqm) Program(amqzlaa0)
                    Host(abcd.com) Installation(Installation1)
                    VRMF(8.0.0.2) QMgr(QM_MQ_TEST)

AMQ8077: Entity 'oracle' has insufficient authority to access object
'QM_MQ_TEST'.

EXPLANATION:
The specified entity is not authorized to access the required object. The
following requested permissions are unauthorized: connect
ACTION:
Ensure that the correct level of authority has been set for this entity against
the required object, or ensure that the entity is a member of a privileged
group.
----- amqzfubx.c : 670 --------------------------------------------------------
06/11/2015 12:19:26 PM - Process(11046.643) User(mqm) Program(amqrmppa)
                    Host(abcd.com) Installation(Installation1)
                    VRMF(8.0.0.2) QMgr(QM_MQ_TEST)

AMQ9557: Queue Manager User ID initialization failed for 'oracle'.

EXPLANATION:
The call to initialize the User ID 'oracle' failed with CompCode 2 and Reason
2035.
ACTION:
Correct the error and try again.

Answer 1

Do you have "oracle" user available on the server where qmgr is running? If it is, add the connect authority for that user. You may need other authorities for the adapter to work (for example put or get on a specific queue). This will be reported in the qmgr log.

SET AUTHREC OBJTYPE(QMGR) PRINCIPAL('oracle') AUTHADD(CONNECT)

Answer 2

There are two problems evident.

DEFINE CHANNEL(QM_MQ_TEST)         CHLTYPE(SVRCONN)
SET    CHLAUTH(QM_MQ_TEST_SVRCONN) TYPE(ADDRESSMAP) ADDRESS(*) USERSRC(CHANNEL)
SET    CHLAUTH(QM_MQ_TEST_SVRCONN) TYPE(BLOCKUSER) USERLIST('nobody')
                         ^^^^^^^^

Notice how the name of the defined channel doesn't match the profile names in the CHLAUTH rules? These rules cannot possibly apply to the channel that was defined.

The second problem is that the user ID oracle has no authority to connect to the QMgr. Generally you want to grant +connect +inq on the QMgr itself, then grant +put +get +browse +inq on the queues. If you want to be more precise, grant +put +inq on one queue and +get +browse +inq on the other.

Note that you always have to grant +inq for Java or JMS applications because IBM's classes make inquiries on the objects to which they connect or open. For example, on connecting to MQ they inquire as to the version and if a DLQ is specified. On connecting to a queue they look for things like MAXMSGL and BOQNAME.

So you may or may not need +inq depending on what the application is written in and how it is coded. You may also need other permissions such as +passid. The best way to work through the required permissions is to install SupportPac MS0P into MQ Explorer, then enable Authorization Events. If another authorization error occurs, the event message will tell you the object against which the call failed, the ID requesting access, the API call being made at the time, and the exact options specified for the call. All of this will be in human-readable language and accessible through MQ Explorer so you don't have to go hunt down error log entries each time.

Finally, since IBM's docs and much of the casual advice you get on the Internet gets it wrong, make sure you understand what happens when you authorize a Principal versus a Group.

On all versions of MQ prior to v8.0, and by default in v8.0, when you run a setmqaut or SET AUTHREC against a principal, MQ goes out and looks up the primary group for that ID and substitutes that in the permission grant. When the ID's primary group is not what was expected, this can lead to unexpected authorization of large populations of accounts. As a rule, grant authorizations on groups instead of principals.

There are two narrow exceptions to this. The first is that in MQ v8.0 it is possible to configure MQ to authorize directly against principals. The problem with this is that a script full of authorization grants on principals will succeed without warnings regardless of whether that configuration setting has been made. The only way to know it worked is to dump the resulting authorization records and reconcile against the original script. If you are not prepared to do this, avoid granting auths by principal on non-Windows platforms.

Windows has always been an exception because MQ records the authorization grant against a Windows Security ID or "SID" and the SID for an account is functionally equivalent to one for a group. The problem comes in if the ID used in the authorization grant is unqualified.

For example, on a Windows QMgr if I were to execute this command...
SET AUTHREC OBJTYPE(QMGR) PRINCIPAL('oracle') AUTHADD(CONNECT)
...then Windows would attempt to resolve the account oracle first against the local SAM database, then against the domain controllers it knows about in whatever search order they happen to be in at the moment.

So assume the ID is defined on the last of 5 domain controllers that Windows searches and that someone creates a new account called oracle on one of the DCs earlier in the search chain. The MCAUSER(oracle) in the channel will resolve to a different account with a different SID. The connection will fail with an error that Entity 'oracle' has insufficient authority to access object 'QM_MQ_TEST' despite your being able to display auiths records in which "oracle" is clearly granted access.

So if you ever do decide to grant access on the Principal instead of the Group, make sure that the v8.0 QMgr is set to honor that, or on Windows that you specify oracle@[host name here] for a local account or oracle@[domain name here] for a domain account both in the authorization command and in the MCAUSER.