| Author |
Message
|
| wraymore |
 Posted: Mon Apr 16, 2007 7:34 am Post subject: Solved - Using MQOO_SET_ALL_CONTEXT gets MQRC_NOT_AUTHORIZED |
 |
|
Centurion
Joined: 16 Aug 2005
Posts: 114
Location: Burlington, NC USA
|
Have a .net application attempting to send a message through MQClient to MQServer Hub. We are wanting the client application to provide some data in the MQMD.ApplIdentityData field. On the server we have in the queueManager a queue alias (that the client app references) that routes to a local queue. The OAM sets authority on these queues to "allmqi".
The code within the .net app is:
mqQueue =
mqQMgr.AccessQueue(ReadDefaultConfig(enumDefaultConfig.MQSecurity_QueueN
ame), MQOO_OUTPUT + MQOO_FAIL_IF_QUIESCING + MQOO_SET_ALL_CONTEXT)
mqMsg.ApplicationIdData =
ReadDefaultConfig(enumDefaultConfig.MQSecurity_ApplicationIdData)
mqPutMsgOpts = mqSession.AccessPutMessageOptions()
mqPutMsgOpts.Options = MQPMO_SET_ALL_CONTEXT
mqQueue.Put(mqMsg, mqPutMsgOpts)
When executing the app gets a MQRC 2035 - MQRC_NOT_AUTHORIZED return.
When we remove the MQOO_SET_ALL_CONTEXT and MQPMO_SET_ALL_CONTEXT parameters from the .net application and execute, a message does arrive on the queuemanger in the appropriate local queue, however with no value in the MQMD.ApplIdentityData field.
Any suggestions will be appreciated. Thanks
Last edited by wraymore on Tue Apr 17, 2007 7:55 am; edited 1 time in total |
|
| Back to top |
|
 |
