| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Need some thoughts about authorization problem |
« View previous topic :: View next topic » |
| Author |
Message
|
| Metalman |
 Posted: Wed May 05, 2010 6:18 am Post subject: Need some thoughts about authorization problem |
 |
|
Newbie
Joined: 05 May 2010
Posts: 5
Location: Dubuque, IA
|
I've been working at this problem for a bit now, and everything that I've tried seemed to have lead to a dead end. Here's the story.
Back around Feb 19 (or whenever that Friday was before the weekend), I had to apply a fixpack upgrade to a few servers to the customer. The result would have brought 6.0.2.6 to 6.0.2.8. Apparently ever since then, the customer has been having issues with some of the queues. Just recently, they have came back saying how they're having problems with some other queues (why they only notice it now, who knows). They have been trying to put messages from their application from WAS to a queue, but it gets sent to the DLQ. Browsing through the DLQ, I find the first message that was put there that was in relation to this:
| Code: |
****Message descriptor****
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 273 CodedCharSetId : 819
Format : 'MQDEAD '
Priority : 4 Persistence : 1
MsgId : X'414D5120434D50524F44514D202020204BC153CE206CCA03'
CorrelId : X'000000000000000000000000000000000000000000000000'
BackoutCount : 0
ReplyToQ : ' '
ReplyToQMgr : 'CMPRODQM '
** Identity Context
UserIdentifier : 'rmadmin '
AccountingToken :
X'0000000000000000000000000000000000000000000000000000000000000000'
ApplIdentityData : ' '
** Origin Context
PutApplType : '28'
PutApplName : 'WebSphere MQ Client for Java'
PutDate : '20100503' PutTime : '10493238'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'
**** Message ****
length - 6370 bytes
00000000: 444C 4820 0000 0001 0000 07F3 4943 4C41 'DLH .......óICLA'
00000010: 494D 532E 5245 494E 4445 5849 4E47 4155 'IMS.REINDEXINGAU'
00000020: 4449 5451 5545 5545 2E42 4143 4B4F 5554 'DITQUEUE.BACKOUT'
00000030: 2020 2020 2020 2020 2020 2020 434D 5052 ' CMPR'
00000040: 4F44 514D 2020 2020 2020 2020 2020 2020 'ODQM '
00000050: 2020 2020 2020 2020 2020 2020 2020 2020 ' ' |
not sure if the rest of it is needed, but there's a lot to it. First thing that crosses my mind, as was taught by Vitor, was the 07F3, which I found is a 2035. I figured ok, seems like a usual problem. So I check the status of the queue itself with the ID that's trying to send it:
| Code: |
dspmqaut -m CMPRODQM -n ICLAIMS.REINDEXINGAUDITQUEUE.BACKOUT -t q -p rmadmin
Entity rmadmin has the following authorizations for object ICLAIMS.REINDEXINGAUDITQUEUE.BACKOUT:
get
browse
put
inq
crt |
Correct me if I'm wrong, but since they have the level of access they probably need, I would think they should have access to the queue. So now I'm curious about the 2035. I've done quite a few things to see if I can try to fix it, but it's all been for nothing so far.
Since we also support WAS for this customer, I do have access to the ID, so I'd though I'd try some other things that might help figure it out. Being a production server, I don't want to do any extensive damage and get in trouble, so I've created a Dummy queue and put a few messages on it under mqm. Under rmadmin, I try to browse the queue but I get the following:
| Code: |
[/home/rmadmin]$ /usr/mqm/samp/bin/amqsbcg DUMMY CMPRODQM
AMQSBCG0 - starts here
**********************
MQCONN failed with CompCode:2, Reason:2059 |
Only thing I found is 2059 means Queue Manager not available. Now that throws me off even more since I know it's up and running because I just made the queue shortly before this command. This time I've checked the queue and the qmgr. This is what I get:
| Code: |
[/home/mqm]dspmqaut -m CMPRODQM -n DUMMY -t q -p rmadmin
Entity rmadmin has the following authorizations for object DUMMY:
get
browse
put
inq
set
crt
dlt
chg
dsp
passid
passall
setid
setall
clr
[/home/mqm]dspmqaut -m CMPRODQM -t qmgr -p rmadmin
Entity rmadmin has the following authorizations for object CMPRODQM:
inq
set
connect
altusr
crt
dlt
chg
dsp
setid
setall |
I'm not sure what else to say. I would imagine I'm lacking a bit more information, but I can't think too much on it right now unless asked. If it helps, Vitor does know the box, or at least he should. If he doesn't, him and I need to talk about it.
Sorry for the long post, I'm new so take it easy on me 
And if he reads this before coming back to the office, I've asked help from his backup and he's even confused. Also, the beard told me to post, I didn't want to. |
|
| Back to top |
|
 |
