| Author |
Message
|
| Prashantzmq |
 Posted: Thu Mar 15, 2018 2:19 am Post subject: CHLAUTH on z/os |
 |
|
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 |
|
 |
| exerk |
| Posted: Thu Mar 15, 2018 2:45 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
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 |
|
|
| bruce2359 |
| Posted: Thu Mar 15, 2018 4:32 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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.
_________________
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: Thu Mar 15, 2018 8:49 pm Post subject: Re: CHLAUTH on z/os |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
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 |
|
|
| Prashantzmq |
| Posted: Fri Mar 16, 2018 12:17 am Post subject: |
|
|
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 |
|
|
| Prashantzmq |
| Posted: Fri Mar 16, 2018 12:21 am Post subject: |
|
|
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 |
|
|
| hughson |
| Posted: Fri Mar 16, 2018 12:32 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
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 |
|
|
| Prashantzmq |
| Posted: Fri Mar 16, 2018 12:43 am Post subject: |
|
|
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 |
|
|
| hughson |
| Posted: Fri Mar 16, 2018 1:45 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
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 |
|
|
| Prashantzmq |
| Posted: Fri Mar 16, 2018 2:54 am Post subject: |
|
|
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 |
|
|
| hughson |
| Posted: Fri Mar 16, 2018 3:54 am Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
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 |
|
|
| Prashantzmq |
| Posted: Fri Mar 16, 2018 4:31 am Post subject: |
|
|
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 |
|
|
| bruce2359 |
| Posted: Fri Mar 16, 2018 6:11 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
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.
_________________
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 |
|
|
| cicsprog |
| Posted: Thu Aug 08, 2019 9:29 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
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 |
|
|
| cicsprog |
| Posted: Thu Aug 08, 2019 10:47 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
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 |
|
|
|
|
