| Author |
Message
|
| PeterPotkay |
 Posted: Fri Jul 12, 2013 11:57 am Post subject: MQ 2035 |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
The bubba ID is a local ID defined to the server.
Windows 2008 R2 SP1
MQ 7.5.0.1
The MCAUSER of the SVRCONN channel is set to bubba.
I am using amqsgetc from my desktop to access this QM.
I can’t get past this error.
Grasping at straws here. Even though dmpmqaut shows this ID has this access I refreshed security. I restarted the QM. What is the problem here?
The entry in the MQ error log.
| Quote: |
7/12/2013 15:46:21 - Process(2572.20) User(mqxxxxx_xxx) Program(amqzlaa0.exe)
Host(WH1WMBD0022) Installation(Installation1)
VRMF(7.5.0.1) QMgr(FSIBLAB)
AMQ8077: Entity 'bubba@myservernamehere' has insufficient authority to access object
'HIG.FSIBLAB.LOCAL.QUEUE'.
EXPLANATION:
The specified entity is not authorized to access the required object. The
following requested permissions are unauthorized: get
ACTION:
Ensure that the correct level of authority has been set for this entity against
the required object, or ensure that the entity is a member of a privileged
group.
----- amqzfubn.c : 515 -------------------------------------------------------- |
The Authority Event message from MO71:
| Code: |
Command :44 (QMgr Event)
Reason :2035 (Not authorized.)
Parameter Id :2015 (QMgr Name)
Value :'FSIBLAB '
Parameter Id :1020 (Reason Qualifier)
Value :2 [0x'2'] MQRQ_OPEN_NOT_AUTHORIZED
Parameter Id :2016 (Q Name)
Value :'HIG.FSIBLAB.LOCAL.QUEUE '
Parameter Id :1022 (Open Options)
Value :00002001
00002000 Fail if quiescing
00000001 Input as Queue Definition
Parameter Id :3025 (User Identifier)
Value :'bubba '
Parameter Id :1 (Appl Type)
Value :11 [0x'B'] MQAT_WINDOWS_NT
Parameter Id :3024 (Appl Name)
Value :'ebSphere MQ\bin\amqsgetc.exe' |
| Code: |
E:\Peter>dmpmqaut -m FSIBLAB -p bubba
profile: 'HIG.FSIBLAB.LOCAL.QUEUE'
object type: queue
entity: bubba@MYSERVERNAMEHERE
entity type: principal
authority: get put inq
- - - - - - - -
profile: SELF
object type: qmgr
entity: bubba@MYSERVERNAMEHERE
entity type: principal
authority: inq connect
- - - - - - - -
profile: @CLASS
object type: queue
entity: bubba@MYSERVERNAMEHERE
entity type: principal
authority: none
- - - - - - - -
profile: @CLASS
object type: qmgr
entity: bubba@MYSERVERNAMEHERE
entity type: principal
authority: none
E:\Peter> |
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Jul 12, 2013 11:01 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The problem is that you are dealing with 2 different ids and you need to treat them as such:
bubba => expected to be defined locally to the qmgr box
bubba@mydomain => a domain account not equal to bubba.
I usually authorize the domain group of the account. Then create a domain account in the domain group. This way any user that will be added to the domain group can have the same access. (V7.5 no admin access)
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Jul 13, 2013 4:08 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I'm testing a simple use case for a PMR so I am using a temporary single, locally defined ID on the server.
Because its Windows I am OK with authorizing the principle versus going against a group.
I actually started with a local ID in a local group and authorized the group, ran into the same issue, so switched to authorizing the user directly to take one variable (group membership) out of the equation.
Running the setmqaut commands against 'bubba' or against 'bubba@myservernamehere' results in the same dmpmqaut results. See here:
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r5/topic/com.ibm.mq.doc/fa15670_.htm
| Quote: |
| For WebSphere MQ for Windows only, all principals displayed include domain information |
Putting 'bubba' or 'bubba@myservernamehere' in the MCAUSER causes the same results.
The connection to the queue manager works all along. +connect is being recognized. The amqscnxc sample works just fine with this set up. But no matter how hard I try to access a queue, amqsputc or amqsgetc, it throws the 2035. I tried defining a new queue, running an additional setmqaut command for that new queue and still a 2035.
The fact that the MQCONN works but the MQOPEN fails is interesting.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Jul 13, 2013 6:21 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Was the qmgr started/created with a security group (-sa flag)?
On the other hand the dmpmqaut says you have no get authority against the queue, yet you are trying to do an amqsgetc
Does the user running the MQ Service have the requisite permissions to query the domain about group membership?
This is given by editing the user policy on the domain server.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Jul 13, 2013 7:51 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
| Was the qmgr started/created with a security group (-sa flag)? |
I'll check on Monday, I did not create this QM. It is our first MQ 7.1 / 7.5 QM.
| fjb_saper wrote: |
On the other hand the dmpmqaut says you have no get authority against the queue, yet you are trying to do an amqsgetc
|
Sorry, for this queue that is true, but I did try other permissions on other queues as a test and all show the same weird issue - MQCONN works fine, MQOPEN fails.
| fjb_saper wrote: |
Does the user running the MQ Service have the requisite permissions to query the domain about group membership?
This is given by editing the user policy on the domain server. |
I'll have to check on Monday. It should have been created this way per our standard. But who knows how they actually created it. Never assume anything I suppose. Regardless, is this a factor if bubba is a local ID and not a domain ID?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sun Jul 14, 2013 7:27 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
But regardless of the answers to your questions, why would the authority for the MQCONN work, but the MQOPEN permissions seem to not be recognized?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sun Jul 14, 2013 10:02 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Hmmmm.
Try this shotgun: grant +allmqi to the queue for bubba. Any change?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Sun Jul 14, 2013 3:25 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
Does MQ Trace show how MQ is resolving the authorization?
_________________
Glenn |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jul 15, 2013 5:45 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I’ve been trying various things mentioned in this thread. I had a long response all ready to send out this morning, and then I had one more look at the authorities, this time using my trusty MO71 GUI. There was the problem, plain as day. The way the GUI presented it made the problem readily apparent when I could see all the profiles listed.
It reminded me of my first week of Basic Programmer Training back in ’98, where we were learning how to submit our very first JCL jobs. One poor schlub (me) was stuck after hours in class trying to get that blasted job to run. No one could figure it out. The next morning we come in, the teacher takes one look at it again and tells me to remove that one extra slash from one of the lines and walks away laughing. Hours wasted because of an extra character on one line. Geez, I thought, one little mistake like that will derail a whole program? I thought these computers were supposed to be smart.
Sigh.
Here is the authority I have.
| Code: |
E:\Peter>dmpmqaut -m FSIBLAB -p bubba
profile: 'HIG.FSIBLAB.LOCAL.QUEUE'
object type: queue
entity: bubba@MYSERVERNAMEHERE
entity type: principal
authority: get put inq |
Here is the error message:
The entry in the MQ error log.
| Code: |
7/12/2013 15:46:21 - Process(2572.20) User(mqxxxxx_xxx) Program(amqzlaa0.exe)
Host(WH1WMBD0022) Installation(Installation1)
VRMF(7.5.0.1) QMgr(FSIBLAB)
AMQ8077: Entity 'bubba@myservernamehere' has insufficient authority to access object
'HIG.FSIBLAB.LOCAL.QUEUE'. |
Look at those queue names. See the problem yet? Try squinting real hard.
I had run this:
| Code: |
| E:\>setmqaut -m FSIBLAB -t queue -n ‘HIG.FSIBLAB.LOCAL.QUEUE’ -p bubba -all +put +get +inq |
I should have done this:
| Code: |
| E:\>setmqaut -m FSIBLAB -t queue -n HIG.FSIBLAB.LOCAL.QUEUE -p bubba -all +put +get +inq |
| Code: |
E:\>dmpmqaut -m FSIBLAB -p bubba -t queue
profile: HIG.FSIBLAB.LOCAL.QUEUE
object type: queue
entity: bubba@WH1WMBD0022
entity type: principal
authority: get put inq
- - - - - - - -
profile: 'HIG.FSIBLAB.LOCAL.QUEUE'
object type: queue
entity: bubba@WH1WMBD0022
entity type: principal
authority: get put inq
- - - - - - - -
profile: @CLASS
object type: queue
entity: bubba@WH1WMBD0022
entity type: principal
authority: none |
I had just gotten out of a runmqsc session creating some new queues that I had wrapped in quotes and I guess I was still thinking setmqaut needed it as well (it doesn’t – it respects lowercase names when needed.)
As soon as I ran this everything works as expected. It had been working exactly as it should have all along. Computers are smart – me dumb.
-Peter
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jul 15, 2013 8:33 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Damn apostrophes.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
|
|
