buckrodger
asked on
MQ logging
I'm an MQ newb. I'm trying to connect from WAS7 JMS. I use JNDI to get the QueueConnectionFactory then call createQueueConnection. When I make this call I get a JMSException caused by
JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED')
I would like to see the credentials being passed to MQ, does MQ log failed connection attempts ? Is there a way to see why this connection is failing ?
thanks very much
JMSCMQ0001: WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2035' ('MQRC_NOT_AUTHORIZED')
I would like to see the credentials being passed to MQ, does MQ log failed connection attempts ? Is there a way to see why this connection is failing ?
thanks very much
ASKER
We did upgrade WAS from 6.1 to 7. And this all worked on 6.1. In my local env WAS and MQ are on different machines. In the test env WAS and MQ are on the same machine. I don't think its a password thing because if I specify the same username and password on the createQueueConnection call it works fine. However if I let WAS pass the credentials it fails.
So what version of MQ is being used? 6.0, I presume.
ASKER
6.0.2.6
Here's something that I just learned:
changes were done to the MQ JMS V7 client to provide to the MQ server the userid of the process (application) that is talking with the MQ server via the MQ JMS client.
In this case, the MQ queue manager has received a username which either:
- Does not exist in the Unix host of the MQ queue manager,
- Does exist, but it does not have the proper authority to access the MQ queue manager.
Solution
Check which user ID the application is being run under and then check to see if that user ID is in the mqm group (or some other group with sufficient authority).
If it is not in the mqm group, then add it to the mqm group and issue a runmqsc command:
REFRESH SECURITY(*)
The user ID associated with the program when it runs must have authority to access certain resources of the queue manager. Grant the following authorities to the user ID:
- The authority to connect to the queue manager, and the authority to inquireon the attributes of the queue manager object
- The authority to put and get messages on the desired queue.
.
b) In case that it is not obvious which is the actual userid token that is received by the MQ queue manager from the MQ JMS client, then it is necessary to take a trace of the queue manager (and if possible, a trace of the MQ JMS client).
The tokens to look for in the traces are:
+ From the JMS Trace (trace.log) you can see the userid that is sent by the MQ Client
For example, the trace.log for the JMS client may have strings such as these:
com.ibm.mq.jms.MQQueueConn ectionFact ory connecting as user: JohnDoe
com.ibm.mq.jms.MQQueueConn ection Setting username = JohnDoe
com.ibm.mq.MQv6InternalCom munication s userID = 'JohnDoe '
com.ibm.mq.MQv6InternalCom munication s UID :JOHNDOE
+ From the MQ server trace you can see the userid that is received by the queue manager
It is very likely that one of the MQ trace files (*.FMT) will have the following string indicating that the value (username) is not a user ID in the system or that it does not belong to the mqm group (unknown principal). Search for the string: UnknownPrincipal
UnknownPrincipal(johndoe)
Also, in case that the userid does exist, another possible cause is that the user does not have all the proper authorizations, thus, check for the following phrase in the trace:
The following requested permissions are unauthorized:
I hope that this helps!
changes were done to the MQ JMS V7 client to provide to the MQ server the userid of the process (application) that is talking with the MQ server via the MQ JMS client.
In this case, the MQ queue manager has received a username which either:
- Does not exist in the Unix host of the MQ queue manager,
- Does exist, but it does not have the proper authority to access the MQ queue manager.
Solution
Check which user ID the application is being run under and then check to see if that user ID is in the mqm group (or some other group with sufficient authority).
If it is not in the mqm group, then add it to the mqm group and issue a runmqsc command:
REFRESH SECURITY(*)
The user ID associated with the program when it runs must have authority to access certain resources of the queue manager. Grant the following authorities to the user ID:
- The authority to connect to the queue manager, and the authority to inquireon the attributes of the queue manager object
- The authority to put and get messages on the desired queue.
.
b) In case that it is not obvious which is the actual userid token that is received by the MQ queue manager from the MQ JMS client, then it is necessary to take a trace of the queue manager (and if possible, a trace of the MQ JMS client).
The tokens to look for in the traces are:
+ From the JMS Trace (trace.log) you can see the userid that is sent by the MQ Client
For example, the trace.log for the JMS client may have strings such as these:
com.ibm.mq.jms.MQQueueConn
com.ibm.mq.jms.MQQueueConn
com.ibm.mq.MQv6InternalCom
com.ibm.mq.MQv6InternalCom
+ From the MQ server trace you can see the userid that is received by the queue manager
It is very likely that one of the MQ trace files (*.FMT) will have the following string indicating that the value (username) is not a user ID in the system or that it does not belong to the mqm group (unknown principal). Search for the string: UnknownPrincipal
UnknownPrincipal(johndoe)
Also, in case that the userid does exist, another possible cause is that the user does not have all the proper authorizations, thus, check for the following phrase in the trace:
The following requested permissions are unauthorized:
I hope that this helps!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for your help
Glad to have been able to help.
Thanks for the grade & points.
Good luck & have a great day.
Thanks for the grade & points.
Good luck & have a great day.
Information about "API Completion and reason codes" can be found here:
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqsao.doc/csq0519.htm
Information about "Security consideration" can be found here:
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.amqtac.doc/wq10400_.htm
Is this a new installation, or did you upgrade your MQ and/or WSAS recently?
Did it ever work?
Are they (MQ & WSAS) on the same, or different machines?
Searching for MQRC_NOT_AUTHORIZED, we find:
--------------------------
MQRC_NOT_AUTHORIZED
public final static int
Reason code - queue is not authorized for access.
--------------------------
Information about "Log defaults" can be found here:
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.amqzag.doc/fa12570_.htm
Hopefully this helps.
Let me know.