| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQ Explorer and RACF password validation |
« View previous topic :: View next topic » |
| Author |
Message
|
| zpat |
 Posted: Mon Aug 01, 2011 6:22 am Post subject: |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
| rojaan wrote: |
| Okay, I'll look into this then. One small thing... any ideas why MQ Explorer has the option to enter the password when you enter a userid in the connection details? |
I presume it passes it to the client side security exit. Why it doesn't pass it to the queue manager to check (where possible) is one of the great mysteries of MQ. |
|
| Back to top |
|
 |
| rojaan |
| Posted: Mon Aug 01, 2011 6:34 am Post subject: |
|
|
Newbie
Joined: 01 Aug 2011
Posts: 8
|
| I performed some tests with the MCAUSER field. When I left it blank it did not inherit the started task userid for the CHIN address space, for some reason it used my name which failed as there is no user profile set up for this so it was unable to validate access to the SYSTEM.MQEXPLORER.REPLY.MODEL queue. I read in the manual that it should inherit the CHIN stc userid id, but this is not the case. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Aug 01, 2011 6:39 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| zpat wrote: |
| rojaan wrote: |
| Okay, I'll look into this then. One small thing... any ideas why MQ Explorer has the option to enter the password when you enter a userid in the connection details? |
I presume it passes it to the client side security exit. Why it doesn't pass it to the queue manager to check (where possible) is one of the great mysteries of MQ. |
The client app (or the environment/shell) can pass username/password to the SVRCONN, which acts as proxy for MQI calls.
Presuming that there is no security exit at either end of the MQI channel,
the MCAUSER identity will be:
1) the value of MCAUSER (if it is set to nonblank); OR,
2) MCAUSER have the value of the flowed user ID.
_________________
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 |
|
|
| fjb_saper |
| Posted: Mon Aug 01, 2011 6:40 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| rojaan wrote: |
| I performed some tests with the MCAUSER field. When I left it blank it did not inherit the started task userid for the CHIN address space, for some reason it used my name which failed as there is no user profile set up for this so it was unable to validate access to the SYSTEM.MQEXPLORER.REPLY.MODEL queue. I read in the manual that it should inherit the CHIN stc userid id, but this is not the case. |
That depends on whether your client is supplying a userid or not.
- In case you are not supplying a userid the one from the CHIN address space is used.
- If you are however supplying a userid, that userid will be used.
Have fun 
_________________
MQ & Broker admin
Last edited by fjb_saper on Mon Aug 01, 2011 6:42 am; edited 1 time in total |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Aug 01, 2011 6:42 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| rojaan wrote: |
| I performed some tests with the MCAUSER field. When I left it blank it did not inherit the started task userid for the CHIN address space, for some reason it used my name which failed as there is no user profile set up for this so it was unable to validate access to the SYSTEM.MQEXPLORER.REPLY.MODEL queue. I read in the manual that it should inherit the CHIN stc userid id, but this is not the case. |
It's more complicated than the one snippet of the manual that you read. With RESLEVEL, you get to specify which, and how many, ids are used for authorization.
_________________
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 |
|
|
| rojaan |
| Posted: Mon Aug 01, 2011 6:44 am Post subject: |
|
|
Newbie
Joined: 01 Aug 2011
Posts: 8
|
| I will have a think about what strategy to take. Thank you to both of you for your help. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Aug 01, 2011 10:03 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| rojaan wrote: |
| I will have a think about what strategy to take. Thank you to both of you for your help. |
I'm not sure what you mean by what strategy to take. There is nothing new here, no specific strategy that's unique or different.
z/OS users (or equivalent) get authenticated by the security component - RACF or equivalent.
z/OS actions (MVS OPEN, MQGET, whatever) get authorization from the security component, as well. For mq stuff, this is all well-documented in the WMQ for z/OS manuals and InfoCenter. There need to be the appropriate WMQ facility and resource classes.
For the WMQ Explorer, and the SVRCONN channel acting as proxy, authentication info (userid/password) can be explicitly passed. What gets passed will be sent to RACF.
In this instance, a RACF userid/password can be supplied. The userid/password must be known to RACF, match case (MVS expects UPPER-CASE unless you've allowed for mixed case, and have the required privileges.
Once the userid/password is/are authenticated, the Explorer will pass the mqsc-equivalent commands to the qmgr; and the replies will be passed back through the reply-to-queue.
You indicated that the userid/password didn't have authorization to the reply model. This is working as designed. Grant the appropriate permissions to the reply model for the userid you passed, and try again.
_________________
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 |
|
|
| rojaan |
| Posted: Mon Aug 01, 2011 10:15 am Post subject: |
|
|
Newbie
Joined: 01 Aug 2011
Posts: 8
|
This was my own personal strategy to decide how I will secure WMQ. Whether I allow users to use MQ Explorer purely for read only purposes by specifying an MCAUSER that has the relevant access then allow administration tasks to be performed using the ISPF interface, obviously users need to logon to TSO to use this so I can easily secure it.
I have already created all of the relevant classes and the profiles to secure the different resources in WMQ.
I appreciate the access required to use MQ Explorer, this part of the thread related to what happened when I remove the userid from the connection details, it was working as expected. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Aug 01, 2011 7:56 pm Post subject: |
|
|
Jedi
Joined: 25 Mar 2003
Posts: 2495
Location: Melbourne, Australia
|
| rojaan wrote: |
| ... any ideas why MQ Explorer has the option to enter the password when you enter a userid in the connection details? |
So that MQ can pass them to a Security Exit which is defined on the SVRCONN channel on the Queue Manager. The Security Exit could perform validation or authentication. There are several Security Exits available on the market.
_________________
Glenn |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Aug 01, 2011 9:33 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
The v7 Explorer can/will/does prompt for username/password. It is this username/password that must match a userid/password in RACF.
_________________
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 |
|
|
| bruce2359 |
| Posted: Tue Aug 02, 2011 5:11 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
Moved to Security forum.
_________________
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 |
|
|
| gbaddeley |
| Posted: Tue Aug 02, 2011 4:20 pm Post subject: |
|
|
Jedi
Joined: 25 Mar 2003
Posts: 2495
Location: Melbourne, Australia
|
| bruce2359 wrote: |
| The v7 Explorer can/will/does prompt for username/password. It is this username/password that must match a userid/password in RACF. |
It can be anything you want it to be, as coded in a security exit.
_________________
Glenn |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Fri Aug 12, 2011 3:06 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
Hello Bruce,
Sorry to be picky but you have blurred the lines and have some mis-information in your posting.
| bruce2359 wrote: |
| z/OS users (or equivalent) get authenticated by the security component - RACF or equivalent. |
z/OS queue manager does NOT authenticate by itself. You need an MQ security exit that will perform that function. Even if you set the UserID and Password in MQ Explorer or other products, the queue manager will NOT do any authentication.
Actually, this is true for ANY platform where you run a queue manager.
| bruce2359 wrote: |
| z/OS actions (MVS OPEN, MQGET, whatever) get authorization from the security component, as well. For mq stuff, this is all well-documented in the WMQ for z/OS manuals and InfoCenter. There need to be the appropriate WMQ facility and resource classes. |
True. Note: Authorization is performed after any security exit authentication.
| bruce2359 wrote: |
| For the WMQ Explorer, and the SVRCONN channel acting as proxy, authentication info (userid/password) can be explicitly passed. What gets passed will be sent to RACF. |
False. Unless you have written or purchased an MQ security exit, this does not happen.
Also, any UserID and Password set in MQ Explorer is sent to the queue manager in PLAIN TEXT.
| bruce2359 wrote: |
| In this instance, a RACF userid/password can be supplied. The userid/password must be known to RACF, match case (MVS expects UPPER-CASE unless you've allowed for mixed case, and have the required privileges. |
Yes, case does matter. As noted above, it is the MQ security exit that will perform the authentication with RACF and not the queue manager.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Aug 12, 2011 6:31 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
Roger.
My post was about the OP that wanted to use the WMQ Explorer product to administer a WMQ z/OS qmgr. As with all other platforms, no security exit is mandatory to do this kind of remote administration.
All that must take place is that the WMQ Explorer (v7) user supply a valid MVS (or UNIX or Windows) userid and password in the little window that the Explorer opens for this explicit purpose. No security exit is mandatory.
All of this presumes that the pre-requisite RACF (ACF, OAM) stuff has been appropriately configured to authorize access on the platform to be remotely administered.
| Quote: |
| z/OS queue manager does NOT authenticate by itself. You need an MQ security exit that will perform that function. Even if you set the UserID and Password in MQ Explorer or other products, the queue manager will NOT do any authentication. |
Not what I said, or intended to say.
At the well-documented MQI calls (MQOPEN, MQPUT1, etc.), whether from server- or client-bindings apps, the qmgr security component will issue a RACROUTE system call to ask RACF (or ACF) if the userid has sufficient authorization to access the resource.
| Quote: |
bruce2359 wrote:
For the WMQ Explorer, and the SVRCONN channel acting as proxy, authentication info (userid/password) can be explicitly passed. What gets passed will be sent to RACF. |
| Quote: |
Roger replies:
False. Unless you have written or purchased an MQ security exit, this does not happen. |
Which part is false?
The SVRCONN acting as proxy? That is its purpose - to issue MQI calls on behalf of a client app.
Are you saying that the Explorer doesn't pass the userid/password pair supplied by the user? If none are supplied, or an invalid userid/password are supplied, access to WMQ resources fails since RACF can not authenticate the userid.
Yes, userid/password is passed as clear text from the Explorer to the target system to be administered. This is an ideal place for SSL or a security exit to impose additional security.
I am not anti-security exits, Roger. My post was not an attack. I am an aficionado of Capitalware products; and I've recommended your products to my clients.
I thought I was pretty clear. But apparently not.
_________________
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 |
|
|
| RogerLacroix |
| Posted: Fri Aug 12, 2011 7:52 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
| bruce2359 wrote: |
| My post was about the OP that wanted to use the WMQ Explorer product to administer a WMQ z/OS qmgr. As with all other platforms, no security exit is mandatory to do this kind of remote administration. |
True.
| bruce2359 wrote: |
| All that must take place is that the WMQ Explorer (v7) user supply a valid MVS (or UNIX or Windows) userid and password in the little window that the Explorer opens for this explicit purpose. No security exit is mandatory. |
Incorrect. It appears that you have a mis-understanding of what a queue manager does with a UserID and Password sent by MQ Explorer (or any other program).
The queue manager uses the UserID for authorization ONLY and it throws away the password. The queue manager does not call RACF or ACF for authentication. Yes, it does an authorization check of the UserID against RACF or ACF but not authentication.
Now if there is a security exit defined then the UserID and Password is passed to it. It is up to the security exit to do the appropriate system call to authenticate the UserID and Password.
| bruce2359 wrote: |
| All of this presumes that the pre-requisite RACF (ACF, OAM) stuff has been appropriately configured to authorize access on the platform to be remotely administered. |
Authorization yes - authentication no.
| bruce2359 wrote: |
| Quote: |
| z/OS queue manager does NOT authenticate by itself. You need an MQ security exit that will perform that function. Even if you set the UserID and Password in MQ Explorer or other products, the queue manager will NOT do any authentication. |
Not what I said, or intended to say.
At the well-documented MQI calls (MQOPEN, MQPUT1, etc.), whether from server- or client-bindings apps, the qmgr security component will issue a RACROUTE system call to ask RACF (or ACF) if the userid has sufficient authorization to access the resource. |
Authorization yes - authentication no.
| bruce2359 wrote: |
| Quote: |
bruce2359 wrote:
For the WMQ Explorer, and the SVRCONN channel acting as proxy, authentication info (userid/password) can be explicitly passed. What gets passed will be sent to RACF. |
| Quote: |
Roger replies:
False. Unless you have written or purchased an MQ security exit, this does not happen. |
Which part is false? |
The false part is "What gets passed will be sent to RACF." The queue manager does NOT send anything to RACF for authentication.
| bruce2359 wrote: |
| Are you saying that the Explorer doesn't pass the userid/password pair supplied by the user? |
No. I'm saying that the queue manager does not do authentication.
| bruce2359 wrote: |
| If none are supplied, or an invalid userid/password are supplied, access to WMQ resources fails since RACF can not authenticate the userid. |
If you don't believe me then put in a valid z/OS UserID and put garbage for the Password and you will be able to successfully connect to the queue manager.
| bruce2359 wrote: |
| I am not anti-security exits, Roger. My post was not an attack. I am an aficionado of Capitalware products; and I've recommended your products to my clients. |
I did not think you were attacking security exits, many people think that a queue manager does both authentication and authorization but it only does authorization!!
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| 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
|
|
|
|
