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 IndexIBM MQ SecurityCHLAUTH on z/os

Post new topicReply to topic Goto page 1, 2  Next
CHLAUTH on z/os View previous topic :: View next topic
Author Message
Prashantzmq
PostPosted: Thu Mar 15, 2018 2:19 am Post subject: CHLAUTH on z/os Reply with quote

Newbie

Joined: 15 Mar 2018
Posts: 6

Hi All,

I am trying the below command to block the SVRCONN channel from connecting the queue manager.But it does't seem to work.It allows the connection to go through.

ALTER QMGR CHLAUTH(ENABLED)
SET CHLAUTH('SYSTEM.DEF.SVRCONN') TYPE(BLOCKUSER) USERLIST('XXXXXXX')

where XXXXXXX is the qmgr and chinit address space started task user id.

The connection is being tried using user id-YYYYYYY.

Any help is much appreciated.

TIA
Back to top
View user's profile Send private message
exerk
PostPosted: Thu Mar 15, 2018 2:45 am Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6103

Moved to the Security forum.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys.

Back to top
View user's profile Send private message
bruce2359
PostPosted: Thu Mar 15, 2018 4:32 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8498
Location: US: west coast, almost. Otherwise, enroute.

Are you new to z/OS and IMQ on z/OS? I'm guessing yes to both.

IMQ security is far more complicated on z/OS. You will need to visit with your RACF (or ACF/TopSecret) system programmers.

Address space ids of QMGR and CHIN are controlled by the MQCONN class, and not by BLOCKUSER and USERLIST.

Channels are processes running in the CHIN address space. channels do not connect to qmgrs.
_________________
There are two types of people in this world:
1) Those that can extrapolate from incomplete data
Back to top
View user's profile Send private message
hughson
PostPosted: Thu Mar 15, 2018 8:49 pm Post subject: Re: CHLAUTH on z/os Reply with quote

Grand Master

Joined: 09 May 2013
Posts: 1253
Location: Bay of Plenty, New Zealand

Prashantzmq wrote:
I am trying the below command to block the SVRCONN channel from connecting the queue manager.But it doesn't seem to work.It allows the connection to go through.

ALTER QMGR CHLAUTH(ENABLED)
SET CHLAUTH('SYSTEM.DEF.SVRCONN') TYPE(BLOCKUSER) USERLIST('XXXXXXX')

where XXXXXXX is the qmgr and chinit address space started task user id.

The connection is being tried using user id-YYYYYYY.


If the connection is being tried using user id YYYYYYY then it won't match XXXXXXX so that rule won't apply, or am I missing some link between XXXXXXX and YYYYYYY?

Also the pre-installed CHLAUTH rule of TYPE(BLOCKUSER) which has USERLIST(*MQADMIN) already blocks the started task user IDs of the MSTR and CHIN address spaces, so you don't need to add another rule for that.

Have you by any chance removed the default rules? The reason I ask is that SYSTEM channels are also blocked by the pre-installed rules, so your channel shouldn't run for that reason too.

Perhaps you can show us the output of DISPLAY CHLAUTH(*) ALL on your system?

bruce2359 wrote:
Address space ids of QMGR and CHIN are controlled by the MQCONN class, and not by BLOCKUSER and USERLIST.

The user ids that ths MSTR and CHIN started tasks run under can still be added to BLOCKUSER and USERLIST rules if you want - they are still user ids in the system after all. Although you don't need to if you have the *MQADMIN rule in place as noted above.

bruce2359 wrote:
Channels are processes running in the CHIN address space. channels do not connect to qmgrs.

Channels do connect to the queue manager - you can see this if you use the DISPLAY CONN command - they do so in order to open queues, and put or get messages.

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
Prashantzmq
PostPosted: Fri Mar 16, 2018 12:17 am Post subject: Reply with quote

Newbie

Joined: 15 Mar 2018
Posts: 6

Thanks for the input.

I understand that CHNIT connects to QMGR via adapter TCB.That is channels make the MQ API call's via these adapter tasks(CHIADAPS).

The default CHLAUTH rules that are in place have been removed to test various CHLAUTH rules or scenarios provided in MQ v7.1.Hence currently the only CHLAUTH rule that is in place is as below:

