ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Security » Enable CONNAUTH selectively? z/OS v9.0

Post new topic  Reply to topic
 Enable CONNAUTH selectively? z/OS v9.0 « View previous topic :: View next topic » 
Author Message
zpat
PostPosted: Mon Nov 22, 2021 5:47 am    Post subject: Enable CONNAUTH selectively? z/OS v9.0 Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
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
View user's profile Send private message
RogerLacroix
PostPosted: Mon Nov 22, 2021 4:13 pm    Post subject: Reply with quote

Jedi Knight

Joined: 15 May 2001
Posts: 3252
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
View user's profile Send private message Visit poster's website
fjb_saper
PostPosted: Mon Nov 22, 2021 9:06 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
zpat
PostPosted: Tue Nov 23, 2021 1:40 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
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
View user's profile Send private message
fjb_saper
PostPosted: Fri Nov 26, 2021 8:50 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
zpat
PostPosted: Sat Nov 27, 2021 1:34 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
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
View user's profile Send private message
bruce2359
PostPosted: Sat Nov 27, 2021 11:07 am    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
hughson
PostPosted: Sun Nov 28, 2021 7:17 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
zpat
PostPosted: Tue Nov 30, 2021 4:59 am    Post subject: Reply with quote

Jedi Council

Joined: 19 May 2001
Posts: 5849
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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ Security » Enable CONNAUTH selectively? z/OS v9.0
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.