Creating and Configuring Websphere MQ for Oracle SOA MQ Series Adapter
I created a queue manager named 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')
However, I could see below error in the 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.
source to share
Two problems are obvious.
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 a specific channel does not match the profile names in the CHLAUTH rules? These rules cannot be applied to a specific channel.
The second problem is that the user id oracle
has no authority to connect to QMgr. Typically, you want to provide +connect +inq
in QMgr itself and then provide +put +get +browse +inq
in queues. If you want to be more specific, highlight +put +inq
in one queue and +get +browse +inq
on the other.
Note that you always need to provide +inq
for Java or JMS applications because IBM classes ask for the objects to which they connect or open. For example, when connecting to MQ, they ask for the version and if DLQ is specified. When connected to a queue, they look for things like MAXMSGL
and BOQNAME
.
Thus, you may or may not need +inq
to depending on what the application is written and how it is coded. You may also need other permissions such as +passid
. The best way to work with required permissions is to install SupportPac MS0P in MQ Explorer and then enable authorization events. If another authorization error occurs, the event message will tell you the object against which the call was invoked, the id of the identity request, the API call at the moment, and the exact parameters specified for the call. All of this will be in human-readable language and accessible through the MQ Explorer, so you don't have to search for error log entries every time.
Finally, since the IBM docs and most of the random advice you get on the internet are wrong, make sure you understand what happens when you authorize Principal versus group.
In all versions of MQ prior to v8.0 and by default in 8.0, on startup setmqaut
or SET AUTHREC
against the MQ principal, it exits and looks at the main group for that id and replaces that in resolution. When the primary group ID is not expected, it can lead to unexpected resolution of a large number of accounts. Typically, grant permissions to groups instead of members.
There are two narrow exceptions. First, in MQ v8.0, you can configure MQ to authenticate directly against members. The problem is that a script full of authorization permissions on principals will succeed with no warnings regardless of whether this config option was set. The only way to know how it works is to dump the resulting authorization records and align with the original script. If you are not ready to do this, do not allow default authorization on platforms other than Windows.
Windows has always been an exception in that MQ writes the authorization permission to the Windows SID, or "SID," and the SID for an account is functionally equivalent to one for a group. The problem occurs if the identifier used in authorization resolution is unqualified.
For example, on QMgr Windows, if I have to execute this command ... SET AUTHREC OBJTYPE(QMGR) PRINCIPAL('oracle') AUTHADD(CONNECT)
... then Windows will try to first resolve the account oracle
against the local SAM database and then with the domain controllers it knows about, in whatever search order they are in are now.
So, suppose the ID is defined on the last of the 5 domain controllers that Windows is looking for, and that someone creates a new account named oracle
on one of the domain controllers earlier in the search chain. MCAUSER(oracle)
in the channel will be resolved to a different account with a different SID. The connection will fail Entity 'oracle' has insufficient authority to access object 'QM_MQ_TEST'
, even though you can display auiths records where " oracle
" is explicitly provided.
So, if you ever decide to grant access to a Principal and not a group, make sure that QMgr v8.0 is installed in honor of that either on the Windows for which you specified oracle@[host name here]
for the local account or oracle@[domain name here]
for the domain account as in the authorization command , and in MCAUSER
.
source to share
Do you have an "oracle" user available on the server running qmgr? If so, add permissions for this user. You may need other permissions for the adapter to work (for example, put or receive a specific queue). This will be reported in the qmgr log.
SET AUTHREC OBJTYPE (QMGR) PRINCIPAL ('oracle') AUTHADD (CONNECT)
source to share