| Author |
Message
|
| offshore |
 Posted: Fri Jan 23, 2004 10:37 am Post subject: MQ Security Question(s) |
 |
|
Master
Joined: 20 Jun 2002
Posts: 222
|
All,
The issue of security was brought up again concerning my MQ system. After doing some research I realized it may not be working the way I thought it was and that has raised some questions.
Enviroment:
MQ 5.3 QMGR W2K connecting to MQ 5.3 QMGR z/OS.
The z/OS side has all security set up so that only certain ID's can connect to the QMGR, perform put/get to certain queues.
The W2K side doesn't have any security setup so to speak.
How the app works:
The app running on Windows connects to the Windows QMGR and does a put to a remote q. The application puts in a generic ID used for that application. This remote q points to a local queue on z/OS.
The Problem:
What I've noticed is that any userid can put to the remote q on Windows and the messages is put to the actual queue on z/OS. Its as though the security setup on z/OS isn't working for this scenerio?
Is there some sort of authenication because its QMGR to QMGR with a sender/recieve channel or cluster channel.
I know that the z/OS security works since a mainframe user that is actually logged onto the mainframe is unable to connect or put if not in the securty profile.
Is there were the MCA ID comes into effect? What I was thinking is that only a certain app would be able to put to a certain queue. It doesn't look as though that is the case.
The application (which is a CICS) would still fail if the non-app id was put on a queue, due to certain ID's can only run certain transactions.
Hope this makes some sense. I guess how does QMGR to QMGR security work with sndr/rcvr channels or cluster sndr/rcvr channels. |
|
| Back to top |
|
 |
