| Author |
Message
|
| zpat |
 Posted: Fri Dec 11, 2009 3:07 am Post subject: SYSTEM.ADMIN.QMGR.EVENT and authority events |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
I am implementing better security on my queue managers (and removing mqm from the channel's mcauser).
I want to see any 2035 events so I can check if my setmqaut settings are correct, so I enabled authority events.
Some messages are on SYSTEM.ADMIN.QMGR.EVENT and with the handy MO71 tool I can format them like this
| Quote: |
Command :44 (QMgr Event)
Reason :2035 (Not authorized.)
Parameter Id :2015 (QMgr Name)
Value :'XXXXXX '
Parameter Id :1020 (Reason Qualifier)
Value :4 [0x'4'] MQRQ_CMD_NOT_AUTHORIZED
Parameter Id :1021 (Command)
Value :13 [0x'D'] MQCMD_INQUIRE_Q
Parameter Id :3025 (User Identifier)
Value :'yyyyyyyy '
|
However the queue name being inquired against is not shown in the message!
This is not terribly useful - all I know is the queue manager (duh) and the userid.
Any ideas how to find out the object name causing the 2035 (apart from asking the user of course)?
Last edited by zpat on Fri Dec 11, 2009 4:43 am; edited 1 time in total |
|
| Back to top |
|
 |
| exerk |
| Posted: Fri Dec 11, 2009 3:34 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
zpat,
Set the MQS_REPORT_NOAUTH environment variable and restart your queue manager. More detailed info on it can be found HERE, and also THIS one may be of help to you.
EDIT: Having re-read your post - I find the Events and Statistics plug-in for MQExplorer is quite useful.
_________________
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 |
|
|
| zpat |
| Posted: Fri Dec 11, 2009 3:54 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Thanks - very useful.
Shame IBM didn't enhance the message though. |
|
| Back to top |
|
|
| crossland |
| Posted: Fri Feb 11, 2011 8:58 am Post subject: |
|
|
Master
Joined: 26 Jun 2001
Posts: 248
|
| exerk wrote: |
zpat,
Set the MQS_REPORT_NOAUTH environment variable and restart your queue manager. More detailed info on it can be found HERE, and also THIS one may be of help to you.
EDIT: Having re-read your post - I find the Events and Statistics plug-in for MQExplorer is quite useful. |
Has anyone come across a similar technique on iSeries? |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Feb 11, 2011 1:26 pm Post subject: Re: SYSTEM.ADMIN.QMGR.EVENT and authority events |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
|
| Back to top |
|
|
| crossland |
| Posted: Mon Feb 14, 2011 3:48 am Post subject: |
|
|
Master
Joined: 26 Jun 2001
Posts: 248
|
The queue name that was used in the display command would be a useful bit of information to add to the event message. The iSeries admin guide states the following:
| Quote: |
To process the DSP commands you must grant the user *connect and *admdsp authority to the queue manager, together with any specific option listed:
...
* DSPMQMQ, Display WebSphere MQ Queue – *admdsp to the queue
|
As the userid has *connect and *admdsp for the queue manager, it would be helpful if I could see which queue should have *admdsp. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 14, 2011 5:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It would have to be more generic than the queue name.
Since the error in question is that you attempted to run a PCF command that you are not authorized to run, and this command might not actually involve any queue at all, merely adding a queue name is the wrong choice.
Adding the object name of the PCF command, however, is a good idea. So if you're not allowed to delete channels, then it could tell you what channel you tried to delete. Or if you're not allowed to define services, it could tell you the name of the service that you tried to define.
But you probably need to open a requirement to get that changed. |
|
| Back to top |
|
|
| crossland |
| Posted: Tue Feb 15, 2011 6:21 am Post subject: |
|
|
Master
Joined: 26 Jun 2001
Posts: 248
|
Totally agree with mqjeff about his last post.
The cause of the event messages is peculiar. An application is running on a remote queue manager and connecting to a receiver channel with a MCA userid. That userid has *CONNECT and *ADMDSP authorities for the queue manager and *ADMDSP for all queues.
The event messages give a reason of 'Not Authorised: Command' with the command being 'DISPLAY QUEUE'.
Would be very grateful for any suggestions on how to resolve this. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Feb 15, 2011 10:33 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| crossland wrote: |
Totally agree with mqjeff about his last post.
The cause of the event messages is peculiar. An application is running on a remote queue manager and connecting to a receiver channel with a MCA userid. That userid has *CONNECT and *ADMDSP authorities for the queue manager and *ADMDSP for all queues.
The event messages give a reason of 'Not Authorised: Command' with the command being 'DISPLAY QUEUE'.
Would be very grateful for any suggestions on how to resolve this. |
No authorizations to the qmgr's pcf input queue or reply to model queue...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| crossland |
| Posted: Wed Feb 16, 2011 2:13 am Post subject: |
|
|
Master
Joined: 26 Jun 2001
Posts: 248
|
The application involved issues a DISPLAY QUEUE on all queues; the problem is with SYSTEM.AUTH.DATA.QUEUE.
The Security manual states, under "How access control is implemented by WebSphere MQ on UNIX systems and Windows":
| Quote: |
| The OAM maintains an access control list (ACL) for each resource that it controls. Authorization data is stored on a local queue called SYSTEM.AUTH.DATA.QUEUE. Access to this queue is restricted to users in the mqm group, and additionally on Windows, to users in the Administrators group, and users logged in with the SYSTEM ID. User access to the queue cannot be changed. |
Does a similar concept apply on iSeries? If so, is there any way to grant the MCA user *ADMDSP to SYSTEM.AUTH.DATA.QUEUE? GRTMQMAUT reports that the queue doesn't exist when you try to grant access to SYSTEM.AUTH.DATA.QUEUE. As you can imagine, I am reluctant to give super access to the MCA userid. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Feb 16, 2011 2:37 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| crossland wrote: |
| the problem is with SYSTEM.AUTH.DATA.QUEUE. |
The application needs to stop trying to issue DISPLAY QUEUE on this queue, or be running as mqm.
Since this is the queue that holds and controls OAM information, it's a special case queue for OAM security.... |
|
| Back to top |
|
|
| crossland |
| Posted: Wed Feb 16, 2011 2:51 am Post subject: |
|
|
Master
Joined: 26 Jun 2001
Posts: 248
|
It gets weirder - there was a fix to allow you to set these privileges on 6.0.2.8:
http://www-01.ibm.com/support/docview.wss?rs=171&uid=swg1IZ52608
And this queue manager is 6.0.2.9.
Yet the following is produced:
GRTMQMAUT OBJ(SYSTEM.AUTH.DATA.QUEUE) OBJTYPE(*Q) USER(...) AUT(*ADMDSP) MQMNAME(...)
WebSphere MQ authority granted.
RFRMQMAUT MQMNAME(...)
WebSphere MQ security cache refreshed.
DSPMQMAUT OBJ(SYSTEM.AUTH.DATA.QUEUE) OBJTYPE(*Q) USER(...) MQMNAME(...)
WebSphere MQ object SYSTEM.AUTH.DATA.QUEUE not found.
Error found on DSPMQMAUT command.
Authorisation events are still being produced after these commands were executed. |
|
| Back to top |
|
|
| crossland |
| Posted: Tue Feb 22, 2011 3:47 am Post subject: |
|
|
Master
Joined: 26 Jun 2001
Posts: 248
|
Apparently, this works when setmqaut is issued from qshell, but not using GRTMQMAUT (an APAR has been raised to resolve this: SE46973).
The problem that I have is when I issue setmqaut from the qshell, I get the following error:
| Code: |
$
> /qsys.lib/qmqm.lib/setmqaut.pgm -m <mgr> -t q -p <id> -n SYSTEM.AUTH.DATA.QUEUE +dsp
00000893 |AMQ0893| |WebSphere MQ was unable to display an error message for message id hexadecimal %6, with inserts %1, %2, %3, %
4 and %5.
|
$
|
Any suggestions on what needs to be done, to issue setmqaut from qshell? For queues other than SYSTEM.AUTH.DATA.QUEUE, GRTMQMAUT works fine and dspmqver works within qshell. |
|
| Back to top |
|
|
| crossland |
| Posted: Wed Feb 23, 2011 1:28 am Post subject: |
|
|
Master
Joined: 26 Jun 2001
Posts: 248
|
Fixed it. If anyone else encounters this problem, the solution is:
1)Ensure *PUBLIC has *USE authority to the DSPMQMQ command
2)Grant *CONNECT and *ADMDSP authority to the queue manager:
GRTMQMAUT OBJ(<qmgr>) OBJTYPE(*MQM) USER(<user>) AUT(*CONNECT *ADMDSP) MQMNAME(<qmgr>)
3)Replace the GRANT to the Q with the SET command as follows:
Instead of issuing
GRTMQMAUT OBJ(SYSTEM.AUTH.DATA.QUEUE) OBJTYPE(*Q) USER(<user>) AUT(*ADMDSP) MQMNAME(<qmgr>)
Do this instead:
STRQSH
export QIBM_MULTI_THREADED=Y
/qsys.lib/qmqm.lib/setmqaut.pgm -m <qmgr> -t q -p <user> -n SYSTEM.AUTH.DATA.QUEUE +dsp
Press F3
4)RFRMQMAUT MQMNAME(<qmgr>) |
|
| Back to top |
|
|
|
|
