| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Channel auth causes MQC 2035 but not authevent message |
« View previous topic :: View next topic » |
| Author |
Message
|
| zpat |
 Posted: Thu Oct 19, 2017 5:02 am Post subject: Channel auth causes MQC 2035 but not authevent message |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
MQ 7108 on Linux
| Quote: |
AMQ9777: Channel was blocked
EXPLANATION:
The inbound channel 'SYSTEM.DEF.SVRCONN' was blocked from address
'10.nn.nn.nnn' because the active values of the channel matched a record
configured with USERSRC(NOACCESS). The active values of the channel were 'CLNTUSER()'.
|
This cause the connection attempt to fail with MQRC 2035 (Not Auth) - however no event message was produced despite authority events being enabled.
Any ideas why no event message?
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
 |
| hughson |
| Posted: Sat Oct 21, 2017 7:59 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
CHLAUTH events are controlled by the CHLEV switch - they are channel events rather than Not Auth events.
Use the following command:-
| Code: |
| ALTER QMGR CHLEV(EXCEPTION) |
and you will see the MQRC_CHANNEL_BLOCKED event messages.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| zpat |
| Posted: Sat Oct 21, 2017 10:37 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Thanks, it would be more logical (in a sense) to have one event queue for all NOT AUTH MQRC 2035 type events......
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| hughson |
| Posted: Sat Oct 21, 2017 3:00 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
Normally with events, the reason code returned to the application matches the event, and then events are grouped accordingly. I suspect if the reason code given to the application was MQRC_CHANNEL_BLOCKED then it might have been more obvious that it was a different style of event, in the same way that if the reason code was MQRC_PUT_INHIBITED you'd know to look for Inhibit Events.
In the case of security failures, while detailed information is written in the event message and in the queue manager error log, the same is not true for the client end of the connection. It is simply told "Computer says No for security reasons" and no more detail than that. The reasoning here being that to give different reason codes for different types of errors gives a would be hacker information about what piece of security he is trying to hack.
MQ was already dishing out MQRC_NOT_AUTHORIZED prior to the invention of CHLAUTH, so it was adopted as the "No for security reasons" reason code.
Hope that helps,
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| 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
|
|
|
|
