| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Enable CONNAUTH selectively? z/OS v9.0 |
« View previous topic :: View next topic » |
| Author |
Message
|
| zpat |
 Posted: Mon Nov 22, 2021 5:47 am Post subject: Enable CONNAUTH selectively? z/OS v9.0 |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
z/OS MQ v9.0
We would like to enforce authentication for some userids and not others when connecting by SVRCONN channels.
So if someone tried to use any channel which mapped to mcauser = spartcus then we would require a valid OS (RACF) password (or some other means of authentication). But if not spartcus then it would not need a password.
We can't have all ids requiring authentication as it would break 95% of existing connections.
Does CONNAUTH offer any granularity or have IBM delivered an impractical solution to the (long standing) requirement?
CHCKCLNT(REQDADM) would seem ideal, but once again z/OS MQ is the poor relation and does not allow a definition of what are the MQ admin ids.
How can we achieve something like the effect of CHCKCLNT(REQDADM) on the olde worlde mainframe? 
_________________
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 |
|
 |
| RogerLacroix |
| Posted: Mon Nov 22, 2021 4:13 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
To my knowledge, you cannot do what you are requesting because the CONNAUTH attributes apply to all channels, you cannot selectively have some check UserId and Password while others do not.
<Vendor_Plug>
If you want to look at 3rd party solutions, then have a look at Capitalware's MQ Authenticate User Security Exit for z/OS (z/MQAUSX).
z/MQAUSX can do it. Basically, you will have 1 configuration file (IniFile) for authentication and 1 for non-authentication and you would set the appropriate IniFile in the channel's SCYDATA field.
Capitalware offers free trials and free support for all of its products. Just send an email to support@capitalware.com to have a trial.
</Vendor_Plug>
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Nov 22, 2021 9:06 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I beg to differ here. You can. It all has to do with a combination of connauth and chlauth records.
Say you set the conauth to optional or none, but set the corresponding chlauth to required or required admin....
What you cannot do is make it selective by user id. Although you might if the number is not big and you create enough chlauth records... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Nov 23, 2021 1:40 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
Thanks. I will think about both of these.
I suspect even CONNAUTH as OPTIONAL would break existing connections where applications have historically supplied passwords which were never checked and will not be valid.
One issue (at least to auditors) is that those with MQ admin access could define their own channel to bypass any CHLAUTH controls. I know it's curious to try to protect MQ against those with admin rights - but access to "privileged" (Breakglass) RACF ids by MQ is the issue here.
I could RFE to request z/OS MQ to allow the definition of those ids which could then be subject to additional connection checking. However I would probably be retired long before it was coded, released and implemented by us.....
Seems a big omission by IBM to make it all or nothing though by userid.
_________________
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 |
|
|
| fjb_saper |
| Posted: Fri Nov 26, 2021 8:50 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| zpat wrote: |
Thanks. I will think about both of these.
I suspect even CONNAUTH as OPTIONAL would break existing connections where applications have historically supplied passwords which were never checked and will not be valid.
One issue (at least to auditors) is that those with MQ admin access could define their own channel to bypass any CHLAUTH controls. I know it's curious to try to protect MQ against those with admin rights - but access to "privileged" (Breakglass) RACF ids by MQ is the issue here.
I could RFE to request z/OS MQ to allow the definition of those ids which could then be subject to additional connection checking. However I would probably be retired long before it was coded, released and implemented by us.....
Seems a big omission by IBM to make it all or nothing though by userid. |
Not quite if you have the default chlauth record with "*MQADMIN" it effectively forces "privileged users" to authenticate.
Now you could set up admins as non privileged users...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| zpat |
| Posted: Sat Nov 27, 2021 1:34 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| Quote: |
USERLIST
A list of up to 100 user IDs which are banned from use of this channel or set of channels. Use the special value *MQADMIN to mean privileged or administrative users. The definition of this value depends on the operating system, as follows:
[Windows]On Windows, all members of the mqm group, the Administrators group and SYSTEM.
[AIX][Linux]On AIX® and Linux®, all members of the mqm group.
[IBM i]On IBM i, the profiles (users) qmqm and qmqmadm and all members of the qmqmadm group, and any user defined with the *ALLOBJ special setting.
[z/OS]On z/OS, the user ID that the channel initiator, queue manager and advanced message security address spaces are running under. |
Apparently on z/OS - no humans are MQ administrators 
_________________
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 |
|
|
| bruce2359 |
| Posted: Sat Nov 27, 2021 11:07 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| zpat wrote: |
| Apparently on z/OS - no humans are MQ administrators |
CHIN is a service provider to the QMGR. Apps do not connect to the CHIN address space.
I can attest to the (lack of) humanity of z/OS sysprogs.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| hughson |
| Posted: Sun Nov 28, 2021 7:17 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| zpat wrote: |
| Quote: |
USERLIST
A list of up to 100 user IDs which are banned from use of this channel or set of channels. Use the special value *MQADMIN to mean privileged or administrative users. The definition of this value depends on the operating system, as follows:
[Windows]On Windows, all members of the mqm group, the Administrators group and SYSTEM.
[AIX][Linux]On AIX and Linux, all members of the mqm group.
[IBM i]On IBM i, the profiles (users) qmqm and qmqmadm and all members of the qmqmadm group, and any user defined with the *ALLOBJ special setting.
[z/OS]On z/OS, the user ID that the channel initiator, queue manager and advanced message security address spaces are running under. |
Apparently on z/OS - no humans are MQ administrators |
The special value *MQADMIN captures the set of user ids that are likely to have access to resources you wouldn't want remote clients having access to. In the case of distributed platforms, this is the set of privileged user ids - you certainly wouldn't want a remote client application being able to assert, without proof, that it wanted to run as one of these. On z/OS there is no such thing as a privileged user id for MQ, but the address space user IDs may well have access to various queues that you would not want remote client applications having access to, so these user ids are treated in the same way as privileged users.
| fjb_saper wrote: |
| Now you could set up admins as non privileged users... |
You certainly can - see Blog Post: A non-privileged MQ administrator
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Nov 30, 2021 4:59 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
IBM have a long and glorious tradition of delivering a solution that is almost, but not quite, ready for the real-world.
Still it has given employment to thousands of Sysprogs over the years (including myself).. 
Not forgetting some very nice add-on vendor products....
_________________
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 |
|
|
|
|
|
| |
|
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
|
|
|
|
