| Author |
Message
|
| fjb_saper |
 Posted: Thu Nov 15, 2007 10:24 am Post subject: |
 |
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20768
Location: LI,NY
|
| jefflowrey wrote: |
Does it succeed to issue setmqaut for an object that doesn't exist on the qmgr you're connected to?
I didn't think it did.
But yes, DO NOT give privileges to S.C.T.Q. |
I believe it works if you give a generic name like PREFIX.NAME.**
_________________
MQ & Broker admin |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Thu Nov 15, 2007 10:25 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
This really counteracts one of the benifits of clustering which is less admin work since your SUPPOSED to be able to minimize q defs and channel defs in a cluster.
So to stays secure, if I got 500 different clustered queues in a cluster, I'm expected to create the 500 local queues on the QMs, and then create 500 more Q Aliases on each and every other QM in the cluster that wants to talk to these queues?!
 
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Nov 15, 2007 10:32 am Post subject: |
|
|
Guest
|
Clustered queues or not, if you want to have randomly named queues AND secure them, you will need to create auth rules to match.
As fjb_saper recommends (and a best practice), queues should be named something like: PAYROLL.TIMECARD, PAYROLL.UPDATE, etc.. Then, the grant can be generic PAYROLL.* |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Nov 15, 2007 10:33 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20768
Location: LI,NY
|
Lookat my previous post. And I'm not sure whether it will work for a queue that is not clustered. Generic authorizations are valid for objects not even yet created that follow the pattern...
Don't remember much but I believe one of the crazier things I did was define a qalias with a targq being a cluster q not hosted by the qmgr I defined the qalias on... This has some serious draw backs as you will a) not be able to do it if the qmgr doesn't know about the cluster queue, b) get some contact admin and misleading reason codes should the qmgr not be able to connect to one of the FR's while trying to post...
If an alias needs to be created because of authorization patterns it should be created on the qmgr the base q resides on and be clustered.... and yes Peter this does mean 500 more queues...
_________________
MQ & Broker admin
Last edited by fjb_saper on Thu Nov 15, 2007 10:41 am; edited 1 time in total |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Nov 15, 2007 10:38 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
Nope, I tried it. setmqaut or dspmqaut fails for a q not locally defined. You have to grant access to the cluster transmit q, or define a Q Alias for every q in the cluster on every QM. Bogus man. Unless we're missing something obvious.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Nov 15, 2007 10:43 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20768
Location: LI,NY
|
| PeterPotkay wrote: |
| Nope, I tried it. setmqaut or dspmqaut fails for a q not locally defined. You have to grant access to the cluster transmit q, or define a Q Alias for every q in the cluster on every QM. Bogus man. Unless we're missing something obvious. |
Did you try with the full qname or a generic qname?
As a workaround you can use a remote q with no rqmname and no xmitq. This would then be your local alias for a clusterq.... or use a cluster alias as rqmname..., set the authorization for the qr and let the qmgr resolve the routing. (1 qr for 500 qc)
_________________
MQ & Broker admin
Last edited by fjb_saper on Thu Nov 15, 2007 10:52 am; edited 2 times in total |
|
| Back to top |
|
|
| mqsidude |
| Posted: Thu Nov 15, 2007 10:48 am Post subject: |
|
|
Centurion
Joined: 22 Jan 2004
Posts: 148
|
Thank you all for your contributions here.
Creating an alias queue for every cluster queue and granting permissions individually seems to be a pain as Peter pointed.
| Quote: |
| setmqaut or dspmqaut fails for a q not locally defined |
Peter - They are talking about the alias queues locally created (on QM2 in this case) and pointing to cluster queues (in this case hosted on QM1). |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Nov 15, 2007 11:00 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| PeterPotkay wrote: |
| Nope, I tried it. setmqaut or dspmqaut fails for a q not locally defined. You have to grant access to the cluster transmit q, or define a Q Alias for every q in the cluster on every QM. Bogus man. Unless we're missing something obvious. |
Nope... you are not missing something, this was one of the hot topics of "advanced clustering" at Impact 2007...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Nov 15, 2007 11:11 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
To be clear about what we're protecting against.
If everyone has PUT authority to S.C.T.Q on some queue manager - then any application connected to that queue manager can talk to every other queue on the entire cluster - with whatever authorities the cluster channel MCAs allow. In a default configuration, this would include the command server input queue.
So one option is to define all your CLUSSDRs and CLUSRCVRs with an MCAUser that has only a specific level of application authorities. Which can be controlled per qmgr...
But for tight security... you need the QALIASes.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Nov 15, 2007 12:08 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20768
Location: LI,NY
|
Just double checked what we are using and must sadly confirm 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Nov 15, 2007 12:50 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| jefflowrey wrote: |
| So one option is to define all your CLUSSDRs and CLUSRCVRs with an MCAUser that has only a specific level of application authorities. Which can be controlled per qmgr... |
But if you tag the MCAUSER of the CLUSRCVR with an ID that does not have access to the SYSTEM.* queues (other than the DLQ), the clustered QMs won't be able to send messages to their cluster command queues. So I think we're still stuck with Aliases for every q or allowing access to the S.C.T.Q
Michael, "advanced clustering at Impact 2007", did they provide a possible solution for this, or just highlight it as an ongoing problem?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Nov 15, 2007 1:00 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| PeterPotkay wrote: |
| jefflowrey wrote: |
| So one option is to define all your CLUSSDRs and CLUSRCVRs with an MCAUser that has only a specific level of application authorities. Which can be controlled per qmgr... |
But if you tag the MCAUSER of the CLUSRCVR with an ID that does not have access to the SYSTEM.* queues (other than the DLQ), the clustered QMs won't be able to send messages to their cluster command queues. So I think we're still stuck with Aliases for every q or allowing access to the S.C.T.Q |
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Nov 15, 2007 1:05 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
MQ 6.1 or 7.0 needs to beef up the security capabilities of MQ in general. A cluster aware setmqaut / dspmqaut / dmpmqaut enhancement is needed for one thing.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Nov 15, 2007 3:34 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| PeterPotkay wrote: |
Michael, "advanced clustering at Impact 2007", did they provide a possible solution for this, or just highlight it as an ongoing problem? |
it was actually T-Rob's session on security (4224) that triggered this awareness, that filtered into Ian vanstones advanced clustering session (4206) and became a topic although I just went through the slides and none refer to security ... 
as you may recall from earlier posts, Impact 2007 was one of the most tight lipped conferences to date...
don't know what has been said about MQ last week in Vienna... (I opted not to go there... as I am planning to go to Impact 2008 in vegas, april 6-11 2008   )
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| Nigelg |
| Posted: Fri Nov 16, 2007 2:24 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
I would mention PUTAUT(CTX) but I know Peter does not like it...
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
|
|