| wraymore |
| Posted: Mon Apr 16, 2007 7:49 am Post subject: |
|
|
Centurion
Joined: 16 Aug 2005
Posts: 114
Location: Burlington, NC USA
|
| Forgot to mention we are running WMQ 5.3 with fp 13 on the server and client installations. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 16, 2007 8:23 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Does the "+allmqi" include the "+set" permission?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| marcin.kasinski |
| Posted: Mon Apr 16, 2007 8:32 am Post subject: |
|
|
Sentinel
Joined: 21 Dec 2004
Posts: 850
Location: Poland / Warsaw
|
In my opinion...
- to use MQOO_SET_ALL_CONTEXT or MQPMO_SET_ALL_CONTEXT you need "set" rights.
_________________
Marcin |
|
| Back to top |
|
|
| wraymore |
| Posted: Mon Apr 16, 2007 8:49 am Post subject: |
|
|
Centurion
Joined: 16 Aug 2005
Posts: 114
Location: Burlington, NC USA
|
| We tried "set" prior to the "allmqi" and still got MQRC_NO_AUTHORIZED |
|
| Back to top |
|
|
| marcin.kasinski |
| Posted: Mon Apr 16, 2007 9:37 am Post subject: |
|
|
Sentinel
Joined: 21 Dec 2004
Posts: 850
Location: Poland / Warsaw
|
| wraymore wrote: |
| We tried "set" prior to the "allmqi" and still got MQRC_NO_AUTHORIZED |
My tips :
Have you done refresh security ?
Check dspmqaut output.
Check qmgr error logs ? (This is the most important)
_________________
Marcin |
|
| Back to top |
|
|
| Nigelg |
| Posted: Tue Apr 17, 2007 12:45 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| Quote: |
Have you done refresh security ? |
For goodness sake....
REFRESH SECURITY IS ONLY NEEDED IF O/S USER NAMES ARE ADDED OR AMENDED.
The answer to this problem is...
When a queue is opened with the open option MQOO_SET_IDENTITY_CONTEXT the set authority on the qmgr is syntactically required.
The solution is to grant +setid authority on the qmgr to the user.
This is not in any manual AFAIK.
This could have been discovered by enabling auth events, running the test and checking the generated event.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| marcin.kasinski |
| Posted: Tue Apr 17, 2007 1:37 am Post subject: |
|
|
Sentinel
Joined: 21 Dec 2004
Posts: 850
Location: Poland / Warsaw
|
| Nigelg wrote: |
For goodness sake....
REFRESH SECURITY IS ONLY NEEDED IF O/S USER NAMES ARE ADDED OR AMENDED.
|
OK.
I could be wrong.
This is my understanding.. :
This is from manual
| Quote: |
When a queue is opened for the first time (or for the first time since a security refresh) WebSphere MQ performs a RACF(R) check to obtain the user's access rights and places this information in the cache. The cached data includes user IDs and resources on which security checking has been performed. If the queue is opened again by the same user the presence of the cached data means WebSphere MQ does not have to issue RACF checks, which improves performance. The action of a security refresh is to discard any cached security information and so force WebSphere MQ to make a new check against RACF. Whenever you add, change or delete a RACF resource profile that is held in the MQADMIN, MQPROC, MQQUEUE, or MQNLIST class, you must tell the queue managers that use this class to refresh the security information that they hold. |
I remember that after changing user rights I had to make refresh security because (as you can read) this information is cached to improve performance.
Now after reading your post I'm little confused.
I will have to check it.
_________________
Marcin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Apr 17, 2007 3:31 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Setmqaut always updates the cache that you see documented there.
Changing group memberships in the OS does not.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| marcin.kasinski |
| Posted: Tue Apr 17, 2007 3:52 am Post subject: |
|
|
Sentinel
Joined: 21 Dec 2004
Posts: 850
Location: Poland / Warsaw
|
| jefflowrey wrote: |
Setmqaut always updates the cache that you see documented there.
Changing group memberships in the OS does not. |
Thanks.
I've checked it.
Now it's clear for me.
_________________
Marcin |
|
| Back to top |
|
|
| wraymore |
| Posted: Tue Apr 17, 2007 4:16 am Post subject: |
|
|
Centurion
Joined: 16 Aug 2005
Posts: 114
Location: Burlington, NC USA
|
Here is the output from dspmqaut on the Local and alias queues
dspmqaut -m QMMSGDAA -n TRD.IBD_USLABS.QL -t q -p uslabsd
Entity uslabsd has the following authorizations for object TRD.IBD_USLABS.QL:
get
browse
put
inq
set
passid
passall
setid
setall
$ dspmqaut -m QMMSGDAA -n TRD.IBD_USLABS.QA -t q -p uslabsd
Entity uslabsd has the following authorizations for object TRD.IBD_USLABS.QA:
get
browse
put
inq
set
passid
passall
setid
setall |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Tue Apr 17, 2007 4:23 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
what's the output of:
dspmqaut -m QMMSGDAA -t qmgr -p uslabsd
the qmgr object also has a +setid +setall setting.
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| Nigelg |
| Posted: Tue Apr 17, 2007 5:02 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
Hello, hello....
I did leave a rather hefty clue in my last post...
| Quote: |
The answer to this problem is...
When a queue is opened with the open option MQOO_SET_IDENTITY_CONTEXT the set authority on the qmgr is syntactically required.
The solution is to grant +setid authority on the qmgr to the user.
|
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| wraymore |
| Posted: Tue Apr 17, 2007 7:53 am Post subject: Solved - Using MQOO_SET_ALL_CONTEXT gets MQRC_NOT_AUTHORIZED |
|
|
Centurion
Joined: 16 Aug 2005
Posts: 114
Location: Burlington, NC USA
|
Thanks everyone for your assistance. Thanks Nigelg for the specific information. javascript:emoticon(' ')
javascript:emoticon('') |
|
| Back to top |
|
|
|
|
