| Author |
Message
|
| cicsprog |
 Posted: Tue Sep 03, 2024 2:43 pm Post subject: |
 |
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
This wont paste very well, but here is a display of test messages I put messages to via MQ Console:
Manage
QKSL
Queues
Local Queue: JASON.TEST messages
Actions
3 messages (0%)
Maximum queue depth: 5000000
Clear queue
Refresh
Create
Timestamp
Application ID
User ID
Application data MSG 1
Sep 3, 2024 at 11:00:41 AM
QKSLCHIN
TKMA339
Second Message ADD MSG 2
Sep 3, 2024 at 11:00:25 AM
QKSLCHIN
TKMA339
Add Message Test
Sep 3, 2024 at 10:56:50 AM MSG 3
QKSLCHIN
TKMO008
test with reslevel
What's weird is its my userid TKMO008 in the MQ header that's supposedly the one who created the message - USER. So my RACF userid is somehow getting associated with the message I logged into MQ Console with which is also my TSO userid.
Last edited by cicsprog on Tue Sep 03, 2024 3:04 pm; edited 1 time in total |
|
| Back to top |
|
 |
| cicsprog |
| Posted: Tue Sep 03, 2024 2:53 pm Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
| Morag I sent u a screen shot via MQGEM support email. |
|
| Back to top |
|
|
| hughson |
| Posted: Tue Sep 03, 2024 2:56 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| cicsprog wrote: |
| I think that's an old RACF entry. There is no Q with the name FMNTMQL in QKSL. |
So can you give us an example queue name to work with?
| cicsprog wrote: |
| As I mentioned earlier, I'm pretty sure the msgs from MQ Console are PCF messages. |
The messages coming from MQ Console to display objects will indeed be PCF messages. However now that we're talking about doing MQOPENs to put messages to queues, we won't be using PCF messages.
| cicsprog wrote: |
| Why aren't the RACF rules that I have in place stopping MQOPEN (and other API type opens)? |
You can see why I asked about RESLEVEL now - it does appear like there are no checks being done.
Can you show us a bit more about the resources in your MQQUEUE class - perhaps there is more than you showed in that RACF job in your much much earlier post.
Can you connect a normal client application, simplify things a bit by taking the MQ Console out of the picture for a moment, and just see what happens. Use amqsputc for example, and use a user ID that shouldn't be able to put a message to a queue.
It might also be useful at this point to understand exactly the security in place on your MQ Console? Which type of security is it using (there are various choices - see IBM Docs: Configuring users and roles)?
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| cicsprog |
| Posted: Tue Sep 03, 2024 3:15 pm Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
ok...will mess with tomorrow.
It does seem like RACF isn't getting called for the MQPUT using TKMO008 or MQCONSL userids.
I will try what you suggested. I wish I had a way to trace this. Maybe I can go thru CICS and run cedf with a tiny pgm. Going thru MQ trace might not be great. |
|
| Back to top |
|
|
| cicsprog |
| Posted: Wed Sep 04, 2024 11:45 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
|
| Back to top |
|
|
| cicsprog |
| Posted: Thu Sep 05, 2024 7:04 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
So I reconfigured MO71 for this QManager QKSL to use the same SVRCONN Channel that MQ Console uses to access QKSL.
Initially I got this:
CSQX777E -QKSL CSQXRESP Channel WEBCON.SVRCONN from SPC0W33YY 453
(172.31.88.201) has been blocked due to USERSRC(NOACCESS), Detail:
CLNTUSER(TKMO008)
In addition MO71 would NOT connect
So I added this temporarily:
SET
CHLAUTH('WEBCON.SVRCONN')
ACTION(ADD)
TYPE(USERMAP)
ADDRESS('*')
CHCKCLNT(ASQMGR)
CLNTUSER(
'TKMO008'
)
CUSTOM(' ')
DESCR('MQ WebConsole Access')
MCAUSER('MQCONSL')
USERSRC(MAP)
This allowed me to get MO71 connected.
Thru MO71 I was able to put a message to Queue JASON.TEST
TimeStamp :Sep 5, 2024 at 9:50:14 AM
Application ID: Files\MO71 Test\mqmonntp.exe
USER ID: MQCONSL
Application data: Test message from 'QKSL' using MO71 |
|
| Back to top |
|
|
| cicsprog |
| Posted: Thu Sep 05, 2024 7:20 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
so I changed:
SET
CHLAUTH('WEBCON.SVRCONN')
ACTION(REPLACE)
TYPE(USERMAP)
ADDRESS('*')
CHCKCLNT(ASQMGR)
CLNTUSER(
'TKMO008'
)
CUSTOM(' ')
DESCR('MQ WebConsole Access')
MCAUSER('NORACFID')
USERSRC(MAP)
MO71 connected but nothing worked..just hanged.
Changed CHLAUTH MCA USER to Application RACF USERID:
SET
CHLAUTH('WEBCON.SVRCONN')
ACTION(REPLACE)
TYPE(USERMAP)
ADDRESS('*')
CHCKCLNT(ASQMGR)
CLNTUSER(
'TKMO008'
)
CUSTOM(' ')
DESCR('MQ WebConsole Access')
MCAUSER('TKMA339')
USERSRC(MAP)
Put a message to JASON.TEST from MO71 and MQ Consul and both worked.
So this proves that either there isnt any checking or RACF CLASS(MQQUEUE) is allowing. |
|
| Back to top |
|
|
| cicsprog |
| Posted: Thu Sep 05, 2024 8:24 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
So here is MQQUEUE via RACFADM:
CLASS: MQQUEUE
FILTER: QKSL.**
SELECT: S Show, L List, C Chan
S Profile
-------------------------------
QKSL.*
QKSL.**
QKSL.EP.*
QKSL.ES.CS.*
QKSL.FMNTMQL.**
QKSL.KAX90032
QKSL.PO.*
QKSL.RS.*
QKSL.SYSTEM.**
QKSL.SYSTEM.COMMAND.**
QKSL.SYSTEM.COMMAND.INPUT
QKSL.SYSTEM.CSQOREXX.**
QKSL.SYSTEM.REST.REPLY.QUEUE
QKSL.VN.*
Given the resource rules below, I dont think a RACF check for MQOPEN is being done. The resource rules QKSL.* and QKSL.** have APPL group as NONE
QKSL.*
APPL NONE
LRNAPPL READ
LRNMNGR UPDATE
MIO UPDATE
NSQMVS CONTROL
OPER READ
PKMO ALTER
QAMNGR ALTER
QKMO ALTER
QKSQMSTR ALTER
TKMS ALTER
TKMSSUP ALTER
QKSL.**
APPL NONE
DB2 ALTER
OPER READ
PKMO ALTER
QKSLCHIN ALTER
TKMS ALTER
TMONMQ ALTER
TMQLFS ALTER
QKSL.EP.*
APPL ALTER
LRNAPPL READ
LRNMNGR UPDATE
OPER READ
PKMO ALTER
SACASH ALTER
SACREDIT ALTER
SALEAD ALTER
SAMGR ALTER
TKMS ALTER
TMONMQ ALTER
TMQLFS ALTER
QKSL.ES.CS.*
APPL READ
DCMGMT UPDATE
DCPCALL UPDATE
DCPCNOUP UPDATE
DCPCSUPS UPDATE
DCRCALL UPDATE
DCRVSUPS UPDATE
LRNAPPL READ
LRNMNGR UPDATE
MIOANL UPDATE
MRCHANL UPDATE
MRCHMGR UPDATE
MRCHSANL UPDATE
OPER READ
PKMO ALTER
STDCLMGR UPDATE
TKMS ALTER
TMONMQ ALTER
TMQLFS ALTER
QKSL.FMNTMQL.**
APPL ALTER
DB2 ALTER
MQCONSL ALTER
OPER READ
PKMO ALTER
QKSLCHIN ALTER
TKMS ALTER
TMONMQ ALTER
TMQLFS ALTER
QKSL.KAX90032
APPL READ
LRNAPPL READ
LRNMNGR UPDATE
MIO UPDATE
OPER READ
PKMO UPDATE
TKMS ALTER
TMONMQ UPDATE
TMQLFS UPDATE
QKSL.PO.*
APDIRECT UPDATE
APPL READ
BUYASIST UPDATE
BUYCLER UPDATE
BUYER UPDATE
COMPCLER UPDATE
DCMGMT UPDATE
DCOCALL UPDATE
DCOCNOPO UPDATE
DCOCSUPS UPDATE
DMM UPDATE
DMMCLER UPDATE
GMM UPDATE
LOGMGRS UPDATE
LOGSUPS UPDATE
LOGTECH UPDATE
LRNAPPL READ
LRNMNGR UPDATE
MIO UPDATE
MIOLOG UPDATE
MIOMGR UPDATE
MRCHANL UPDATE
QKSL.RS.*
APPL READ
LRNAPPL READ
LRNMNGR UPDATE
MIO UPDATE
OPER READ
PKMO ALTER
TKMS ALTER
TMONMQ ALTER
TMQLFS ALTER
QKSL.SYSTEM.**
PKMO ALTER
TKMS ALTER
QKSL.SYSTEM.COMMAND.**
APPL ALTER
DB2 ALTER
MQCONSL ALTER
OPER READ
PKMO ALTER
QKSLCHIN ALTER
TKMS ALTER
TMONMQ ALTER
TMQLFS ALTER
QKSL.SYSTEM.COMMAND.INPUT
APPL ALTER
DB2 ALTER
MQCONSL ALTER
OPER READ
PKMO ALTER
QKSLCHIN ALTER
TKMS ALTER
TMONMQ ALTER
TMQLFS ALTER
QKSL.SYSTEM.CSQOREXX.**
APPL ALTER
DB2 ALTER
MQCONSL ALTER
OPER READ
PKMO ALTER
QKSLCHIN ALTER
TKMS ALTER
TMONMQ ALTER
TMQLFS ALTER
QKSL.SYSTEM.REST.REPLY.QUEUE
APPL ALTER
DB2 ALTER
MQCONSL ALTER
OPER READ
PKMO ALTER
QKSLCHIN ALTER
TKMS ALTER
TMONMQ ALTER
TMQLFS ALTER
LRNAPPL READ
LRNMNGR UPDATE
PKMO ALTER
TMONMQ ALTER
TMQLFS ALTER
------------------------------- |
|
| Back to top |
|
|
| cicsprog |
| Posted: Thu Sep 05, 2024 9:06 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
|
| Back to top |
|
|
| cicsprog |
| Posted: Mon Sep 09, 2024 1:04 pm Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
So IBM L2/Security says this fix is NOT ZOS related.
So back to figuring how to make RACF validate the MQOPENS's |
|
| Back to top |
|
|
| cicsprog |
| Posted: Thu Sep 26, 2024 10:06 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
Morag or anyone else
Is there a way in CHLAUTH to dynamically set MCAUSER attribute to use MQ's AlternateUserId ? |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Thu Sep 26, 2024 2:42 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| cicsprog wrote: |
| Is there a way in CHLAUTH to dynamically set MCAUSER attribute to use MQ's AlternateUserId ? |
I don't believe that is possible.
CHLAUTH works on the MQCONN/X whereas the AlternateUserId is set in either MQOD or MQSD structure for MQOPEN/MQSUB call.
The only way I can think of doing this is with a Channel Security Exit where you have a list of UserIds that you want to swap.
i.e.
xxxx=yyyy
later
Roger
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| cicsprog |
| Posted: Thu Sep 26, 2024 5:42 pm Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
Funny u should mention that, I was looking at the one shipped in Zos libs. I?ve been swamped on other stuff and this is on bottom of list. But I?m back.
L2 gave me some urls to look at and maybe only the thing I need is a racf user ID defined according to where the sent me? I guess I am not smart enough to understand where they sent me on how to do it. |
|
| Back to top |
|
|
| hughson |
| Posted: Thu Sep 26, 2024 9:14 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
Did you ever get anywhere with discovering exactly what access the CHINIT user ID has to the RESLEVEL profile (which is being covered by the qmgr.* profile in your setup)?
You can discover this by issuing something like the following RACF command:-
| Code: |
| RLIST MQADMIN QKSL.RESLEVEL ALL |
and you will get some output including a section something like this:-
| Code: |
RLIST MQADMIN QKSL.RESLEVEL ALL
CLASS NAME
----- ----
MQADMIN QKSL.** (G)
...
LEVEL OWNER UNIVERSAL ACCESS YOUR ACCESS WARNING
----- -------- ---------------- ----------- -------
00 IBMUSER NONE ALTER NO
...
USER ACCESS
---- ------
IBMUSER ALTER |
Show us this output, with specific focus on the access that the user ID your CHINIT is running under has.
As I have noted a number of times, this really sounds like your CHINIT has high level access to the RESLEVEL profile and thus is doing zero checks at open time. I just want to rule this out so I can stop asking about it.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| cicsprog |
| Posted: Fri Sep 27, 2024 7:31 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
READY
RLIST MQADMIN QKSL.RESLEVEL ALL
CLASS NAME
----- ----
MQADMIN QKSL.RESLEVEL
GROUP CLASS NAME
----- ----- ----
GMQADMIN
RESOURCE GROUPS
-------- ------
NONE
LEVEL OWNER UNIVERSAL ACCESS YOUR ACCESS WARNING
----- -------- ---------------- ----------- -------
00 TKMS NONE NONE NO
INSTALLATION DATA
-----------------
NONE
APPLICATION DATA
----------------
NONE
SECLEVEL
--------
NO SECLEVEL
CATEGORIES
----------
NO CATEGORIES
SECLABEL
--------
NO SECLABEL
AUDITING
--------
FAILURES(READ)
GLOBALAUDIT
-----------
NONE
NOTIFY
------
NO USER TO BE NOTIFIED
CREATION DATE LAST REFERENCE DATE LAST CHANGE DATE
(DAY) (YEAR) (DAY) (YEAR) (DAY) (YEAR)
------------- ------------------- ----------------
247 24 247 24 247 24
ALTER COUNT CONTROL COUNT UPDATE COUNT READ COUNT
----------- ------------- ------------ ----------
000000 000000 000000 000000
USER ACCESS ACCESS COUNT
---- ------ ------ -----
NO USERS IN ACCESS LIST
ID ACCESS ACCESS COUNT CLASS ENTITY NAME
-------- ------- ------------ -------- --------------------------------------
NO ENTRIES IN CONDITIONAL ACCESS LIST |
|
| Back to top |
|
|
|
|
