| Author |
Message
|
| ivanachukapawn |
 Posted: Mon Apr 15, 2013 9:10 am Post subject: puzzling channel authorization behavior |
 |
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
At least puzzling to me. I am getting this error in the qmgr error log:
| Code: |
The inbound channel 'XYZ.1' was blocked from address
'1.1.14.4' because the active values of the channel were mapped to a
userid which should be blocked. The active values of the channel were
'MCAUSER(mqm) CLNTUSER()'.
|
However, the channel in question has this property setting:
I am able to circumvent this error and get a connection by altering the qmgr to CHLAUTH(DISABLED). The channel authorization records have been left to the default settings as follows:
| Code: |
dis chlauth (*)
2 : dis chlauth (*)
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(CHANNEL)
AMQ8878: Display channel authentication record details.
CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP)
ADDRESS(*) USERSRC(NOACCESS)
AMQ8878: Display channel authentication record details.
CHLAUTH(*) TYPE(BLOCKUSER)
USERLIST(*MQADMIN)
|
What is happening? Why does MQ complain about a MCAUSER('mqm') when that is not the setting? |
|
| Back to top |
|
 |
| Vitor |
| Posted: Mon Apr 15, 2013 9:25 am Post subject: Re: puzzling channel authorization behavior |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| ivanachukapawn wrote: |
| However, the channel in question has this property setting:
|
And if there's no MCAUser explicitly set on the channel, what user id value is going to be used in your example?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Mon Apr 15, 2013 9:35 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| the one transmitted over the channel in the connection request. But that doesn't become a MCAUSER value does it? |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Mon Apr 15, 2013 9:38 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| obviously it does, and so I guess I should conclude that the client was logged in as the 'mqm' user ID. Sorry to have bothered you. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Mon Apr 15, 2013 9:51 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Apr 15, 2013 9:57 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| ivanachukapawn wrote: |
| obviously it does, and so I guess I should conclude that the client was logged in as the 'mqm' user ID. Sorry to have bothered you. |
Or the client is a Java MQ Client, and so is not sending an ID by default, and if the client does not send an ID, and the MCAUSER is blank, the ID the channel defaults to is the ID used to start the channel, which is the ID the MQ Listener was started under, which is typically.......'mqm'.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Apr 15, 2013 10:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| PeterPotkay wrote: |
| ivanachukapawn wrote: |
| obviously it does, and so I guess I should conclude that the client was logged in as the 'mqm' user ID. Sorry to have bothered you. |
Or the client is a Java MQ Client, and so is not sending an ID by default, and if the client does not send an ID, and the MCAUSER is blank, the ID the channel defaults to is the ID used to start the channel, which is the ID the MQ Listener was started under, which is typically.......'mqm'. |
I would have said this is the most likely scenario, and one which could be checked quite simply. But if by one means or another the client is using mqm as an id mystery solved and security rules functioning as designed. 
I agree it's perhaps a little misleading for the message to refer to
as if it's part of the channel definition.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Mon Apr 15, 2013 10:23 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
|
| Back to top |
|
|
| hughson |
| Posted: Thu May 09, 2013 8:12 am Post subject: Re: puzzling channel authorization behavior |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| ivanachukapawn wrote: |
I am getting this error in the qmgr error log:
| Code: |
The inbound channel 'XYZ.1' was blocked from address
'1.1.14.4' because the active values of the channel were mapped to a
userid which should be blocked. The active values of the channel were
'MCAUSER(mqm) CLNTUSER()'.
|
|
A handy guide to how to interpret this error message and find out exactly what CHLAUTH rule is blocking you can be found I'm being blocked by CHLAUTH - how can I work out why?
To answer it for you though, you are being blocked because no CLNTUSER was flowed from the client - hence
and since you have nothing mapping the connection into anything else, the default position is to run that client with an MCAUSER(mqm). Since that's what you ended up with, the default CHLAUTH rule that checks for remote privileged access (the one with *MQADMIN in it) has blocked your channel.
| ivanachukapawn wrote: |
| However, the channel in question has this property setting:
|
This is the definitional setting of MCAUSER, but of course when the channel runs there is also a run-time version of it, since it might be different - it can be changed away from the definitional version by many things, exits, CHLAUTH, or just the flowed client-side user. Thus you can see the run-time version of MCAUSER in DISPLAY CHSTATUS.
| ivanachukapawn wrote: |
| What is happening? Why does MQ complain about a MCAUSER('mqm') when that is not the setting? |
It complains because that is the run-time assignment of MCAUSER. An application or channel, cannot run under no user, so if you leave MCAUSER blank on the channel definition, we have to find something to run it under. The error message is reporting what the MCAUSER was chosen to be prior to it being blocked by one of the default rules.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu May 09, 2013 8:17 am Post subject: Re: puzzling channel authorization behavior |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Thank you for posting this! 
| hughson wrote: |
| ivanachukapawn wrote: |
| However, the channel in question has this property setting:
|
This is the definitional setting of MCAUSER, but of course when the channel runs there is also a run-time version of it, since it might be different - it can be changed away from the definitional version by many things, exits, CHLAUTH, or just the flowed client-side user. Thus you can see the run-time version of MCAUSER in DISPLAY CHSTATUS. |
And thank you sharing this.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu May 09, 2013 8:25 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The fact that the channel defaults to mqm when no client id is sent is the reason that every channel should have an MCAUSER, that is specific to the intended purposes of the channel.
The fact that MQ v7.5 blocked this attempt using the default rules shows you that some thought went into them. We went from "default configuration is wide open to anyone to administer" to "default configuration is only administerable by a local connection".
You now have to take additional steps to make your queue manager completely unsecure.
The easiest fix for this is to create a specific CHLAUTH rule for the XYZ.1 channel that is BLOCKUSER and has USERLIST that specifies only a non-existent user.
The correct fix is to apply MCAUSER to all relevant channels, and configure additional security controls to ensure that access to those channels is appropriately scoped (sslpeer is a reasonable first start, but you could also go for a set of CHLAUTH rules for each channel that managed this instead), and a set of CHLAUTH rules that ensure that the necessary userids in the MCAUSERs were not blocked by default rules. |
|
| Back to top |
|
|
|
|