CSQM293I MQXX CSQMDRTC 1 CHLAUTH FOUND MATCHING REQUEST CRITERIA
CSQM201I MQXX CSQMDRTC DISPLAY CHLAUTH DETAILS
CHLAUTH(SYSTEM.DEF.SVRCONN)
TYPE(BLOCKUSER)
USERLIST(
XXXXXXX
)
END CHLAUTH DETAILS

where XXXXXXX is the MQMSTR and MQSCHIN address space user id's.

YYYYYYY is the ID that is being tried to connect to MQ via a client(MO71).I have also tried to put YYYYYYY also in the USERLIST to see if it blocks it, but no luck(disconnected and tried connecting via SVRCONN channel as this type of CHALUTH rule applies only to client channels and not to message channels).

As per the KC -

USERLIST:
On z/OS, the user ID that the channel initiator and queue manager address spaces are running under.

Does *MQADMIN apply on z/OS because I get the below error:

SET CHLAUTH('SYSTEM.DEF.SVRCONN') TYPE(BLOCKUSER) USERLIST(*MQADMIN)

CSQ9006E MQXX 'USERLIST' parameter uses asterisk (*)
incorrectly
CSQ9015E MQXX Parameter '*MQADMIN' is unacceptable for
RESPONSE='USERLIST'
CSQ9023E MQXX CSQ9SCND 'SET CHLAUTH' ABNORMAL COMPLETION


I have another query-is there a way to see the CHLAUTH related messages for successful connections as well,probably some SMF record ?


TIA
Back to top
View user's profile Send private message
Prashantzmq
PostPosted: Fri Mar 16, 2018 12:21 am Post subject: Reply with quote

Newbie

Joined: 15 Mar 2018
Posts: 6

