| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQ console URL RESLEVEL |
« View previous topic :: View next topic » |
| Author |
Message
|
| cicsprog |
 Posted: Fri Sep 27, 2024 7:34 am Post subject: |
 |
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
------------------------( RACFADM - General Resources )
Command ===>
CLASS: MQADMIN
FILTER: QKSL.**
SELECT: S Show, L List, C Change, A Add, R Remove
S Profile
-------------------------------------------------------
QKSL.*
QKSL.CHANNEL.*
QKSL.CONTEXT
QKSL.CONTEXT.SYSTEM.ADMIN.COMMAND.QUEUE
QKSL.NO.TOPIC.CHECKS
QKSL.RESLEVEL
------------------------( RACFADM - General Resources )------------ Row 1 of 1
Command ===> Scroll==> CSR
PROFILE: QKSL.RESLEVEL
TYPE: DISCRETE
CLASS: MQADMIN
UACC: NONE (Default access) OWNER: TKMS (Owner of profile)
WARNING: NO (YES/NO) AUDIT: FAILURES(READ)
DATA: NONE
SELECT: S Show, L List, C Change, A Add, R Remove
S Group/ID Access
------------------------------------------------------------------------------
NO USERS |
|
| Back to top |
|
 |
| cicsprog |
| Posted: Fri Sep 27, 2024 7:48 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
Here's my latest question to L2:
Jason Andersen (Customer)
Sep 20, 2024, 11:03
I'm reopening the case because I'm not making any progress.
1) I need to know if MQ Console can be configured where ZOS DOES NOT HOST MQ Console. ZOS Queue Managers are just another Queue Manager instance wanting to be served from a distributed platform that manages MQ Console.
2) If it can, where is the documentation that explains how to do that?
Olga A. (IBM)
Sep 20, 2024, 11:24
Hello Jason
Yes, this is possible.
Please see these pages for more information:
https://www.ibm.com/docs/en/ibm-mq/9.4?topic=console-mq-adding-remote-queue-manager
https://community.ibm.com/community/user/integration/blogs/callum-jackson1/2021/07/23/ibm-mq-923-support-for-remote-queue-managers-in-th
Thanks and kind regards.
Olga (on behalf of David)
Jason Andersen (Customer)
Sep 20, 2024, 11:41
I dont see any requirement for RACF? Are there any? Where?
In the second url..
Click Next to move to the user page and optionally specify a username and password to connect to the remote queue manager. If you do not specify this information, then authentication information is taken from the remote connection configuration file.
Click Next to move to the Certificate page. You can select an SSL CipherSpec from the drop-down list. You can optionally paste a certificate (as a base64 encoded public key) and this is added to the global trust store.
The certificate is temporarily stored in WLP_USER_DIR/generated.crts/uniqueName-qmgrName.crt before it is added to the trust store. When the connection is successfully added, the certificate is deleted from this location.
Click Next to view the summary page. You can use the Back button to revisit previous pages and make corrections. If you are happy with the information, click Connect to connect to the remote queue manager.
The connection information that you specified is written to CCDT file in your web directory. The path is WLP_USER_DIR/generated.ccdt/ccdt-uniqueName.
Which of this is germane to ZOS?
Olga A. (IBM)
Sep 20, 2024, 13:50
Hello Jason
See this page "Procedure" step 5 or "Example" item 2:
https://www.ibm.com/docs/en/ibm-mq/9.4?topic=mcarqm-adding-remote-queue-manager-mq-console-by-using-command-line
You will see that the JSON CCDT file for a remote queue manager connection basically contains the channel name, host, port, queue manager name and it is a client connection.
So, when you are adding a remote queue manager, you don't see any requirement for RACF.
Using certificate is optional.
In RACF, you need to authorize the user ID that will connect to the queue manager and also authorize which resources the user ID can have access.
You may work with connection security if you want to do so:
https://www.ibm.com/docs/en/ibm-mq/9.4?topic=security-connection-profiles-channel-initiator
Thanks and kind regards.
Olga (on behalf of David). |
|
| Back to top |
|
|
| hughson |
| Posted: Fri Sep 27, 2024 1:07 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
| cicsprog wrote: |
CLASS NAME
----- ----
MQADMIN QKSL.RESLEVEL |
I thought you said you didn't have a RESLEVEL profile? This appears to show that you do. Previously we were under the impression that it was being covered by the QKSL.** profile.
Anyway, I guess that puts that one to bed.
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 1:34 pm Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
| I added after you pointed me to the doc that you should have at least have it defined. So I did. |
|
| Back to top |
|
|
| cicsprog |
| Posted: Fri Sep 27, 2024 1:39 pm Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
|
| Back to top |
|
|
| hughson |
| Posted: Fri Sep 27, 2024 5:44 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
I'm not sure how changing the way you add the client side configuration in is going to help you solve the queue manager side authorization issue you are facing?
Things that affect whether MQOPEN has an authority check are all on the queue manager side.
RESLEVEL; RACF switch profile; PUTAUT on SVRCONN; MCAUSER assigned by whichever method you are using. Do we understand all of these yet?
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 6:44 pm Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
Agreed. I just want to make sure this part is correct first. Since I don?t admin that side, I want to see it?s defined as documented.
Morag
What really concerns me is changing the behavior of these Zos mqm?s. They have an odd config - before my time. I came in as consultant. They use 6 Zos mqms to host nothing but svrconns. There?s one mqm that gets all this traffic and kicks off cics trans, hold msgs for batch, their own app started tasks that consume msgs, etc.
So I?m going to have to be pretty precise on changing up any racf security in these. So, hopefully making sure their configured correct from the manual will help.
All this to replace a product they don?t want to pay for any longer. Hopefully I can get MQ Console working properly so they can use it in test and prod environments. If you have a racf security approach I should take I?m all for it.
I just found your write up on reslevel. That might help a lot
So on Monday I?ll get reading that.
https://mqgem.wordpress.com/2015/06/10/reslevel-profile-and-channels/ |
|
| Back to top |
|
|
| cicsprog |
| Posted: Mon Sep 30, 2024 10:19 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
Morag
I've read your doc. Can't say I understand everything but maybe some.
Here's what I know about the flow from MQ Console
1) ZOS has these set
ADOPTCHK(ALL)
ADOPTMCA(ALL)
CHLAUTH(ENABLED)
CONNAUTH('USE.PW')
I created a RACF userid called MQCONSL requires no password and doesn't expire.
2) In the MQ Console GUI they signon with a NETWORK userid and password. This may or may NOT be a USERID defined in RACF. Password is defiantly different than the RACF one. I know some of the messages (maybe all) contain this NETWORK userid.
3) When a connect to a ZOS MQ, they use a SVRCONN called WEBCON.SVRCONN. Without hardcoding a MCAUSER value, I see the userid "mqm" is passed. The SVRCONN has PUTAUT(DEF) set.
Here is where I not sure what approach to take. I think I need to defiantly need a RESLEVEL for a userid. Also need CHLHAUTH. Not sure what settings.
What I would like is to use the MQCONSL userid to process the PCF messages so it can access the various Q's needed to process PCF messages and replies back to the MQ Console GUI. I'd like to use the alternateuserid field that contains the NETWORK userid, to be used in checking MQCMD security where I can limit what commands they can execute depending on test or prod mqm, I realize that some people will need to get a RACF userid created.
So, asking for some help on how these requirement can get coded.
My guess is
a) RESLEVEL(MQCONSL) ACCESS(ALTER)
b) CHLAUTH to change mqm userid to MQCONSL userid
I reread all your doc again (and again and again, lol) on RESELVEL and the link to MCAUSER usage. I see you can set MCAUSER with userid and password supplied. But, I'm not seeing a way to let the connection to happen, then use JUST the userid in the msg to be used to validate MQCMD rules. Unless you use an channel exit to set alternateuser as MCAUSER.
Remember, to even get into MQ Console, you have to use a valid network userid and password. I just need to use that Network USERID (which is alternateuser) to check what comands they can use on ZOS MQ mqm. I realize this requires me to define userids NOT already in RACF, but that's ok. When the userid is defined in RACF, it will get put into a RACF group that's just for application type security or into a group that has MQ Administration security.
Am I wrong?? |
|
| Back to top |
|
|
| hughson |
| Posted: Mon Sep 30, 2024 6:51 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
OK - I've gone back to the start of this thread and gathered together what I think we know about your system (albeit I know you have made some changes like creating a RESLEVEL profile) so perhaps you can confirm that this is still a true reflection of your system and description of your problem.
Queue Manager Name: QKSL
Pertinent attributes: SCYCASE(UPPER)
QKSL.RESLEVEL RACF profile exists in MQADMIN class and CHIN user ID, QKSLCHIN, (or indeed any user IDs) has no access to it.
This means that channel initiator access control will be using 2 checks.
Queue checks are on as evidenced by:-
| cicsprog wrote: |
DISPLAY SECURITY
CSQH037I -QKSL Security using uppercase classes
CSQH030I -QKSL Security switches ...
CSQH034I -QKSL QUEUE: ON, 'QKSL.NO.QUEUE.CHECKS' not found |
The channel in question, WEBCON.SVRCONN, is defined with PUTAUT(DEF) which means the following two user IDs will be checked on each MQOPEN of a queue:-
- CHL: This will be the CHINIT user ID, QKSLCHIN in all likelihood, unless you have RACF certificate maps in place.
- MCA: This is the resultant MCAUSER that the SVRCONN is going to run under. You are using CHLAUTH rules to set this up.
The WEBCON.SVRCONN channel is also defined with MCAUSER('MQCONSL') as well as the following positive CHLAUTH rule:-
| Code: |
SET CHLAUTH('WEBCON.SVRCONN') TYPE(USERMAP)
CLNTUSER('mqm') ADDRESS('10.2.43.26')
DESCR('MQ WebConsole Access')
USERSRC(MAP) MCAUSER('MQCONSL') |
With this all setup, we assume that the MQ Console SVRCONN channel runs under the MQCONSL user ID, and so the two user IDs that should be checked on an MQOPEN through the CHIN adapter are QKSLCHIN and MQCONSL.
When either MQ Console or other client attached application run on this channel with this user ID, it appears that they can MQOPEN queue JASON.TEST and MQPUT a message implying either the access has been granted, or the checks are not being done at all. This led you to the conclusion:
| cicsprog wrote: |
| So this proves that either there isnt any checking or RACF CLASS(MQQUEUE) is allowing. |
Looking at your profiles in the MQQUEUE class, the queue called JASON.TEST would be covered by either the QKSL.* or QKSL.** profiles (I'm not sure which one takes precedence). I can see that QKSLCHIN has ALTER access to QKSL.** so that just leaves us wondering how MQCONSL got access.
You stated:-
| cicsprog wrote: |
| I changed USERID MQCONSL to have group access under GROUP(APPL) and for MQQUEUE RACF class APPL has ACCESS(NONE). |
This leads me to wonder what group was MQCONSL user ID in before? Was it removed from that group or was the new GROUP(APPL) made in addition to what it had before? What access did the prior group have to MQQUEUE class profiles? Have you restarted queue manager or refreshed the queue manager's view of cached accesses for that user ID since the change?
So, can you show us the group memberships for user ID MQCONSL at this point?
The other thing I would be inclined to try to convince myself that queue checks were (or were not) happening, would be to RDEFINE an MQQUEUE class profile called QKSL.JASON.TEST with no access for anyone, and just make sure that this causes the MQOPEN to now fail. Then at least you know to chase down "How did MQCONSL get access from these profiles?" rather than "Why aren't my MQQUEUE class checks being done?"
I'd also be inclined to experiment with the behaviour when the SVRCONN is defined to use PUTAUT(ONLYMCA) to force it to be checking the MCAUSER - this would rule out any complications from the application doing an MQOPEN using Alternate User ID. I don't know if the MQ Console does that for it's MQOPEN to put a message to a queue. If you could gain some confidence that your MQQUEUE profile checks are being done, we could get a better handle on what was being requested by the MQ Console.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| cicsprog |
| Posted: Thu Oct 10, 2024 6:39 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
| Working on it...will report when I have some observations |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Oct 10, 2024 7:56 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| hughson wrote: |
| cicsprog wrote: |
| So this proves that either there isnt any checking or RACF CLASS(MQQUEUE) is allowing. |
Looking at your profiles in the MQQUEUE class, the queue called JASON.TEST would be covered by either the QKSL.* or QKSL.** profiles (I'm not sure which one takes precedence). I can see that QKSLCHIN has ALTER access to QKSL.** so that just leaves us wondering how MQCONSL got access.
Morag |
Probably not helpful here, but in RACF, the most restrictive rule takes precedence.
It's been decades, but I recall enabling SMF type 80 recording and reporting to determine such things.
_________________
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: Tue Oct 22, 2024 6:58 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
Well I did find a combination of attributes that sort of worked. But, unless the password is provided, it doesn't work like I need it to work because the password isn't present.
I also messed with the C channel exit to try and set MCAUSER. But via the API call by the exit program, the USER always came back blank. When I put the same exit on MO71 the userid was present (MO71 prompts for userid and password). Which believe me again to believe unless that password is provided, your NOT going to get the USERID populated. I saw that for a security exit for SVRCONN channels, you need a exit on the client side also. I believe that exit set REMOTE-ALTERNATE-USERID.
I believe that the way IBM MQ call various routines, documented below has something to do with the password requirement.
https://www.ibm.com/docs/en/ibm-mq/9.4?topic=records-interaction-chlauth-connauth#q132550___title__3 |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
