Author |
Message
|
shahs |
Posted: Tue May 20, 2008 11:44 pm Post subject: Authorization error after installing MQ ver 6.0.2.3 |
|
|
Novice
Joined: 28 Mar 2008 Posts: 15
|
Hi All,
We migrated MQ from mq 5.3 to MQ 6.0.2.3 on a Windows box.It has MQ workflow 3.6 also installed.
There is an Linux server and MQ on that server has also been upgraded to 6.0.2.3.
However an application running on the Windows box when tries to connect to one of the queues on the Linux server we get the follwoing error :
avax.jms.JMSSecurityException: MQJMS2013: invalid security authentication supplied for MQQueueManager
at com.ibm.mq.jms.MQConnection.createQM(MQConnection.java:2489)
at com.ibm.mq.jms.MQConnection.createQMNonXA(MQConnection.java:1899)
at com.ibm.mq.jms.MQQueueConnection.<init>(MQQueueConnection.java:176)
at com.ibm.mq.jms.MQQueueConnectionFactory.createQueueConnection(MQQueueConnectionFactory.java:196)
at com.ibm.mq.jms.MQQueueConnectionFactory.createQueueConnection(MQQueueConnectionFactory.java:114)
at com.jxs.jms.TempMQFactory.open(TempMQFactory.java:62)
at com.jxs.jms.TempMQFactory.buildMQObjects(TempMQFactory.java:107)
at com.jxs.jms.TempMQFactory.<init>(TempMQFactory.java:53)
at com.jxs.jms.UpesQueueWorker.retrieveMessages(UpesQueueWorker.java:67)
at com.jxs.jms.UpesQueueWorker.run(UpesQueueWorker.java:55)
at java.lang.Thread.run(Thread.java:570)
---- Begin backtrace for Nested Throwables
com.ibm.mq.MQException: MQJE001: An MQException occurred: Completion Code 2, Reason 2035
Nothing on the application side can be changed because the code works fine in the other environments.
I have checked the authorities using the dspmqaut commands and everything seems to be fine.
Are there any other MQ checks I need to make to get this problem resolved.
Thanks,
Shahs |
|
Back to top |
|
 |
KramJ |
Posted: Wed May 21, 2008 5:25 am Post subject: |
|
|
Voyager
Joined: 09 Jan 2006 Posts: 80 Location: Atlanta
|
Turn on security events on your queue manager and look at the events that are created. It will give you a better idea of what's causing the 2035 return code. |
|
Back to top |
|
 |
shahs |
Posted: Wed May 21, 2008 11:56 pm Post subject: |
|
|
Novice
Joined: 28 Mar 2008 Posts: 15
|
I have enabled the security events for the qmanager by having the AUTHOREV property of the Qmgr ENABLED.
Is that the only thing I have to do to enable security ..?
There are messages I can see in the SYSTEM.ADMIN.QMGR.EVENT queue but they are not in the readable format.
How do I debug/read this message ...? |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu May 22, 2008 12:04 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
You should probably also review the Using Java manual as client connections work a tiny bit differently in 6.0
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
Vitor |
Posted: Thu May 22, 2008 12:09 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
shahs wrote: |
I have enabled the security events for the qmanager by having the AUTHOREV property of the Qmgr ENABLED.
Is that the only thing I have to do to enable security ..? |
That doesn't enable security, it enables events. You want to disable them as soon as you've fixed your problem or the queue will fill.
shahs wrote: |
There are messages I can see in the SYSTEM.ADMIN.QMGR.EVENT queue but they are not in the readable format.
How do I debug/read this message ...? |
Using the Event Message Format provided in the documentation.
 _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