ok,I tried with`*MQADMIN' (it should in quotes !) and the CHALUTH rule is set.But it sill allows connections to go through.
Back to top
View user's profile Send private message
hughson
PostPosted: Fri Mar 16, 2018 12:32 am Post subject: Reply with quote

Grand Master

Joined: 09 May 2013
Posts: 1253
Location: Bay of Plenty, New Zealand

Prashantzmq wrote:
YYYYYYY is the ID that is being tried to connect to MQ via a client(MO71).I have also tried to put YYYYYYY also in the USERLIST to see if it blocks it, but no luck.


Is YYYYYYY the user ID that you are running MO71 under, i.e. the user ID you logged onto Windows with, or is YYYYYYY the user ID you are typing in on the Security tab to go with a password?

Prashantzmq wrote:
I have another query-is there a way to see the CHLAUTH related messages for successful connections as well,probably some SMF record ?


If the channel connects successfully, you will see CSQX511I message in the CHINIT log. It's not CHLAUTH related per se, just a Channel started message (unless you have suppressed them).

If you are unsure what user ID MQ is checking against for your client connect may I suggest the following tactic.

Temporarily set only the following CHLAUTH rule.

Code:
SET CHLAUTH('*') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS)


Then look at the message in the CHINIT JOBLOG for the "Channel is blocked". It will tell you exactly what the CLNTUSER and MCAUSER are for the blocked connection. Then you can make an appropriate rule that will block ONLY that connection.

Post the output here is you want further assistance.

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
Prashantzmq
PostPosted: Fri Mar 16, 2018 12:43 am Post subject: Reply with quote

Newbie

Joined: 15 Mar 2018
Posts: 6

YYYYYYY is the user id that I logged into windows(for connecting from MO71) and it shows in the output also as below:

Removed all existing CHLAUTH rules and then executed the below rule.

SET CHLAUTH('*') TYPE(ADDRESSMAP) ADDRESS('*') USERSRC(NOACCESS)

Tried connecting from MO71 again and below is the error.

+CSQX777E MQxx CSQXRESP Channel SYSTEM.DEF.SVRCONN from vw009999 568
(a.x.y.z) has been blocked due to USERSRC(NOACCESS), Detail:
CLNTUSER(YYYYYYY)

Thanks
Back to top
View user's profile Send private message
hughson
PostPosted: Fri Mar 16, 2018 1:45 am Post subject: Reply with quote

Grand Master

Joined: 09 May 2013
Posts: 1253
Location: Bay of Plenty, New Zealand

Prashantzmq wrote:
+CSQX777E MQxx CSQXRESP Channel SYSTEM.DEF.SVRCONN from vw009999 568
(a.x.y.z) has been blocked due to USERSRC(NOACCESS), Detail:
CLNTUSER(YYYYYYY)

OK so that confirms that the CLNTUSER is YYYYYYY. So a rule like the following should block it.
Code:
SET CHLAUTH(SYSTEM.DEF.SVRCONN) TYPE(USERMAP) CLNTUSER(YYYYYYY) USERSRC(NOACCESS)

However, you are trying to set a TYPE(BLOCKUSER) rule. This rule is different to the mapping rules in that it checks against the MCAUSER assigned to the running channel and of course the MCAUSER can be set a number of ways, not just from the flowed client user ID. If you're interested in all the different ways read All the ways to set MCAUSER.

To see what your MCAUSER ends up as, remove your CHLAUTH rules and connect in your client application, then while it is running issue the following MQSC command.
Code:
DISPLAY CHSTATUS(SYSTEM.DEF.SVRCONN) MCAUSER

If the displayed MCAUSER is different from your CLNTUSER then you have something else setting the MCAUSER and that's why your BLOCKUSER is not working because the MCAUSER has been changed to something else. BLOCKUSER operates on the final value put into MCAUSER.

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
Prashantzmq
PostPosted: Fri Mar 16, 2018 2:54 am Post subject: Reply with quote

Newbie

Joined: 15 Mar 2018
Posts: 6

Hi Morag,

Thanks for your inputs.

Yes,I can confirm that MCAUSER is YYYYYYY and I tried it again as below:

Removed all CHLAUTH rules
SET CHLAUTH('SYSTEM.DEF.SVRCONN') TYPE(BLOCKUSER) USERLIST(YYYYYYY) ACTION(ADD)

It allows the connection to go through.

Thanks
Back to top
View user's profile Send private message
hughson
PostPosted: Fri Mar 16, 2018 3:54 am Post subject: Reply with quote

Grand Master

Joined: 09 May 2013
Posts: 1253
Location: Bay of Plenty, New Zealand

OK. So that should be blocked then.

The only other thing I can think of to look at is to be correct with the case of your user ID. Case matters for CHLAUTH matching.

I get the impression that you may be doctoring your output for our benefit and replacing the actual user ID with YYYYYYY. And that's fine, hiding the specifics of your system is not a problem. However, it may be masking the case of the user ids for us to see.

So perhaps you can try that out and see whether changing the case is what is causing the problem.

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
Prashantzmq
PostPosted: Fri Mar 16, 2018 4:31 am Post subject: Reply with quote

Newbie

Joined: 15 Mar 2018
Posts: 6

I have checked the case -in the output of DIS CHSTATUS it was uppercase and my command also had upper case-confirmed.

Thanks
Back to top
View user's profile Send private message
bruce2359
PostPosted: Fri Mar 16, 2018 6:11 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8498
Location: US: west coast, almost. Otherwise, enroute.

Hmmmm. The label on the meds I'm taking says not to operate heavy equipment. Should be expanded to advise against posting.
_________________
There are two types of people in this world:
1) Those that can extrapolate from incomplete data
Back to top
View user's profile Send private message
cicsprog
PostPosted: Thu Aug 08, 2019 9:29 am Post subject: Reply with quote

Master

Joined: 27 Jan 2002
Posts: 299

Morag

I'm at a client site. ZOS MQMs

The MQMs have this attribute on the QMANAGER:

CONNAUTH('USE.PW')

And then this Object:

DEFINE NOREPLACE
AUTHINFO('USE.PW')
AUTHTYPE(IDPWOS)
QSGDISP(QMGR)
ADOPTCTX(NO)
CHCKCLNT(OPTIONAL)
CHCKLOCL(NONE)
FAILDLAY(10)
DESCR(' ')

I assume its use password but I'm trying to find what USE.PW means or is. Can you set me strait?
I see some articles you've written that use it but I dont get what it is. Is it a RACF resource maybe?

Jason
Back to top
View user's profile Send private message
cicsprog
PostPosted: Thu Aug 08, 2019 10:47 am Post subject: Reply with quote

Master

Joined: 27 Jan 2002
Posts: 299

Ahhh...I found it...good old MO71...its an OBJECT...AUTHINFO

AUTHINFO(USE.PW)
AUTHTYPE(IDPWOS)
QSGDISP(QMGR)
ADOPTCTX(NO)
CHCKCLNT(OPTIONAL)
Back to top
View user's profile Send private message
Display posts from previous:
Post new topicReply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum IndexIBM MQ SecurityCHLAUTH on z/os
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.