ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Security » MQ 2035

Post new topic  Reply to topic
 MQ 2035 « View previous topic :: View next topic » 
Author Message
PeterPotkay
PostPosted: Fri Jul 12, 2013 11:57 am    Post subject: MQ 2035 Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7716

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
View user's profile Send private message
fjb_saper
PostPosted: Fri Jul 12, 2013 11:01 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20697
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
View user's profile Send private message Send e-mail
PeterPotkay
PostPosted: Sat Jul 13, 2013 4:08 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7716

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
View user's profile Send private message
fjb_saper
PostPosted: Sat Jul 13, 2013 6:21 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20697
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
View user's profile Send private message Send e-mail
PeterPotkay
PostPosted: Sat Jul 13, 2013 7:51 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7716

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
View user's profile Send private message
PeterPotkay
PostPosted: Sun Jul 14, 2013 7:27 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7716

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
View user's profile Send private message
bruce2359
PostPosted: Sun Jul 14, 2013 10:02 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9405
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
View user's profile Send private message
gbaddeley
PostPosted: Sun Jul 14, 2013 3:25 pm    Post subject: Reply with quote

Jedi

Joined: 25 Mar 2003
Posts: 2498
Location: Melbourne, Australia

Does MQ Trace show how MQ is resolving the authorization?
_________________
Glenn
Back to top
View user's profile Send private message
PeterPotkay
PostPosted: Mon Jul 15, 2013 5:45 am    Post subject: Reply with quote

Poobah

Joined: 15 May 2001
Posts: 7716

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
View user's profile Send private message
bruce2359
PostPosted: Mon Jul 15, 2013 8:33 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9405
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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ Security » MQ 2035
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.