| Author |
Message
|
| KathyB |
 Posted: Mon Feb 02, 2004 10:47 am Post subject: ACF-2 and MQSeries |
 |
|
Apprentice
Joined: 02 Feb 2004
Posts: 30
|
| Does anyone have any experience in securing MQSeries using ACF-2? |
|
| Back to top |
|
 |
| RogerLacroix |
| Posted: Mon Feb 02, 2004 2:12 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
|
| Back to top |
|
|
| KathyB |
| Posted: Tue Feb 03, 2004 9:13 am Post subject: |
|
|
Apprentice
Joined: 02 Feb 2004
Posts: 30
|
I have taken over the responsibility for MQSeries security from
> someone who recently retired from our organization and am not familiar
> with this at all. I am the MQSeries administrator here, however do
> not work on security and was not involved in the security aspect of
> it. So, I will have many questions.
>
> The only information I was able to find pertaining to ACF-2 and
> MQSeries is from the Computer Associates website. Not much there.
>
> It appears that some things are already in place, so let me start by
> asking the following questions:
>
> 1. How you use RESLEVEL?
>
> 2. Can you explain what the MQADMIN class is and what do you define
> in the MQADMIN class?
> |
|
| Back to top |
|
|
| cicsprog |
| Posted: Tue Feb 03, 2004 10:39 am Post subject: |
|
|
Partisan
Joined: 27 Jan 2002
Posts: 347
|
If you want to pm me, I can email you a batch job that may help you and your ACF2 administrator with a starting place for MQ and ACF2. While these jobs were for our site, I'd bet you would get the general drift of what needs to happen. Funny thing though, we converted from ACF2 to RACF last year, so MQ runs under RACF in our enterprise.
Regards
Jason |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Tue Feb 03, 2004 12:37 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
Yes, CA's MQ & ACF2 doc is absolutely terrible (CA should be ashamed of it!!!). But it does have the basics. Although the version I have of the doc, circa 1999, has the _NO_ profile switches backwards. If you define a _NO_ profile switch then it turns security ON for that switch (not off).
Answers #1:
RESLEVEL controls how much security checking that the queue manager will do against the UserID or BatchID or RegionID. Zero (0) means that the queue manager will do a full security check. Where as 16 means that the queue manager does not do any security checking (don't do this!!!). Here is a simple sample:
| Code: |
SET C(GSO)
INSERT SAFDEF.mqmresl ID(mqmresl) MODE(IGNORE) JOB(cicsjob) RETCODE(0) FUNCRET(20) FUNCRSN(n)
RACROUTE(REQUEST=AUTH,CLASS=MQADMIN,ENTITYX=csq1.RESLEVEL) REP |
where 'n' represents the level of access desired:
0 - no access
4 - READ access
8 - UPDATE access
12 - CONTROL access
16 - ALTER access
and csq1 is the queue manager name and 'cicsjob' represents the job or jobs for which this access is desired.
Answers #2:
MQADMIN is a CLASMAP record. A CLASMAP ties an ACF2 resource class to an ACF2 resource rule. There are 6 of them:
MQADMIN controls administration security
MQCONN controls connection security
MQQUEUE controls queue security
MQPROC controls process security
MQNLIST controls namelist security
MQCMDS controls command security
Hope that helps.
[Shameless-Plug]If you need any on-site help then please do contact me.[/Shameless-Plug]
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| crossland |
| Posted: Wed Feb 04, 2004 7:33 am Post subject: |
|
|
Master
Joined: 26 Jun 2001
Posts: 248
|
Being in the middle of helping a client with their ACF2 security for MQ, I'll just add a bit. The z/os System Setup Guide includes a section on "Setting up security"; this is a good starting point. RACF CONTROL needs to be replaced with DELETE for ACF2 and RACF ALTER needs to be replaced with ADD for ACF2.
Regards,
Tim Crossland
http://www.solent-consultancy.com |
|
| Back to top |
|
|
| KathyB |
| Posted: Wed Mar 10, 2004 5:32 am Post subject: |
|
|
Apprentice
Joined: 02 Feb 2004
Posts: 30
|
I'd like to thank you all for your help in getting me started with MQ and ACF2 on z/OS. I now have a model that I can use for all my queue managers.
I have a question about securing mq objects on z/OS that are accessed from a distributed platform.
It seeems that all the rules that I have written secure my mq objects as long as I am running locally on the same system where my queue manager is defined.
However, if I access those same objects from a distributed platform, I'm allowed access to them.
I have tried setting MCUSER in both sender and receiver channel definitions to a userid that I know has no authority. I have also tried to set on the receiver channel the PUTAUT parameter to CTX and ALTMCA. I still am allowed access.
Any help would be greatly appreciated. |
|
| Back to top |
|
|
|
|