| mqonnet |
| Posted: Fri Jan 23, 2004 10:51 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
What i think is the most likely cause of your problem is, even though you have security set up on Z/os for specific user to access specific queues, this authentication is NOT being used when a remote user is putting messages onto remote queue.
Reason:
When you put to remote queue, the message is put to the destination local queue by the receiving MCA on the destination queue manager. This MCA uses the authority of the userid who started the queue manager, since that user is in the mqm group, every message is put with that authority.
So, to avoid this state, you need to put in "that specific" userid which you defined on Z/os with specific authority in the MCAUSER attribute of the receiver channel that is connected to the queue manager on Z/os. Remember it is case sensitive. By doing so, you are saying that anyone putting to a remote queue that is pointing to a local queue on Z/os system using this rcvr channel must be authenticated using the userid specified in the MCAUSER attribute.
Hope this helps.
Cheers
Kumar |
|
| Back to top |
|
|
| EddieA |
| Posted: Fri Jan 23, 2004 11:11 am Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
Why not just change the Receiver Channel to have Put Authority = Context. That way, MQ will use the UserID in the message to write to the Local queue. If the user isn't valid on the z/OS security, then DLQ.
Putting a user in the MCAUSER defeats ALL security. Unless it's a "garbage" UserID and you use Security Exits.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
| offshore |
| Posted: Tue Jan 27, 2004 4:20 am Post subject: |
|
|
Master
Joined: 20 Jun 2002
Posts: 222
|
Eddie,
That is exactly what I think I'm going to use. I started reading a manual (image that!!) and that seems to be the eaisiest and best way to go.
Thanks,
offshore |
|
| Back to top |
|
|
| KathyB |
| Posted: Thu Mar 11, 2004 9:56 am Post subject: |
|
|
Apprentice
Joined: 02 Feb 2004
Posts: 30
|
I'm currently having the same problem that you had with remote connections into the mainframe system.
What additionally did you do to resolve the problem. ?
I did exactly as was suggested and made Put Authority = Context.
This made no difference.
What are you using for your ESM? |
|
| Back to top |
|
|
| kman |
| Posted: Thu Mar 11, 2004 7:50 pm Post subject: |
|
|
Partisan
Joined: 21 Jan 2003
Posts: 309
Location: Kuala Lumpur, Malaysia
|
PUTAUT Context only make the queue open with MQOO_SET_ALL_CONTEXT and MQOO_ALTERNATE_USER_AUTHORITY, using the AlternateUserId on the message header, which was copied from the userid. This is the userid on the Windows.
What is your transmission protocol? Are you using TCP/IP or LU 6.2?
If you have the MCAUSER id set, then all connection coming through the channel will use the MCAUSER id, and if that id is authorized, then all connection is possible, even if the userid (user id, application id, process id, etc.,) was not authorized. |
|
| Back to top |
|
|
| KathyB |
| Posted: Mon Mar 15, 2004 4:35 am Post subject: |
|
|
Apprentice
Joined: 02 Feb 2004
Posts: 30
|
I am using TCP/IP and ACF-2 as my ESM.
It doesn't sound like I want to use MCAUSER since I want to be able to stop individual users from accessing objects that don't belong to them when they come in from a remote location.
After doing some reading, it sounds like I need to set a RESLEVEL profile to have 2 userids checked, the channel userid and the userid in the message. I haven't figured out how to do that yet and any help would be appreciated.
Am I on the right track? |
|
| Back to top |
|
|
| crossland |
| Posted: Mon Mar 15, 2004 6:41 am Post subject: |
|
|
Master
Joined: 26 Jun 2001
Posts: 248
|
The default is to check two userids for a channel initiator.
Be aware of the following quote from the z/os System Setup Guide:
| Quote: |
If you do not have a RESLEVEL profile defined, you must be careful that no other profile in the MQADMIN class matches hlq.RESLEVEL. For example, if you have a profile in MQADMIN called hlq.** and no hlq.RESLEVEL profile, beware of the consequences of the hlq.** profile because it is used for the RESLEVEL check.
You should define an hlq.RESLEVEL profile and set the UACC to NONE, rather than not have a RESLEVEL profile at all. |
Regards,
Tim Crossland
http://www.solent-consultancy.com |
|
| Back to top |
|
|
| offshore |
| Posted: Tue Mar 16, 2004 10:58 am Post subject: |
|
|
Master
Joined: 20 Jun 2002
Posts: 222
|
Almost forgot about this post since our "security" issue has died down.
Kathy, we're using the same thing ACF2 & TCPIP.
KMAN, not sure if MCAUSER ID will work with our setup. <I haven't had much time to research security lately with some system changes I've been implementing.>
Here is my reasoning. The QMGR we have running on z/OS hosts many different Q's that are tied to many different applications. The way our security is setup ID1 has access to Q1 - Q5, ID2 has access to Q6- Q9, ect.
There is only 1 channel <cluster sender> going from the Windows QMGR to the z/OS QMGR. I think that will basically give the MCAUSER ID access to all queues and applications which will result in almost the same security we have now?
And I could be completely wrong.....thanks for all the input though. |
|
| Back to top |
|
|
| KathyB |
| Posted: Wed Apr 21, 2004 10:32 am Post subject: |
|
|
Apprentice
Joined: 02 Feb 2004
Posts: 30
|
I have a security question relating to xmit queue security on the mainframe.
I can find no information on securing xmit queues.
I 've secured access to my dead letter queue by unauthorized users by defining an alias to it as outlined in the System Setup Guide, Dead-letter queue security section. Does anyone know if xmit queue security is handled the same way? |
|
| Back to top |
|
|
| mqonnet |
| Posted: Wed Apr 21, 2004 10:52 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Setmqaut the appropriate users to access the xmitq.
Cheers
Kumar |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Apr 21, 2004 10:53 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
On Z/OS?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| KathyB |
| Posted: Wed Apr 21, 2004 11:09 am Post subject: |
|
|
Apprentice
Joined: 02 Feb 2004
Posts: 30
|
I guess my question really is one of best practices. I would like to give users the ability to use PQedit to manipulate their queue data.
I have turned full reslevel checking on, meaning that the userid in the mqmd along with the chinit userid is being checked for queue permission. If one userid is denied access, then access is denied to the object and the message ends up on the DLQ.
So, that is where the problem comes in. I must allow both userids access to the xmit queue in order for messages to flow but now this gives users access to the xmit queue in PQedit.
What do mainframe mqadmins do? |
|
| Back to top |
|
|
| mqonnet |
| Posted: Wed Apr 21, 2004 11:09 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
:) Good catch jeff... Guess i got carried way.
Cheers
Kumar |
|
| Back to top |
|
|
|
|
