| Author |
Message
|
| given2fly |
 Posted: Fri Oct 31, 2014 9:56 am Post subject: setmqaut question |
 |
|
Newbie
Joined: 18 Sep 2014
Posts: 5
|
Hello all,
I am trying to setup read-only access to all queues for a group that I created for users who use MQexplorer. I am running the command below:
$ setmqaut -m QMNAME -t q -n '**' -g mqexp +dsp +browse
The setmqaut command completed successfully.
But it doesnt set the permissions for all queues:
$ dspmqaut -m QMNAME -t q -n 'QL.*' -g mqexp
Entity mqexp has the following authorizations for object QL.*:
I have tried different variations of using the wildcards "**" "*.**" *.** but it doesnt make a difference. What am I missing?
Thanks |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri Oct 31, 2014 10:02 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| there's a difference between dspmqaut and dmpmqaut. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Oct 31, 2014 10:07 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Take a look at THIS, which is V7.0, but should give you a starter for 10...
_________________
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 |
|
|
| given2fly |
| Posted: Fri Oct 31, 2014 10:21 am Post subject: |
|
|
Newbie
Joined: 18 Sep 2014
Posts: 5
|
OK so the authorizations are there, it looks like I was running into a wild card issue OR judging from the below dmpmqaut output, it created separate profiles for every one of my wildcard attempt:
$ dmpmqaut -m QMNAME -t q -n QL.OUT.B2B -g mqexp
profile: *.**
object type: queue
entity: mqexp
entity type: group
authority: browse dsp
- - - - - - - -
profile: **
object type: queue
entity: mqexp
entity type: group
authority: browse dsp
$ dspmqaut -m QMNAME -t q -n QL.OUT.B2B -g mqexp
Entity mqexp has the following authorizations for object QL.OUT.B2B:
browse
dsp
Hopefully its OK to have multiple profiles like the above. Thanks to mqjeff for giving me the hint.
exerk,
your link took me to a page that doesnt exist. |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Oct 31, 2014 1:07 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
|
| Back to top |
|
|
| JosephGramig |
| Posted: Mon Nov 03, 2014 7:44 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
| given2fly wrote: |
OK so the authorizations are there, it looks like I was running into a wild card issue OR judging from the below dmpmqaut output, it created separate profiles for every one of my wildcard attempt:
$ dmpmqaut -m QMNAME -t q -n QL.OUT.B2B -g mqexp
profile: *.**
object type: queue
entity: mqexp
entity type: group
authority: browse dsp
- - - - - - - -
profile: **
object type: queue
entity: mqexp
entity type: group
authority: browse dsp
$ dspmqaut -m QMNAME -t q -n QL.OUT.B2B -g mqexp
Entity mqexp has the following authorizations for object QL.OUT.B2B:
browse
dsp
Hopefully its OK to have multiple profiles like the above. Thanks to mqjeff for giving me the hint.
exerk,
your link took me to a page that doesnt exist. |
Well... *.** is more specific than **, but you gave the same permissions...
You should be as clean as possible and remove any rules you don't want.
Here is an article on your specific topic.
btw, I prefer amqoamd to dspmqaut. Use grep -v 'g mqm' to filter out stuff you don't need (like all of the group mqm permissions). |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Mon Nov 03, 2014 7:51 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
So, what have you done to ensure they don't just connect as mqm or the Windows service ID to gain full administrative control?
Exerk's link was probably better than mine... |
|
| Back to top |
|
|
| given2fly |
| Posted: Wed Nov 05, 2014 11:55 am Post subject: |
|
|
Newbie
Joined: 18 Sep 2014
Posts: 5
|
Yes. We deployed MQ/MB a few years ago and are just getting smarter about MQ security. We thought we were setting rights for individual users (-p option with setmqaut) but during a recent audit realized that MQ was using the primary group instead. That made everyone was part of the mqm/mqbrkrs group. So we now have moved them to another group with limited privileges.
I was also able to figure out how to clean up the orphaned AUTHRECs left behind after the setmqaut -all for the default primary user group.
I think we still have some ground to cover as I am reading that using the default SVRCONN channels isnt a good idea. But am taking it one step at a time.
Thanks, |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Nov 05, 2014 12:06 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| given2fly wrote: |
| I think we still have some ground to cover as I am reading that using the default SVRCONN channels isnt a good idea. But am taking it one step at a time. |
The current IBM MQ Security Bible as far as I' m concerned...
...and yes, I checked the link this time!
_________________
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 |
|
|
|
|