shahs |
Posted: Thu May 22, 2008 3:28 am Post subject: |
|
|
Novice
Joined: 28 Mar 2008 Posts: 15
|
fjb_saper wrote: |
You should probably also review the Using Java manual as client connections work a tiny bit differently in 6.0
Enjoy  |
In our case the application connects to a queue manager in binding mode.
Anything specific I need to look into in this case ...?
But the messages in the event queue shows the application as Websphere MQ Client for java and it gives the id which is connecting.
The id has all the required access to the channel and the queue it is accessing.
Is there any other way to enable security so that we can get some more information on the authorization issue we are facing?
Thanks,
Shahs |
|
Back to top |
|
 |
Vitor |
Posted: Thu May 22, 2008 3:52 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
shahs wrote: |
Is there any other way to enable security so that we can get some more information on the authorization issue we are facing?
|
Security events provide the greatest level of information. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
KramJ |
Posted: Thu May 22, 2008 8:56 am Post subject: |
|
|
Voyager
Joined: 09 Jan 2006 Posts: 80 Location: Atlanta
|
You can use MQ Explorer to view the events in an easily readable format. Right-click on the queue manager. Go to format events and click 'Event Messages..." Or post one of the event messages so we can look at it. Something like this maybe:
Thu May 22 10:53:15 2008
Queue Manager event: CompCode(WARNING)
Reason = MQRC_NOT_AUTHORIZED
parameter count is 4
MQCA_Q_MGR_NAME <QMGR>
MQIACF_REASON_QUALIFIER 4 (X'4')
MQIACF_COMMAND 13 (X'D')
MQCACF_USER_IDENTIFIER userID
Also, have you refreshed security since putting the user in the appropriate group? |
|
Back to top |
|
 |
shahs |
Posted: Fri May 23, 2008 2:51 am Post subject: |
|
|
Novice
Joined: 28 Mar 2008 Posts: 15
|
This problem is now resolved but I fail to understand how it worked.
Here is what I did:
Since the application on Windows box was failing to connect to the Linux server I modified the the SYSTEM.DEF.SVRCONN channel on the Linux box.
I changed the MCAUSER property to include the mqm group.
I set the MQSERVER property on the Windows box and it worked.
But what is suprising is that we did a similar migration on our Test environment and I did not have to make any changes .
The SYSYEM.DEF.SVRCONN channel on Linux does not have the MCAUSER property set to 'mqm' and the application is working fine.
The same application throws error while connecting in our Model environment but works fine in Test..?
Any pointers to why it is behaving differently in the 2 environments..?
Thanks in adavnce,
Shahs |
|
Back to top |
|
 |
Vitor |
Posted: Fri May 23, 2008 3:06 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
shahs wrote: |
Any pointers to why it is behaving differently in the 2 environments..?
|
Because the security's set differently in the 2 environments?
I wouldn't leave it set like that. What you've configured there means any one or anything which connects on the default channel has the rights of mqm (you've solved your security problem by overriding all security). This means the unscrupulous or the inept can do anything they want & is a security hole which is typically undesireable. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
fjb_saper |
Posted: Fri May 23, 2008 3:52 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
shahs wrote: |
This problem is now resolved but I fail to understand how it worked.
Here is what I did:
Since the application on Windows box was failing to connect to the Linux server I modified the the SYSTEM.DEF.SVRCONN channel on the Linux box.
I changed the MCAUSER property to include the mqm group.
I set the MQSERVER property on the Windows box and it worked.
But what is suprising is that we did a similar migration on our Test environment and I did not have to make any changes .
The SYSYEM.DEF.SVRCONN channel on Linux does not have the MCAUSER property set to 'mqm' and the application is working fine.
The same application throws error while connecting in our Model environment but works fine in Test..?
Any pointers to why it is behaving differently in the 2 environments..?
Thanks in adavnce,
Shahs |
You are setting the MQServer property so your application is not java.
This means that the userid being passed is the userid running your client app. This userid needs to exist on your Linux box and be a member of the right group to pass authentication on your MQServer (Linux).
Remove the mcauserid and make sure that the authentication is set up right....
Enjoy  _________________ MQ & Broker admin |
|
Back to top |
|
 |
|