| Metalman |
| Posted: Wed May 05, 2010 6:20 am Post subject: |
|
|
Newbie
Joined: 05 May 2010
Posts: 5
Location: Dubuque, IA
|
something else that came to my mind, since I know it might be asked.
[/home/mqm]uname -a
AIX (server name) 3 5 0021C2AB4C00
I took out the name of the server, just to be safe. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed May 05, 2010 6:31 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
You can enable QM authority events and look for the event messages if a 2035 occurs.
However I have read about subtle changes to the way that JMS/WAS authorisations are handled due to a fix in 6.0.2.8
| Quote: |
Using Classes for Java Message Service (JMS)
--------------------------------------------
WebSphere MQ Version 6.0.2.8 changes the way applications using the
classes for Java Message Service (JMS) handle User IDs when creating
JMS Connections.
Applications would create Connections by calling one of the following
methods:
QueueConnectionFactory.createQueueConnection(String userName, String password)
TopicConnectionFactory.createTopicConnection(String userName, String password)
ConnectionFactory.createConnection(String userName, String password)
If you specify a null value or an empty string as the username, an
empty string will now be sent to the queue manager for authorization
checks.
Prior to this Fix Pack, if you specified a null value as the username,
then the User ID under which the application was running was sent to
the queue manager for authorization checks.
You can choose to preserve the pre-6.0.2.8 behaviour by using a new
Java system property. The new property is called:
com.ibm.mq.jms.ForceUserID
and takes one of two values:
com.ibm.mq.jms.ForceUserID=false
If an application passes an empty string or a null value for the username
when creating a connection, the empty string is sent to the queue manager
for authorization checks.
com.ibm.mq.jms.ForceUserID=true
If the application passes an empty string or a null value for the username
when creating a connection, then the User ID under which the application
is running will be sent to the queue manager for authorization checks.
To set the property, applications using the WebSphere MQ classes for JMS must
be started with the following command:
java -Dcom.ibm.mq.jms.ForceUserID=<value> <application class>
For more details, please refer to
APAR IZ49302 : http://www.ibm.com/support/docview.wss?uid=swg1IZ49302
|
|
|
| Back to top |
|
|
| Metalman |
| Posted: Wed May 05, 2010 7:11 am Post subject: |
|
|
Newbie
Joined: 05 May 2010
Posts: 5
Location: Dubuque, IA
|
| well, it's in the process of being suggested to the customer to see if it's the problem, i'll update that when i get word. |
|
| Back to top |
|
|
| exerk |
| Posted: Wed May 05, 2010 2:01 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
You may also want to try THIS as an augmentation of what zpat has suggested.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| Metalman |
| Posted: Thu May 06, 2010 6:34 am Post subject: |
|
|
Newbie
Joined: 05 May 2010
Posts: 5
Location: Dubuque, IA
|
as I came into the office today, I just had a random thought. Even though it's displaying that level of access, could it be possible that the security wasn't refreshed and they don't actually have that access?
If that was the problem I'm going to be pissed at myself. |
|
| Back to top |
|
|
| Metalman |
| Posted: Mon Aug 23, 2010 7:17 am Post subject: |
|
|
Newbie
Joined: 05 May 2010
Posts: 5
Location: Dubuque, IA
|
i know i'm somewhat reviving an old thread, but i want vitor to see this at least.
a little bit of information i've seemed to neglect. the messages that they are having issues with, they are trying to make them go to a backout queue, but instead of doing that it was going straight to the DLQ.
so the customer came back once again with this issue and this time they wanted to define new queues to pretty much be identical to the problem queues. the box has mqtools on it, so i've looked at a log file with information on the queues and basically copied that and renamed the queues with a 1 at the end of it. i've also set up the permissions to be identical. so basically it's all a replica of the originals, just with a different name.
so then the customer when to send messages to the new queues, and it worked.
i have no clue as to why the new queues would work when it was replicated from the originals, but it did.
before this i was able to get them to do a trace with the original problem on the original queues, while i was doing it for mq. got that information, sending it off to lv2 support to see what they would come back with.
on an off topic, vitor get in touch with me, i want to ask you a question and i can't seem to do pms (reasons probably known with your stories)
Edit: apparently the mqjms trace had nothing in it...great...that's what I get for not checking. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Aug 23, 2010 7:23 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Metalman wrote: |
| i know i'm somewhat reviving an old thread, but i want vitor to see this at least. |
Argh! Argh! The flashbacks weren't fake memories! It was real! Real!
a little bit of information i've seemed to neglect. the messages that they are having issues with, they are trying to make them go to a backout queue, but instead of doing that it was going straight to the DLQ.
| Metalman wrote: |
| on an off topic, vitor get in touch with me, i want to ask you a question and i can't seem to do pms (reasons probably known with your stories) |
The PMs got switched off as an anti-spammer feature. I'm sure someone up there has my hotmail id.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Aug 24, 2010 5:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Vitor wrote: |
| I'm sure someone up there has my hotmail id. |
Certainly Glenn & Sonia know how to find me 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
