| Author |
Message
|
| ivanachukapawn |
 Posted: Mon Feb 23, 2015 8:58 am Post subject: MQ7.5.0.4 CHLAUTH enabled non-privileged user connection |
 |
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| On a 7.5.0.4 queue manager with CHLAUTH enabled, user XYZ can connect to queue managers via configured SVRCONN and no CHLAUTH records are present to authenticate XYZ. User XYZ has OAM authorization to connect and to access specific application queues. I was surprised to see that non-privileged user XYZ could connect to a queue manager without any CHLAUTH authentication records. Is this working as designed? |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Mon Feb 23, 2015 9:20 am Post subject: Re: MQ7.5.0.4 CHLAUTH enabled non-privileged user connection |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| ivanachukapawn wrote: |
| Is this working as designed? |
Yes.
Unless you can point to a CHLAUTH rule defined on your QM that blocks access. But if there is no such rule defined, a wide open channel is just that, wide open. Just because the QM's CHLAUTH attribute is on doesn't mean boo. Its the CHLAUTH rules that make the magic happen.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Mon Feb 23, 2015 11:54 am Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
Peter, you say
| Quote: |
| Unless you can point to a CHLAUTH rule defined on your QM that blocks access |
. Could you clarify? If I have a CHLAUTH record which maps a specified user on a specified channel, is there not an implicit block on other users connecting using that channel? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Feb 23, 2015 12:02 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| ivanachukapawn wrote: |
Peter, you say
| Quote: |
| Unless you can point to a CHLAUTH rule defined on your QM that blocks access |
. Could you clarify? If I have a CHLAUTH record which maps a specified user on a specified channel, is there not an implicit block on other users connecting using that channel? |
No.
You need to tag the MCAUSER on that channel with a bogus ID so that if your CHLAUTH rule doesn't kick in, the channel tries to run as the bogus ID and fails.
And / Or create the backstop rule (see Morag's blog post referenced frequently) that blocks all connections by default.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Mon Feb 23, 2015 12:07 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| granted - I could populate MCAUSER with "nobody" or put in a blocking rule. But if I did neither, wouldn't a CHLAUTH record which maps a specific user for access to a channel implicitly invoke a BLOCK for any other than that user? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Feb 23, 2015 1:02 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| ivanachukapawn wrote: |
| granted - I could populate MCAUSER with "nobody" or put in a blocking rule. But if I did neither, wouldn't a CHLAUTH record which maps a specific user for access to a channel implicitly invoke a BLOCK for any other than that user? |
Nope.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Mon Feb 23, 2015 1:13 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
If I understand your "nope", wouldn't this mean that a CHLAUTH record mapping user XYZ for access to SVRCONN1 would be completely unnecessary since user XYZ could connect to SVRCONN1 anyway because there would be no blocking CHLAUTH record and SVRCONN1 would be "open" as CHLAUTH doesn't mean "boo"
| Quote: |
| Unless you can point to a CHLAUTH rule defined on your QM that blocks access |
|
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 23, 2015 1:19 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
CHLAUTH is configured by default to block system channels and mq admin access.
It's not configured by default to block access to your user defined channels or your local users. |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Mon Feb 23, 2015 1:30 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
Jeff,
but I'm talking about CHLAUTH record mapping XYZ to SVRCONN1 (which is not a SYSTEM channel and the user XYZ is a non-privileged user). So Peter has said that
| Quote: |
| Unless you can point to a CHLAUTH rule defined on your QM that blocks access . . . . if there is no such rule defined, a wide open channel is just that, wide open. |
The channel should be wide open for use by user XYZ with no CHLAUTH record mapping user XYZ. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Feb 23, 2015 1:33 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mqjeff wrote: |
CHLAUTH is configured by default to block system channels and mq admin access.
It's not configured by default to block access to your user defined channels or your local users. |
Lets be even more specific: CHLAUTH is configured by default to block system channels (except system.admin.svrconn) and privileged user access.
Admin access can be achieved with a non privileged user. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 23, 2015 1:34 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If you have a properly configured CHLAUTH Usermap rule that says that everyone who comes in to channel SRVCONN1 should be turned into MCAUSER XYZ.
Easiest way to find out if that's true is to block XYZ from some object, and try and use that object over the SVRCONN.
CHLAUTH rules don't say "the user being presented MUST be user XYZ".
For that you need CONNAUTH. |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Mon Feb 23, 2015 1:40 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
| I have been searching this thread for an explanation of this communications disconnect. I have been asking about a CHLAUTH record for a non-system channel and a non-privileged user - and trying to make sense of Peter's replies reference to this. Last two posts are clarifying CHLAUTH defaults for blocking privileged user access and SYSTEM channels. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Feb 23, 2015 1:44 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Have you read Morag's post on the "backstop rule?"
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Feb 23, 2015 1:47 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Ok.
I'm talking about defaults and system objects because I'm trying to explain further about Peter's response.
To be a little more clear, I hope.
By default, user defined channels and non-admin users are wide open.
If you want to limit a user defined channel, you must create rules that explicitly block or map those things that you want to block or map.
In addition, CHLAUTH user do not insist that an incoming user is a specific user. They only allow you to decide what to do with a particular incoming user - block it, map it, or ignore it (ignored by default).
So if you create a svrconn SVRCONN1, and you create no CHLAUTH rules for it, and you set MQ authorities for a user XYZ, then anyone coming into SVRCONN1 is able to connect, regardless of what user they are (unless they are an administrative user). They are then allowed to do whatever the user they are running as can connect. Anyone coming in as XYZ is able to do whatever XYZ can do.
You can create a CHLAUTH rule that says "Anyone who comes into SVRCONN1 will be turned into user XYZ".
You can not create a CHLAUTH Rule that says "The only people who can connect to SVRCONN1 are user XYZ" - not directly at least. |
|
| Back to top |
|
|
| ivanachukapawn |
| Posted: Mon Feb 23, 2015 2:11 pm Post subject: |
|
|
Knight
Joined: 27 Oct 2003
Posts: 561
|
mqjeff,
mqsc for CHLAUTH (non system channel SVRCONN1 and non-privileged user XYZ) =
SET CHLAUTH(SVRCONN1) TYPE(USERMAP) CLNTUSER('XYZ') \
DESCR('app user') USERSRC(MAP) MCAUSER('XYZ') \
ACTION(ADD)"
note: this map is to MCAUSER ('XYZ') because the channel is configured with MCAUSER = "nobody" - needs to be overridden.
I thought that this rule is setting up permission for user XYZ to connect to SVRCONN1. This now appears to be a misconception since SVRCONN1 is wide open anyway. I guess this rule is completely unnecessary - like a NOOP.
I looked for "backstop rule" by Morag but got not found. Do you have a link? |
|
| Back to top |
|
|
|
|
