|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
CHLAUTH rule change giving 2035 with CHLAUTH WARN(yes) set ? |
« View previous topic :: View next topic » |
Author |
Message
|
smeunier |
Posted: Wed Nov 18, 2015 10:21 am Post subject: CHLAUTH rule change giving 2035 with CHLAUTH WARN(yes) set ? |
|
|
 Partisan
Joined: 19 Aug 2002 Posts: 305 Location: Green Mountains of Vermont
|
I recently implemented a change to tighten up some SVRCONN channel security. I set the MCAUSER channel property to MCAUSER('*NOACCESS') on my SVRCONN channels.
I then implemented a CHLAUTH rule like the following as a gloal block for each SVRCONN channel:
SET CHLAUTH('TEST.SVRCONN') TYPE(BLOCKUSER) USERLIST('*NOACCESS') DESCR('Block all access on this channel') WARN(YES) ACTION(ADD)
I then granted some access:
SET CHLAUTH('TEST.SVRCONN') TYPE(USERMAP) CLNTUSER('mquser') USERSRC(MAP) MCAUSER('mquser') ADDRESS('129.*') DESCR('All Access') ACTION(ADD)
What happened when a user that did no match the rule, I received a Channel Blocked Event Message and a MQ 2035 would be returned to the client. I would have fully expected that I should have gotten a "Channel Blocked Warning" message only.
This was a surprise and has cause some implementation issues. My question is, why a 2035, and not a "Channel Blocked Warning" message, which is what I need to see. |
|
Back to top |
|
 |
fjb_saper |
Posted: Wed Nov 18, 2015 9:40 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
You did not specify your version
However I don't think that the following code does what you think it does:
Code: |
SET CHLAUTH('TEST.SVRCONN') TYPE(BLOCKUSER) USERLIST('*NOACCESS') DESCR('Block all access on this channel') WARN(YES) ACTION(ADD)
|
Check it out with
Code: |
dis chlauth(test.svrconn) type(all) match(runcheck) ... |
Instead of blocking everything I'd expect it to allow privileged access
This is an example of blocking everybody on your channel
Code: |
SET CHLAUTH(TEST.SVRCONN) TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS) WARN(YES) ACTION(ADD) |
 _________________ MQ & Broker admin |
|
Back to top |
|
 |
smeunier |
Posted: Thu Nov 19, 2015 6:45 am Post subject: |
|
|
 Partisan
Joined: 19 Aug 2002 Posts: 305 Location: Green Mountains of Vermont
|
Quote: |
You did not specify your version |
MQVersion 7.5.3
Quote: |
However I don't think that the following code does what you think it does: |
Perhaps my comment in the CHLAUTH command was mis-leading. The intent was to define SVRCONN channels with a MCAUSER(*NOACCESS) and to then block the use of that channel to that user with a CHLAUTH definition like I had stated, unless a rule is in place to override it. In practice, this works just fine, although just having a universal block on the channel as you suggested perhaps would be less work(i.e not having to set the SVRCONN channel's to *NOACCESS).
What became a problem, is when no CHLAUTH definition was in place with a overriding MCAUSER. This yielded a MQRC 2035 with a Event Message of "Channel Blocked", even though I had WARN(YES) enabled on the CHLAUTH definition to blockaccess. The 2035 caused failure at the client end, rather than alert me that I didn't have a rule that matched, which was the intended result (so much for slipping something in undetected!). The 2035 situation is what I'm trying to avoid in lieu of a warning. |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Nov 19, 2015 11:46 am Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
Well if you define the SVRCONN with an MCAUSER that has no access, everybody will get a 2035, unless they are hitting a rule mapping their user to an authorized MCAUSER. This has nothing to do with chlauth but everything to do with setmqaut... 2 different animals and you can mix and match...  _________________ MQ & Broker admin |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
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
|
|
|
|