| Author |
Message
|
| JanB_193 |
 Posted: Wed Oct 15, 2014 5:32 am Post subject: Channel Authentication Records block instead of allow.? |
 |
|
Novice
Joined: 22 Aug 2014
Posts: 15
|
Hi all
I must be missing an important point regarding the channel security logic. 
I (successfully) run mqsc for my Queue Manager with the following commands to set the authentication records:
ALTER QMGR CHLAUTH(ENABLED)
SET CHLAUTH(*) TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS)
SET CHLAUTH(SYSTEM.BKR.CONFIG) TYPE(USERMAP) CLNTUSER('adm.jbr1') MCAUSER('srvWMQ-test@irdom.net')
REFRESH SECURITY(*)
I then try to connect to a remote Broker from the toolkit and get the folloving error msg:
[size=9]15.10.2014 15:06:25 - Process(4204.31) User(srvWMQ-test) Program(amqrmppa.exe) Host(S99069) Installation(Installation1) VRMF(8.0.0.0) QMgr(1LGCIIBT)
Channel was blocked by userid
The inbound channel 'SYSTEM.BKR.CONFIG' was blocked from address '172.31.22.167' because the active values of the channel were mapped to a userid which should be blocked. The active values of the channel were 'MCAUSER(srvWMQ-test@irdom.net) CLNTUSER(adm.jbr1) ADDRESS(M06137)'.
I thought that I explicitely ALLOWED adm.jbr1 the access but something behaves somewhat the other way around then I would expect... 
Any hints where I'm wrong would be greatly appreciated
Environment: WMQ v8.0.0.0 & IIB v9.0.0.2 on Windows Server 2012 R2
Regards Jan |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Wed Oct 15, 2014 5:35 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Is "srvWMQ-test@irdom.net" a member of the mqm group?
If so it's blocked by the default rule to block *MQADMIN users.
So you would need to set up a more specific rule that doesn't block srvWMQ-test@irdom.net |
|
| Back to top |
|
|
| JanB_193 |
| Posted: Wed Oct 15, 2014 5:45 am Post subject: |
|
|
Novice
Joined: 22 Aug 2014
Posts: 15
|
Thanks for the swift answer Jeff!
Yes "srvWMQ-test@irdom.net" is a member of mqm and I do have the default Block User List for *MQADMIN.
I don't see how to define exceptions in the Block User List?
How could I set up a rule excempting "srvWMQ-test@irdom.net" from this blocking?
Regards Jan |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Oct 15, 2014 5:48 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
There might already be a rule - I think Broker is supposed to create one.
But basically you create another BLOCKUSER chlauth that is more specific than "*" - perhaps as specific as 'SYSTEM.BROKER.CONFIG", and then you *don't* block the users you want to allow to connect.
Or you only block a user that doesn't exist. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Wed Oct 15, 2014 5:52 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
And don't use any object that starts with SYSTEM.* and instead create a specific channel for Broker Admins and/or developers.
On the new channel, create a rule specific to this channel to block an ID that is not one you wish to allow (like USERLIST('NoBody')). This effectively let's everybody use this channel except the ID listed (which should not exist). Then you need to secure the channel with SSL or more specific rules or other techniques. |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Oct 15, 2014 5:56 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
|
| Back to top |
|
|
| JanB_193 |
| Posted: Wed Oct 15, 2014 6:29 am Post subject: |
|
|
Novice
Joined: 22 Aug 2014
Posts: 15
|
Thanks for the answers, but I'm not sure I understand this right?
You both suggest I define a BLOCKING rule on a specific channel with a USERLIST containing a user which does not exist and thus all other users can use the channel?
I would assume it to be straight forward to first block all access and then specifically allow Access for known users. And I thought that's what I did with my mqsc script. But presumably I'm wrong?
I also thought that the rules where applied from generic to specific, so that a specific rule of a user would override the general blocking of MQADMIN users.
Am I really missunderstanding this completely?
Sorry for beeing slow in understanding
Regards Jan |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Oct 15, 2014 6:51 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| JanB_193 wrote: |
| I would assume it to be straight forward to first block all access and then specifically allow Access for known users. And I thought that's what I did with my mqsc script. But presumably I'm wrong? |
There is no antidote to the TYPE(BLOCKUSER) rule. By that I mean that there is no TYPE(ALLOWUSER) rule.
| JanB_193 wrote: |
| I also thought that the rules where applied from generic to specific, so that a specific rule of a user would override the general blocking of MQADMIN users. |
What you say is true among the various TYPE(xxxMAP) rules. The BLOCKUSER rule is applied at a much later point in the channel's start-up processing, almost at the end of start-up - once everything that can have a go at setting the MCAUSER has had a go.
Within BLOCKUSER rules themselves, more specific ones apply, which is why the described technique works as an over-ride.
Sorry that it's complicated!
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| JanB_193 |
| Posted: Thu Oct 16, 2014 1:30 am Post subject: |
|
|
Novice
Joined: 22 Aug 2014
Posts: 15
|
First of all, thanks for all the replies! 
And I think I got it now! 
What I did:
1. define a Server Connection Channel <QM>.BKR.CONFIG w/o a MCAUSER defined
2. delete MCUSER on SYSTEM.BKR.CONFIG as well as all custom CHLAUTH records created during my previous attempts 
3. delete the blocking rule for *MQADMIN
4. run the following mqsc commands:
ALTER QMGR CHLAUTH(ENABLED)
SET CHLAUTH(*) TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS)
SET CHLAUTH(<QM>.BKR.CONFIG) TYPE(USERMAP) CLNTUSER('<User>') MCAUSER('<Service ID of WMQ>') ACTION(REPLACE)
REFRESH SECURITY(*)
5. make sure that <User> is not a member of mqm or mqbrks
6. create a .broker Connection Profile with the new channel name
Now a connection with the .Broker works whereas a "undefined" connection will fail with a RC 2035 as the SYSTEM.BKR.CONFIG is locked down, what is what I wanted to achieve.
Do you consider this to be a reasonably secure solution?
Regards Jan |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Oct 16, 2014 3:24 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Jan,
Put some useful information in the Description field of those CHLAUTH rules. You'll thank yourself a year from now when your looking at them and wondering what the heck you intended to do with these rules.
The REFRESH SECURITY command was not needed, unless you made changes to group memberships in step #5, in which case the refresh would have had to occur after step #5.
While the backstop rule will prevenet anyone from using those channels, its best practice to not leave the MCAUSERs blank. Put some ID in there that will fail, that way if the CHLAUTH gets disabled by mistake or someone defines an additional incorrect rule that screws the first rule up, the bogus MCAUSER value still protects the channel. Mayeb use something like "WILL_BE_MAPPED" as the value in the MCAUSER as that gives a hint as to how the ID will actually be set and used for that channel. On the SYSTEM.* channel, I use something like "BOGUS_ID_xx" where xx is a unique number per SYSTEM channel. When someone tries to use that channel the error in the log or Authority Event includes the unique BOGUS_ID_xx name and helps identify which channel was attempted.
I would not map to the service account of MQ. Because now you can have have multiple people all connected to that channel (assuming you'll add additional CHLAUTH rules for other team members), all mapped to the same generic ID. Makes it tougher to determine who did what when things go wrong. But if you are going to be the only one for now I guess its OK.
As its relatively easy to pretend to be CLNTUSER('<User>'), this is not the most secure solution, but way better than nothing. I assume in your company someone impersonating another person's User ID is a fireable offense, so the good guys probably won't try that stunt. But the bad guys you are trying to protect against probably don't care about this.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| JanB_193 |
| Posted: Thu Oct 16, 2014 4:03 am Post subject: |
|
|
Novice
Joined: 22 Aug 2014
Posts: 15
|
Hi Pete
Thanks for the comments! I adjusted my settings according to your advice. However this statement leads to another question:
| PeterPotkay wrote: |
I would not map to the service account of MQ. Because now you can have have multiple people all connected to that channel (assuming you'll add additional CHLAUTH rules for other team members), all mapped to the same generic ID. Makes it tougher to determine who did what when things go wrong. But if you are going to be the only one for now I guess its OK.
|
We are actually three persons working with the Broker. I did this for all of us because I did not want to have us all in the group mqm.
How would you suggest to approach this?
Cheers Jan |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Thu Oct 16, 2014 5:14 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
| JanB_193 wrote: |
Hi Pete
Thanks for the comments! I adjusted my settings according to your advice. However this statement leads to another question:
| PeterPotkay wrote: |
I would not map to the service account of MQ. Because now you can have have multiple people all connected to that channel (assuming you'll add additional CHLAUTH rules for other team members), all mapped to the same generic ID. Makes it tougher to determine who did what when things go wrong. But if you are going to be the only one for now I guess its OK.
|
We are actually three persons working with the Broker. I did this for all of us because I did not want to have us all in the group mqm.
How would you suggest to approach this?
Cheers Jan |
Jan,
It depends, 
Are the three of you also MQ Admins? If yes, then mapping to mqm or the Qmgr's service ID (Windows) is fine because you actually do want only those permissions by default.
Are the three of you just Broker Admins? Just Broker developers?
Unfortunately, you have to read this section of the manual to get the right mixture of permissions depending on the role.
Remember that when granting permissions there are the:
- Result - "The intended permission"
- Side effects - "The implicit permissions"
My bottom line about identity is, if I need to know you are who you say you are, then SSL is the requirement. |
|
| Back to top |
|
|
| JanB_193 |
| Posted: Thu Oct 16, 2014 5:28 am Post subject: |
|
|
Novice
Joined: 22 Aug 2014
Posts: 15
|
Joseph, Peter,
Thanks a lot - now I'm a happy sailor - we're all MQ and Broker Administrators, so with this setup we should be fine!
I'm new in this shop and until now there was no security here whatsoever...  so the situation is already a lot better now, even though some of my colleagues find it a nuisance... 
Cheers Jan |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Oct 16, 2014 5:55 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| JanB_193 wrote: |
| I'm new in this shop and until now there was no security here whatsoever... so the situation is already a lot better now, even though some of my colleagues find it a nuisance... |
Well done you! At least they listened and allowed you to lock it down.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Thu Oct 16, 2014 6:22 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
If you want stuff that happens over that channel all to appear to have been done by the same ID, then map it to a generic ID. For a channel I use for pure MQ Admin, I want it mapped to the MQ ID, because I want all new objects created to be owned by the MQ ID and not some person's ID who may not be here a year from now.
So what types of things are going to occur over this channel? Odds are you do not need to have full blown mqm access.
Create a group, put these peopel in that group, assign that group only the permissions they need to do their WMB work, and let the work happen as their actual IDs. Then you can see who stopped a flow, who did a deploy, etc.
We use the MQAUSX exit from Capitalware to force the user to identify themselves, and then their membership (or not) in that group to determine what they can do to WMB. I do not need / want my WMB guys with full MQ access!
Here is an example of the group permissions needed for a WMB super user, but keeping them out of MQ
| Code: |
setmqaut -m QMname -t qmgr -g wmbgroup -all +connect +inq
setmqaut -m QMname -n 'SYSTEM.BROKER.DEPLOY.QUEUE' -t queue -g wmbgroup -all +put
setmqaut -m QMname -n 'SYSTEM.BROKER.DEPLOY.REPLY' -t queue -g wmbgroup -all +put +get
setmqaut -m QMname -n 'SYSTEM.BROKER.AUTH' -t queue -g wmbgroup -all +inq
The following command grants this team access to all Execution Groups current and future.
setmqaut -m QMname -n 'SYSTEM.BROKER.AUTH.*' -t queue -g wmbgroup -all +put +inq +set
For access via MB Explorer, also add this:
setmqaut -m QMname -n 'SYSTEM.MQEXPLORER.REPLY.MODEL' -t queue -g wmbgroup -all +inq
|
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
