Discussion:
IEE345I Modify invalid authority
(too old to reply)
Peter
2020-08-31 03:40:56 UTC
Permalink
Hello

I am trying to issue a command using SDSF batch and I end up with

IEE345I Modify invalid authority failed by MVS

We have secured SDSF using ISFPRM

My ID and group are part of NTBL in ISFPRMxx and group name is assigned
under the GROUP which maps to my RACF Group (Default)

We are in zOS 2.2 and apart from above what else I need to look ?

Any pointers are much appreciated

Regards
Peter

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Lizette Koehler
2020-08-31 04:21:42 UTC
Permalink
Just curious why you do not control SDSF through your SAF Product.

I removed all of my ISFPARMxx setup and allow our SAF to control who can do what in SDSF. Now the security team is responsible.

Lizette


-----Original Message-----
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> On Behalf Of Peter
Sent: Sunday, August 30, 2020 8:41 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: IEE345I Modify invalid authority

Hello

I am trying to issue a command using SDSF batch and I end up with

IEE345I Modify invalid authority failed by MVS

We have secured SDSF using ISFPRM

My ID and group are part of NTBL in ISFPRMxx and group name is assigned under the GROUP which maps to my RACF Group (Default)

We are in zOS 2.2 and apart from above what else I need to look ?

Any pointers are much appreciated

Regards
Peter

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Brian Westerman
2020-08-31 05:10:54 UTC
Permalink
Even if you maintain SDSF via SAF (which you have to do by z/OS 2.5 because that's all that will be supported) you will still have to update the RACF OPERCMDS class (TSO RACF option 2 (general resource profiles)).

The profile name you need to update (for MVS batch and STC's) is MVS.MODIFY.**, for JES2 related stuff it would be JES2.MODIFY.**. I made it simplistic by using the ** after the modify. You can actually get pretty specific about what tasks are allowed to be modified by whom, but I figured you just wanted to get around your problem right now.

Brian

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter
2020-08-31 05:49:47 UTC
Permalink
Thank you for your response

So I believe I need to introduce RACF OPERCMDS even if it is maintained by
ISFPRMXX.



On Mon, 31 Aug, 2020, 9:11 am Brian Westerman, <
Post by Brian Westerman
Even if you maintain SDSF via SAF (which you have to do by z/OS 2.5
because that's all that will be supported) you will still have to update
the RACF OPERCMDS class (TSO RACF option 2 (general resource profiles)).
The profile name you need to update (for MVS batch and STC's) is
MVS.MODIFY.**, for JES2 related stuff it would be JES2.MODIFY.**. I made
it simplistic by using the ** after the modify. You can actually get
pretty specific about what tasks are allowed to be modified by whom, but I
figured you just wanted to get around your problem right now.
Brian
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
R.S.
2020-08-31 11:26:15 UTC
Permalink
Post by Brian Westerman
Even if you maintain SDSF via SAF (which you have to do by z/OS 2.5 because that's all that will be supported) you will still have to update the RACF OPERCMDS class (TSO RACF option 2 (general resource profiles)).
The profile name you need to update (for MVS batch and STC's) is MVS.MODIFY.**, for JES2 related stuff it would be JES2.MODIFY.**. I made it simplistic by using the ** after the modify. You can actually get pretty specific about what tasks are allowed to be modified by whom, but I figured you just wanted to get around your problem right now.
Brian
To clarify: it's not "even if you". RACF profiles are crucial part of
this picture. There is no possibility to "maintain SDSF via SAF" and to
not prepare the SAF (RACF).
You need profiles in OPERCMDS class, the class has to be activated, the
class has to be raclisted, etc.

Notes:
1. Fortunately the list of MVS commands and JES2 commands is maybe long,
but finite. And there are books which document "translation" from the
command to resource name, i.e. MVS.CANCEL.JOB.jobname.
2. Various command require various levels of authority, for example D
A,L require MVS.DISPLAY at level READ, CANCEL require UPDATE and FORCE
require CONTROL. The idea is simple: the more dangerous command the
higher level.
3. Note, the world is biiger than MVS and JES2. There are other commands
and other profiles for them. So, MVS.** and JES2.** will not cover
everything. SDSF is one of examples. RACF is another one.
4. To be honest "the rest of the world" is rather minority, and it's
rarely used. However it exists. For them you may create ** profile just
to catch it.
5. It's good when you get ICH408I message - this is hint for RACF
administrator. However it is also possible to not get such message,
everything depends on resource owner and decision about how to ask RACF.
SDSF is switches off logging oftenly.
6. JES2.** is tricky. The string "JES2" is the name of JES2 subsystem,
but it can be "JES8" or "JOHN" or whatever. The same apply to SDSF,
which usually use SDSF in resource name, but it is customizable. The
same for RACF subsystem.
7. For MVS commands the prefix is always MVS.


HTH
--
Radoslaw Skorupka
Lodz, Poland





======================================================================

Jeśli nie jesteś adresatem tej wiadomości:

- powiadom nas o tym w mailu zwrotnym (dziękujemy!),
- usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku).
Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze.

mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: ***@mBank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 0000025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2020 r. wynosi 169.401.468 złotych.

If you are not the addressee of this message:

- let us know by replying to this e-mail (thank you!),
- delete this message permanently (including all the copies which you have printed out or saved).
This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised.

mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: ***@mBank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 0000025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.401.468 as at 1 January 2020.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Brian Westerman
2020-09-01 04:30:44 UTC
Permalink
Yes. The "other" alternative is to not protect OPERCMDS (i.e. let everything be authorized), but that's really not a good option.

It's not a difficult process, and for the simplistic stuff you are doing to modify a simple started task, it's just the MVS.MODIFY.STC.** one you have to worry about for now, or you can limit it to just the specific STC via MVS.MODIFY.STC.membername.id where membername is the name of the member containing the JCL source and ID is the actual STC ID. If your JES2 Proc for the task is FRED and the ID of the task is also FRED (which is mostly normal), then the entire profile is "MVS.MODIFY.STC.FRED.FRED".

But as I said, for now you can just use MVS.MODIFY.STC.** and that will allow you to modify any started task.

Brian
Post by Peter
Thank you for your response
So I believe I need to introduce RACF OPERCMDS even if it is maintained by
ISFPRMXX.
On Mon, 31 Aug, 2020, 9:11 am Brian Westerman, <
Post by Brian Westerman
Even if you maintain SDSF via SAF (which you have to do by z/OS 2.5
because that's all that will be supported) you will still have to update
the RACF OPERCMDS class (TSO RACF option 2 (general resource profiles)).
The profile name you need to update (for MVS batch and STC's) is
MVS.MODIFY.**, for JES2 related stuff it would be JES2.MODIFY.**. I made
it simplistic by using the ** after the modify. You can actually get
pretty specific about what tasks are allowed to be modified by whom, but I
figured you just wanted to get around your problem right now.
Brian
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...