Re: RACF - SDSF question

[Shaffer, Terri]

Thanks Rob.  That showed what rules I was hitting.

I think I might have fixed it, but will have to see.  What I found was there 
was an *.* rule and an actual JESNODE.**, which was more specific and allowed 
all users ALTER ac cess

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Rob 
Scott
Sent: Wednesday, April 17, 2024 11:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

[You don't often get email from 0618c90e6fdf-dmarc-requ...@listserv.ua.edu. 
Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


You can check what security activity is going on behind the scenes in SDSF, by 
doing the following :


  1.  Invoke SDSF and get to the point just before the user issues the action
  2.  Issue "SET SECTRACE ON"
  3.  Issue the "C" action
  4.  Issue "SET SECTRACE OFF"
  5.  Go into SDSF ULOG and there will new numerous security trace messages 
showing the resources checked by SDSF and the SAF result from each.

They look something like :

ISF051I SAF Access allowed SAFRC=0 ACCESS=ALTER CLASS=JESSPOOL 
RESOURCE=node.owner.jobnameetc

In your specific case, SDSF will do a JESSPOOL profile check and require UPDATE 
or UPDATE access for CANCEL style actions.

Note that this is a "value add" thing that SDSF does and might not be reflected 
in the behaviour of other products/methods that can issue MVS and JES2 commands.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Wednesday, April 17, 2024 1:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL



Hi,
I would like to resurrect this question again, because my issue is back but not 
sure if by design or my RACF setup...

Because we are a development shop, we allow our developers to start/stop and 
issue modify commands to shutdown their CICS regions that run as batch Jobs.

They are the owners/notify of said regions, However, what I would like to 
prevent to them Cancelling the regions, due to possible file corruption, etc.

They put a C beside a jobname which then issues a $CJ, which then translates 
into a CANCEL ,A=xx command.

$CJ(5138)
CANCEL C30TCIE2,A=0051
IEE301I C30TCIE2 CANCEL COMMAND ACCEPTED
$HASP890 JOB(C30TCIE2) 288
$HASP890 JOB(C30TCIE2) STATUS=(EXECUTING/SPS1),CLASS=Y,
$HASP890 PRIORITY=9,SYSAFF=(ANY),HOLD=(NONE
$HASP890 CANCEL=YES

So my question becomes is it even possible to stop this because technically 
they are the owners?

In RACF.
My JESSPOOL class has.
*.*.C30TCI*.** (G)

My OPERCMDS class has
JES2.CANCEL.BAT with them having UPDATE access

MVS.CANCEL.JOB.C30TCI* (G) NO access

So not sure this is possible or not?

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Wednesday, February 8, 2023 9:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Thank you, with your input and Robs, I now know the order of the checks, which 
was the piece I didn't fully understand.

I have now cleaned up my extra rules and added rules under jesspool and they 
are now stopped.

Rob, thanks for the slides!

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Robert 
S. Hansel (RSH)
Sent: Wednesday, February 8, 2023 8:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Hi Terri,

Here are a couple of thoughts to add to what others have mentioned.

Since SDSF is issuing a JES2 cancel job $CJ command, the name of the OPERCMDS 
resource being checked is JES2.CANCEL.BAT. Profile JES2.CANCEL.BAT.C30TCI* is 
superfluous since the resource name never includes the jobname, so you can 
delete it. Profile JES2.CANCEL.BAT.** is guarding JES2.CANCEL.BAT because the 
.** generic suffix applies to zero or more qualifiers, and in this case it is 
zero qualifiers. The suggestions to lock down MVS cancel job commands won't 
help in this situation because SDSF is issuing JES2 commands inst

Re: RACF - SDSF question

[Hayim Sokolsky]

Terri,

This is somewhat of an all or nothing equation, with a twist or two.

In OPERCMDS, the permits should always be "WHEN(CONSOLE(SDSF))" instead of 
permitting their groups. This filters the ability to issue the OPERATOR 
commands - both MVS commands and JES2 commands to be limited to situations 
where SDSF has generated the command for the user. At this point the 
JES2.CANCEL.BAT can only be issued when the user is authorized to the job.

So:
PERMIT JES2.CANCEL.BAT CLASS(OPERCMDS) ID(GROUP1) ACCESS(UPDATE)
 /* not recommended */
PERMIT JES2.CANCEL.BAT CLASS(OPERCMDS) ID(*) ACCESS(UPDATE) WHEN(CONSOLE(SDSF)) 
 /* recommended */

The second part of this equation is the profiles in the JESSPOOL class. If they 
have ALTER to a given job's profiles, they can have SDSF generate the commands 
to cancel or purge the job. If they do not have ALTER, then they cannot.

The interesting twist is how specific or not specific you go in JESSPOOL. SDSF 
gets kind of creative when it comes to issuing checks against JESSPOOL. There 
are separate checks performed on rerouting and purging output files which are 
separate from the normal JESSPOOL profile names.

  *   If the user owns the job, that is the job runs under their UserID, they 
automatically have ALTER. So don't let them run CICS regions under their own 
personal UserIDs.
  *   Assuming you have non-human (surrogate) UserIDs, the JESSPOOL profile 
should always contain the UserID or non-human UserID prefix explicitly, such as 
*.UserID.*.** instead of *.*.jobname.**.

JESSPOOL Profile
Scope
nodeid.userid.jobname.jobid
The job itself. Not used for releasing output or viewing the job output.
nodeid.userid.jobname.jobid.Ddsid.dsname
View individual SYSIN or SYSOUT data sets.
nodeid.userid.jobname.jobid.GROUP.ogroupid
Releasing or purging output groups.

It's all in how well you structure the UserIDs, OPERCMDS, and JESSPOOL profiles.



Hayim Sokolsky (he/him/his)

Director, Software Engineering

Rocket Software, USA



E: hsokol...@rocketsoftware.com<mailto:hsokol...@rocketsoftware.com>

W:RocketSoftware.com


From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Wednesday, April 17, 2024 08:28
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL



Hi,
I would like to resurrect this question again, because my issue is back but not 
sure if by design or my RACF setup...

Because we are a development shop, we allow our developers to start/stop and 
issue modify commands to shutdown their CICS regions that run as batch Jobs.

They are the owners/notify of said regions, However, what I would like to 
prevent to them Cancelling the regions, due to possible file corruption, etc.

They put a C beside a jobname which then issues a $CJ, which then translates 
into a CANCEL ,A=xx command.

$CJ(5138)
CANCEL C30TCIE2,A=0051
IEE301I C30TCIE2 CANCEL COMMAND ACCEPTED
$HASP890 JOB(C30TCIE2) 288
$HASP890 JOB(C30TCIE2) STATUS=(EXECUTING/SPS1),CLASS=Y,
$HASP890 PRIORITY=9,SYSAFF=(ANY),HOLD=(NONE
$HASP890 CANCEL=YES

So my question becomes is it even possible to stop this because technically 
they are the owners?

In RACF.
My JESSPOOL class has.
*.*.C30TCI*.** (G)

My OPERCMDS class has
JES2.CANCEL.BAT with them having UPDATE access

MVS.CANCEL.JOB.C30TCI* (G) NO access

So not sure this is possible or not?

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Wednesday, February 8, 2023 9:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Thank you, with your input and Robs, I now know the order of the checks, which 
was the piece I didn't fully understand.

I have now cleaned up my extra rules and added rules under jesspool and they 
are now stopped.

Rob, thanks for the slides!

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Robert 
S. Hansel (RSH)
Sent: Wednesday, February 8, 2023 8:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Hi Terri,

Here are a couple of thoughts to add to what others have mentioned.

Since SDSF is issuing a JES2 cancel job $CJ command, the name of the OPERCMDS 
resource being checked is JES2.CANCEL.BAT. Profile JES2.CANCEL

Re: RACF - SDSF question

[Rob Scott]

Of course, that should read "UPDATE or ALTER access"

Rob

From: IBM Mainframe Discussion List  On Behalf Of Rob 
Scott
Sent: Wednesday, April 17, 2024 4:02 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL



You can check what security activity is going on behind the scenes in SDSF, by 
doing the following :


1. Invoke SDSF and get to the point just before the user issues the action
2. Issue "SET SECTRACE ON"
3. Issue the "C" action
4. Issue "SET SECTRACE OFF"
5. Go into SDSF ULOG and there will new numerous security trace messages 
showing the resources checked by SDSF and the SAF result from each.

They look something like :

ISF051I SAF Access allowed SAFRC=0 ACCESS=ALTER CLASS=JESSPOOL 
RESOURCE=node.owner.jobnameetc

In your specific case, SDSF will do a JESSPOOL profile check and require UPDATE 
or UPDATE access for CANCEL style actions.

Note that this is a "value add" thing that SDSF does and might not be reflected 
in the behaviour of other products/methods that can issue MVS and JES2 commands.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Wednesday, April 17, 2024 1:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL



Hi,
I would like to resurrect this question again, because my issue is back but not 
sure if by design or my RACF setup...

Because we are a development shop, we allow our developers to start/stop and 
issue modify commands to shutdown their CICS regions that run as batch Jobs.

They are the owners/notify of said regions, However, what I would like to 
prevent to them Cancelling the regions, due to possible file corruption, etc.

They put a C beside a jobname which then issues a $CJ, which then translates 
into a CANCEL ,A=xx command.

$CJ(5138)
CANCEL C30TCIE2,A=0051
IEE301I C30TCIE2 CANCEL COMMAND ACCEPTED
$HASP890 JOB(C30TCIE2) 288
$HASP890 JOB(C30TCIE2) STATUS=(EXECUTING/SPS1),CLASS=Y,
$HASP890 PRIORITY=9,SYSAFF=(ANY),HOLD=(NONE
$HASP890 CANCEL=YES

So my question becomes is it even possible to stop this because technically 
they are the owners?

In RACF.
My JESSPOOL class has.
*.*.C30TCI*.** (G)

My OPERCMDS class has
JES2.CANCEL.BAT with them having UPDATE access

MVS.CANCEL.JOB.C30TCI* (G) NO access

So not sure this is possible or not?

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com%3cmailto:terri.shaf...@aciworldwide.com>>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>>>
 On Behalf Of Shaffer, Terri
Sent: Wednesday, February 8, 2023 9:09 AM
To: 
IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>>
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Thank you, with your input and Robs, I now know the order of the checks, which 
was the piece I didn't fully understand.

I have now cleaned up my extra rules and added rules under jesspool and they 
are now stopped.

Rob, thanks for the slides!

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com%3cmailto:terri.shaf...@aciworldwide.com>>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>>>
 On Behalf Of Robert S. Hansel (RSH)
Sent: Wednesday, February 8, 2023 8:00 AM
To: 
IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU%3cmailto:IBM-MAIN@LISTSERV.UA.EDU>>
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Hi Terri,

Here are a couple of thoughts to add to what others have mentioned.

Since SDSF is issuing a JES2 cancel job $CJ command, the name of the OPERCMDS 
resource being checked is JES2.CANCEL.BAT. Profile JES2.CANCEL.BAT.C30TCI* is 
superfluous since the resource name never includes the jobname, so you can 
delete it. Profile JES2.CANCEL.BAT.** is guarding JES2.CANCEL.BAT because the 
.** generic suffix applies to zero or more qualifiers, and in this case it is 
zero qualifiers. The suggestions to lock down MVS cancel job commands won't 
help in this situation because SDSF is issuing JES2 commands instead of MVS 
commands, so the OPERCMDS MVS.CANCEL.JOB

Re: RACF - SDSF question

[Rob Scott]

You can check what security activity is going on behind the scenes in SDSF, by 
doing the following :


  1.  Invoke SDSF and get to the point just before the user issues the action
  2.  Issue "SET SECTRACE ON"
  3.  Issue the "C" action
  4.  Issue "SET SECTRACE OFF"
  5.  Go into SDSF ULOG and there will new numerous security trace messages 
showing the resources checked by SDSF and the SAF result from each.

They look something like :

ISF051I SAF Access allowed SAFRC=0 ACCESS=ALTER CLASS=JESSPOOL 
RESOURCE=node.owner.jobnameetc

In your specific case, SDSF will do a JESSPOOL profile check and require UPDATE 
or UPDATE access for CANCEL style actions.

Note that this is a "value add" thing that SDSF does and might not be reflected 
in the behaviour of other products/methods that can issue MVS and JES2 commands.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Wednesday, April 17, 2024 1:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL



Hi,
I would like to resurrect this question again, because my issue is back but not 
sure if by design or my RACF setup...

Because we are a development shop, we allow our developers to start/stop and 
issue modify commands to shutdown their CICS regions that run as batch Jobs.

They are the owners/notify of said regions, However, what I would like to 
prevent to them Cancelling the regions, due to possible file corruption, etc.

They put a C beside a jobname which then issues a $CJ, which then translates 
into a CANCEL ,A=xx command.

$CJ(5138)
CANCEL C30TCIE2,A=0051
IEE301I C30TCIE2 CANCEL COMMAND ACCEPTED
$HASP890 JOB(C30TCIE2) 288
$HASP890 JOB(C30TCIE2) STATUS=(EXECUTING/SPS1),CLASS=Y,
$HASP890 PRIORITY=9,SYSAFF=(ANY),HOLD=(NONE
$HASP890 CANCEL=YES

So my question becomes is it even possible to stop this because technically 
they are the owners?

In RACF.
My JESSPOOL class has.
*.*.C30TCI*.** (G)

My OPERCMDS class has
JES2.CANCEL.BAT with them having UPDATE access

MVS.CANCEL.JOB.C30TCI* (G) NO access

So not sure this is possible or not?

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of 
Shaffer, Terri
Sent: Wednesday, February 8, 2023 9:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Thank you, with your input and Robs, I now know the order of the checks, which 
was the piece I didn't fully understand.

I have now cleaned up my extra rules and added rules under jesspool and they 
are now stopped.

Rob, thanks for the slides!

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com<mailto:terri.shaf...@aciworldwide.com>

-Original Message-
From: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf Of Robert 
S. Hansel (RSH)
Sent: Wednesday, February 8, 2023 8:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Hi Terri,

Here are a couple of thoughts to add to what others have mentioned.

Since SDSF is issuing a JES2 cancel job $CJ command, the name of the OPERCMDS 
resource being checked is JES2.CANCEL.BAT. Profile JES2.CANCEL.BAT.C30TCI* is 
superfluous since the resource name never includes the jobname, so you can 
delete it. Profile JES2.CANCEL.BAT.** is guarding JES2.CANCEL.BAT because the 
.** generic suffix applies to zero or more qualifiers, and in this case it is 
zero qualifiers. The suggestions to lock down MVS cancel job commands won't 
help in this situation because SDSF is issuing JES2 commands instead of MVS 
commands, so the OPERCMDS MVS.CANCEL.JOB.jobname resources won't be checked.

As was mentioned, to cancel a job typically also requires ALTER access to the 
JESSPOOL resource guarding the job. Look into setting up appropriate JESSPOOL 
profiles to isolate and restrict ALTER access to these jobs. Also consider 
whether users have been (inadvertently) set up as Destination Operators. If 
they have READ access to SDSF resource ISFOPER.DEST.JES2 and ALTER access to 
SDSF resources prefixed ISFAUTH.DEST., they can cancel jobs while bypassing 
JESSPOOL profile checks.

If the CONSOLE class is active, you can permit ID(*) UPDATE access to 
JES2.CANCEL.BAT.** conditionally by adding operand WHEN(CONSOLE(SDSF)) to the 
PERMIT command so that users can only issue JES2 cancel job commands from 
within SDSF panels. Th

Re: RACF - SDSF question

[Norbert Gál]

Hello Terri,


How does your JESJOBS class look like?

https://www.ibm.com/docs/en/zos/2.5.0?topic=cujn-controlling-who-can-cancel-jobs-by-job-name





-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Wednesday, April 17, 2024 2:28 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXTERNAL] Re: RACF - SDSF question

Hi,
  I would like to resurrect this question again, because my issue is back but 
not sure if by design or my RACF setup...

Because we are a development shop, we allow our developers to start/stop and 
issue modify commands to shutdown their CICS regions that run as batch Jobs.

They are the owners/notify of said regions, However, what I would like to 
prevent to them Cancelling the regions, due to possible file corruption, etc.

They put a C beside a jobname which then issues a $CJ, which then translates 
into a CANCEL ,A=xx  command.

$CJ(5138)
CANCEL   C30TCIE2,A=0051
IEE301I C30TCIE2  CANCEL COMMAND ACCEPTED
$HASP890 JOB(C30TCIE2) 288
$HASP890 JOB(C30TCIE2)  STATUS=(EXECUTING/SPS1),CLASS=Y,
$HASP890PRIORITY=9,SYSAFF=(ANY),HOLD=(NONE
$HASP890CANCEL=YES

So my question becomes is it even possible to stop this because technically 
they are the owners?

In RACF.
My JESSPOOL class has.
*.*.C30TCI*.** (G)

My OPERCMDS class has
JES2.CANCEL.BAT with them having UPDATE access

MVS.CANCEL.JOB.C30TCI* (G)  NO access

So not sure this is possible or not?

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Wednesday, February 8, 2023 9:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Thank you, with your input and Robs, I now know the order of the checks, which 
was the piece I didn't fully understand.

I have now cleaned up my extra rules and added rules under jesspool and they 
are now stopped.

Rob, thanks for the slides!

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Robert S. Hansel (RSH)
Sent: Wednesday, February 8, 2023 8:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Hi Terri,

Here are a couple of thoughts to add to what others have mentioned.

Since SDSF is issuing a JES2 cancel job $CJ command, the name of the OPERCMDS 
resource being checked is JES2.CANCEL.BAT. Profile JES2.CANCEL.BAT.C30TCI* is 
superfluous since the resource name never includes the jobname, so you can 
delete it. Profile JES2.CANCEL.BAT.** is guarding JES2.CANCEL.BAT because the 
.** generic suffix applies to zero or more qualifiers, and in this case it is 
zero qualifiers. The suggestions to lock down MVS cancel job commands won't 
help in this situation because SDSF is issuing JES2 commands instead of MVS 
commands, so the OPERCMDS MVS.CANCEL.JOB.jobname resources won't be checked.

As was mentioned, to cancel a job typically also requires ALTER access to the 
JESSPOOL resource guarding the job. Look into setting up appropriate JESSPOOL 
profiles to isolate and restrict ALTER access to these jobs. Also consider 
whether users have been (inadvertently) set up as Destination Operators. If 
they have READ access to SDSF resource ISFOPER.DEST.JES2 and ALTER access to 
SDSF resources prefixed ISFAUTH.DEST., they can cancel jobs while bypassing 
JESSPOOL profile checks.

If the CONSOLE class is active, you can permit ID(*) UPDATE access to 
JES2.CANCEL.BAT.** conditionally by adding operand WHEN(CONSOLE(SDSF)) to the 
PERMIT command so that users can only issue JES2 cancel job commands from 
within SDSF panels. This would prevent them from cancelling jobs outside of 
SDSF, to include when using the SDSF / command. You would need to remove 
UACC(UPDATE) or ID(*) UPDATE permission, whichever applies, for the conditional 
permission to take effect. Operations and Tech Support staff will need 
'regular' UPDATE access permission. (CONSOLE is a Default Return Code 8 class, 
so don't activate it without first creating a ** profile with UACC(READ).)

To see exactly what resource names are being checked that are allowing the 
unwanted job cancellations, issue the SDSF command SET SECTRACE ON, cancel the 
job, and then issue the SDSF command ULOG. ULOG will show you all the access 
checks SDSF is making along with the results of each of these checks. SECTRACE 
is a phenomenal diagnostic tool that we use often.

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.  *** Celebrating our 30th Anniversary

Re: RACF - SDSF question

[Shaffer, Terri]

Hi,
  I would like to resurrect this question again, because my issue is back but 
not sure if by design or my RACF setup...

Because we are a development shop, we allow our developers to start/stop and 
issue modify commands to shutdown their CICS regions that run as batch Jobs.

They are the owners/notify of said regions, However, what I would like to 
prevent to them Cancelling the regions, due to possible file corruption, etc.

They put a C beside a jobname which then issues a $CJ, which then translates 
into a CANCEL ,A=xx  command.

$CJ(5138)
CANCEL   C30TCIE2,A=0051
IEE301I C30TCIE2  CANCEL COMMAND ACCEPTED
$HASP890 JOB(C30TCIE2) 288
$HASP890 JOB(C30TCIE2)  STATUS=(EXECUTING/SPS1),CLASS=Y,
$HASP890PRIORITY=9,SYSAFF=(ANY),HOLD=(NONE
$HASP890CANCEL=YES

So my question becomes is it even possible to stop this because technically 
they are the owners?

In RACF.
My JESSPOOL class has.
*.*.C30TCI*.** (G)

My OPERCMDS class has
JES2.CANCEL.BAT with them having UPDATE access

MVS.CANCEL.JOB.C30TCI* (G)  NO access

So not sure this is possible or not?

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Shaffer, Terri
Sent: Wednesday, February 8, 2023 9:09 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Thank you, with your input and Robs, I now know the order of the checks, which 
was the piece I didn't fully understand.

I have now cleaned up my extra rules and added rules under jesspool and they 
are now stopped.

Rob, thanks for the slides!

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Robert S. Hansel (RSH)
Sent: Wednesday, February 8, 2023 8:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Hi Terri,

Here are a couple of thoughts to add to what others have mentioned.

Since SDSF is issuing a JES2 cancel job $CJ command, the name of the OPERCMDS 
resource being checked is JES2.CANCEL.BAT. Profile JES2.CANCEL.BAT.C30TCI* is 
superfluous since the resource name never includes the jobname, so you can 
delete it. Profile JES2.CANCEL.BAT.** is guarding JES2.CANCEL.BAT because the 
.** generic suffix applies to zero or more qualifiers, and in this case it is 
zero qualifiers. The suggestions to lock down MVS cancel job commands won't 
help in this situation because SDSF is issuing JES2 commands instead of MVS 
commands, so the OPERCMDS MVS.CANCEL.JOB.jobname resources won't be checked.

As was mentioned, to cancel a job typically also requires ALTER access to the 
JESSPOOL resource guarding the job. Look into setting up appropriate JESSPOOL 
profiles to isolate and restrict ALTER access to these jobs. Also consider 
whether users have been (inadvertently) set up as Destination Operators. If 
they have READ access to SDSF resource ISFOPER.DEST.JES2 and ALTER access to 
SDSF resources prefixed ISFAUTH.DEST., they can cancel jobs while bypassing 
JESSPOOL profile checks.

If the CONSOLE class is active, you can permit ID(*) UPDATE access to 
JES2.CANCEL.BAT.** conditionally by adding operand WHEN(CONSOLE(SDSF)) to the 
PERMIT command so that users can only issue JES2 cancel job commands from 
within SDSF panels. This would prevent them from cancelling jobs outside of 
SDSF, to include when using the SDSF / command. You would need to remove 
UACC(UPDATE) or ID(*) UPDATE permission, whichever applies, for the conditional 
permission to take effect. Operations and Tech Support staff will need 
'regular' UPDATE access permission. (CONSOLE is a Default Return Code 8 class, 
so don't activate it without first creating a ** profile with UACC(READ).)

To see exactly what resource names are being checked that are allowing the 
unwanted job cancellations, issue the SDSF command SET SECTRACE ON, cancel the 
job, and then issue the SDSF command ULOG. ULOG will show you all the access 
checks SDSF is making along with the results of each of these checks. SECTRACE 
is a phenomenal diagnostic tool that we use often.

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.  *** Celebrating our 30th Anniversary ***
617-969-8211
http://www.linkedin.com/in/roberthansel
http://www.rshconsulting.com/

-Original Message-
Date:Tue, 7 Feb 2023 13:31:41 +
From:"Shaffer, Terri" 
Subject: RACF - SDSF question

Hi,
 I know there is a RACF group, but hopefully this is simple and I am just 
missing something I have done 100 times over with no issues.

Re: RACF, external password management

[Tom Marchant]

FWIW, the list of messages that I posted came from the web interface.

On Tue, 9 Apr 2024 22:25:57 +0100, Jeremy Nicoll 
 wrote:

>On Tue, 9 Apr 2024, at 21:29, Tom Marchant wrote:
>> I haven't noticed. How did you determine that they are gone? I see
>> these posts from you, some of which reference zMFA.
>
>I just looked in the list archive whose address is specified in the
>
>  List-Archive: 
>
>header in every mail.  I had to register a password for the website
>to do that ... but it looks as if the mails are there.
>
>So... does Linda mean that they vanished from her gmail account,
>or something else?

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

Re: RACF, external password management

[Jeremy Nicoll]

On Tue, 9 Apr 2024, at 21:29, Tom Marchant wrote:
> I haven't noticed. How did you determine that they are gone? I see 
> these posts from you, some of which reference zMFA.

I just looked in the list archive whose address is specified in the

  List-Archive: 

header in every mail.  I had to register a password for the website
to do that ... but it looks as if the mails are there.

So... does Linda mean that they vanished from her gmail account, 
or something else?

-- 
Jeremy Nicoll - my opinions are my own.

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

Re: RACF, external password management

[Tom Marchant]

I haven't noticed. How did you determine that they are gone? I see these posts 
from you, some of which reference zMFA.

Re: RACF, external password management  Linda Hagedorn 
   2024-02-29 15:53IBM-MAIN
Re: RACF, external password management  Linda Hagedorn 
   2024-02-29 13:00IBM-MAIN
Re: RACF, external password management  Linda Hagedorn 
   2024-02-29 12:44IBM-MAIN
Re: RACF, external password management  Linda Hagedorn 
   2024-02-29 12:43IBM-MAIN
Re: RACF, external password management  Linda Hagedorn 
   2024-02-29 12:31IBM-MAIN
Re: RACF, external password management  Linda Hagedorn 
   2024-02-29 12:30IBM-MAIN
RACF, external password management  Linda Hagedorn 
   2024-02-28 16:35IBM-MAIN

On Tue, 9 Apr 2024 13:20:56 -0500, Linda Hagedorn  
wrote:

>Has anyone else noticed their posts deleted?  
>My posts re: zMFA are gone.  Poof.

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

Re: RACF, external password management

[Linda Hagedorn]

Has anyone else noticed their posts deleted?  
My posts re: zMFA are gone.  Poof.  

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

Re: RACF/DB2 Search Question?

[Robert S. Hansel]

Hi Terri,

Temporarily add the UAUDIT attribute to the ID to generate SMF records for 
everything it touches, and use this information to help remediate its 
authority. For DB2-related activity, look in the LOGSTR field of the SMF record 
as this will often tell you what resource it was originally trying to use for 
which it needed a high-level authority to access. Permitting the ID access to 
the resources it is using could eliminate the need for high-level authorities 
and for the DBA group connection.

BTW, you might get more responses to questions like this by posting them on 
RACF-L.

Regards, Bob

Robert S. Hansel   2024 IBM Champion
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
www.rshconsulting.com

Upcoming RSH RACF Training - WebEx
- RACF Level I Administration - APR 22-26, 2024
- RACF Level II Administration - NOV 4-8, 2024
- RACF Level III Admin, Audit, & Compliance - DEC 9-13, 2024
- RACF - Securing z/OS UNIX  - SEPT 23-27, 2024
- zSecure Admin - Basic Administration - May 7-10, 2024
-

-Original Message-
Date:Wed, 3 Apr 2024 12:22:15 +
From:"Shaffer, Terri" 
Subject: RACF/DB2 Search Question?

Hi,
  One wondering if the RACF experts could answer something?

We are in the process of upgrading our DB2 from V8 to V13.1, which is actually 
working great, but they have a PC application that uses JDBC drivers to talk to 
DB2.

Everything works, Except a create tablespace command.  So in looking at things 
I found, I made sure the userid being passed has access to .sysadm rule, 
which is all it had before, but still failed with SQL -551.

Anyhow what I did to fix it was add the DBA group to that userid and everything 
started to work. However because that is more authority than I would like to 
give out, is there a way thru a RACF search or something other command I can 
find all the rules that has this specific GROUP specified? So maybe I can 
narrow down what Rule or MDSNxx or DSNADM Class that group has access to so I 
can narrow down that userid access to just what it needs?

We are a development shop, and its developers DB2, but I still don’t like 
giving more access than whats actually required.

Thanks.

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide – Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

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

Re: RACF, external password management

[Colin Paice]

I wrote One minute MVS: What is IBM Multi Factor Authentication on z/OS?
<https://colinpaice.blog/2024/01/07/one-minute-mvs-what-is-ibm-multi-factor-authentication-on-z-os/>
and a series of implementation posts starting with Multi Factor
Authentication(MFA): Planning.
<https://colinpaice.blog/2024/02/03/multi-factor-authenticationmfa-planning/>
I found the MFA product easy to set up and use.  I had little problems like
ordering the wrong YubiKey which did not support MFA!

Colin

On Sun, 3 Mar 2024 at 22:22, Jared Hunter 
wrote:

> Hi all,
>
> I’m an architect/implementor on the IBM Z MFA team since the prehistory /
> notional phase of the product.
>
> If folks would be interested in one or more “office hours” style Q+A
> sessions about the product and its (many, sometimes exotic) features, feel
> free to reach out to me at this address.
>
> No sales touch implied, just a question-driven tour of the tech and design
> philosophy.
>
> -Jared
>
> Jared Hunter
> Strategic Architect, Security
> Rocket Software, USA
> E: jhun...@rocketsoftware.com<mailto:jhun...@rocketsoftware.com>
>
>
>
> Date: Fri, 1 Mar 2024 06:24:45 +
> From: Timothy Sipples mailto:sipp...@sg.ibm.com>>
> Subject: Re: RACF, external password management
>
> Linda Hagedorn wrote:
> >This is very promising. Do you know where I can read more about ZMFA?
>
> The documentation landing page is here:
> https://www.ibm.com/docs/en/zma<https://www.ibm.com/docs/en/zma>
>
> >I'm interested in knowing how to configure the external source, and how
> >the token is passed back to RACF, and how long the token lasts.
> >For example, if systems programmers are working a problem, we
> >wouldn't want the token to expire in 3 hrs.
> >Or does the token last for the duration of the session?
> >If tso/ispf times out (sysprog is doing research or answering
> >mgmt questions), will they have to generate a new token?
>
> If for example you’re configuring ZMFA to use a LDAP server as an
> “external” factor then this landing page has further details:
> https://www.ibm.com/docs/en/zma/2.3.0?topic=customization-configuring-ldap
> <
> https://www.ibm.com/docs/en/zma/2.3.0?topic=customization-configuring-ldap
> >
>
> I put the word external in quotation marks because the LDAP server could
> be z/OS’s LDAP server or some other LDAP server running on the same IBM Z
> machine. And LDAP is just one example. Many “external” and external
> factors’ interfaces are supported.
>
> You can configure ZMFA for “out-of-band” authentication so that users
> obtain what’s called a “cache token credential” (CTC) to log into RACF (via
> TSO/E for example). You can choose whether the CTC is reusable and how
> quickly it expires.
>
>
> https://www.ibm.com/docs/en/zma/2.3.0?topic=policies-setting-policy-token-timeout
> <
> https://www.ibm.com/docs/en/zma/2.3.0?topic=policies-setting-policy-token-timeout
> >
>
> https://www.ibm.com/docs/en/zma/2.3.0?topic=policies-setting-cache-token-credential-be-reusable
> <
> https://www.ibm.com/docs/en/zma/2.3.0?topic=policies-setting-cache-token-credential-be-reusable
> >
>
> —
> Timothy Sipples
> Senior Architect
> Digital Assets, Industry Solutions, and Cybersecurity
> IBM Z/LinuxONE, Asia-Pacific
> sipp...@sg.ibm.com<mailto:sipp...@sg.ibm.com>
>
> 
> Rocket Software, Inc. and subsidiaries ¦ 77 Fourth Avenue, Waltham MA
> 02451 ¦ Main Office Toll Free Number: +1 855.577.4323
> Contact Customer Support:
> https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
> Unsubscribe from Marketing Messages/Manage Your Subscription Preferences -
> http://www.rocketsoftware.com/manage-your-email-preferences
> Privacy Policy -
> http://www.rocketsoftware.com/company/legal/privacy-policy
> 
>
> This communication and any attachments may contain confidential
> information of Rocket Software, Inc. All unauthorized use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> notify Rocket Software immediately and destroy all copies of this
> communication. Thank you.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: RACF, external password management

[Jared Hunter]

Hi all,

I’m an architect/implementor on the IBM Z MFA team since the prehistory / 
notional phase of the product.

If folks would be interested in one or more “office hours” style Q+A sessions 
about the product and its (many, sometimes exotic) features, feel free to reach 
out to me at this address.

No sales touch implied, just a question-driven tour of the tech and design 
philosophy.

-Jared

Jared Hunter
Strategic Architect, Security
Rocket Software, USA
E: jhun...@rocketsoftware.com<mailto:jhun...@rocketsoftware.com>



Date: Fri, 1 Mar 2024 06:24:45 +
From: Timothy Sipples mailto:sipp...@sg.ibm.com>>
Subject: Re: RACF, external password management

Linda Hagedorn wrote:
>This is very promising. Do you know where I can read more about ZMFA?

The documentation landing page is here:
https://www.ibm.com/docs/en/zma<https://www.ibm.com/docs/en/zma>

>I'm interested in knowing how to configure the external source, and how
>the token is passed back to RACF, and how long the token lasts.
>For example, if systems programmers are working a problem, we
>wouldn't want the token to expire in 3 hrs.
>Or does the token last for the duration of the session?
>If tso/ispf times out (sysprog is doing research or answering
>mgmt questions), will they have to generate a new token?

If for example you’re configuring ZMFA to use a LDAP server as an “external” 
factor then this landing page has further details:
https://www.ibm.com/docs/en/zma/2.3.0?topic=customization-configuring-ldap<https://www.ibm.com/docs/en/zma/2.3.0?topic=customization-configuring-ldap>

I put the word external in quotation marks because the LDAP server could be 
z/OS’s LDAP server or some other LDAP server running on the same IBM Z machine. 
And LDAP is just one example. Many “external” and external factors’ interfaces 
are supported.

You can configure ZMFA for “out-of-band” authentication so that users obtain 
what’s called a “cache token credential” (CTC) to log into RACF (via TSO/E for 
example). You can choose whether the CTC is reusable and how quickly it expires.

https://www.ibm.com/docs/en/zma/2.3.0?topic=policies-setting-policy-token-timeout<https://www.ibm.com/docs/en/zma/2.3.0?topic=policies-setting-policy-token-timeout>
https://www.ibm.com/docs/en/zma/2.3.0?topic=policies-setting-cache-token-credential-be-reusable<https://www.ibm.com/docs/en/zma/2.3.0?topic=policies-setting-cache-token-credential-be-reusable>

—
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM Z/LinuxONE, Asia-Pacific
sipp...@sg.ibm.com<mailto:sipp...@sg.ibm.com>


Rocket Software, Inc. and subsidiaries ¦ 77 Fourth Avenue, Waltham MA 02451 ¦ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: RACF, external password management

[Radoslaw Skorupka]

W dniu 01.03.2024 o 19:43, Seymour J Metz pisze:

And after the user is revoked. *permanently*.

Making a logon loop a convenient option for a DOS attack.


...and your proposal is?

(not to say userlist need not to be published)

--
Radoslaw Skorupka
Lodz, Poland

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

Re: RACF, external password management

[Timothy Sipples]

Frank Swarbrick wrote:
>I have a curious question about MFA on z/OS.  Does each login
>require a different token?  Meaning, if I log on to TSO and to CICS,
>can I use the same token?  I ask because I log on and off to
>various CICS regions throughout the day, and I'd hate to have to
>get a new token for each login.  (We don't use MFA right now,
>except for our mainframe "outsourcer" teams (Kyndryl).

That’s configurable based on what security posture you’re trying to maintain. 
The token can be one-time (and time limited) or can be reused (and still time 
limited). The time limit is configurable, too.

>I wish that you could just "logon to VTAM," as it were, and it would
>log you in to each VTAM application you use.  I don't think this is
>available right now, correct me if I'm wrong!

Yes, you can do that with a combination of CL/SUPERSESSION, Z MFA, and 
PassTickets. Other combinations may be possible, but that’s the typical IBM 
combination. The entry point to the documentation is here:

https://www.ibm.com/docs/en/zma/2.3.0?topic=customization-clsupersession-zos

—
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM Z/LinuxONE, Asia-Pacific
sipp...@sg.ibm.com


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

Re: RACF, external password management

[Steve Thompson]

Hi Frank:

2FA, where it calls you to get a code, or prompts you for a code 
off some security device (RSA?) will be per logon attempt. Now, 
if you have a session manager (of some kind), that may only 
require one response with the "token" they want, and the session 
manager may then not trigger 2FA for each logon under its control.


In the remote logons I've done, Cisco was effectively the session 
manager and handled the initial connection to customer site 
(using VPN). Once authenticated, it was basically a single 
sign-on -- with the exception of TSO and other Mainframe specific 
access/logons, but 2FA was not activated in that case.


YMMV as usual.

Steve Thompson





On 3/1/2024 5:49 PM, Frank Swarbrick wrote:

I have a curious question about MFA on z/OS.  Does each login require a different token?  
Meaning, if I log on to TSO and to CICS, can I use the same token?  I ask because I log 
on and off to various CICS regions throughout the day, and I'd hate to have to get a new 
token for each login.  (We don't use MFA right now, except for our mainframe 
"outsourcer" teams (Kyndryl).

I wish that you could just "logon to VTAM," as it were, and it would log you in 
to each VTAM application you use.  I don't think this is available right now, correct me 
if I'm wrong!

Frank

From: IBM Mainframe Discussion List  on behalf of Timothy 
Sipples 
Sent: Thursday, February 29, 2024 11:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: RACF, external password management

Linda Hagedorn wrote:

This is very promising. Do you know where I can read more about ZMFA?

The documentation landing page is here:
https://www.ibm.com/docs/en/zma


I'm interested in knowing how to configure the external source, and how
the token is passed back to RACF, and how long the token lasts.
For example, if systems programmers are working a problem, we
wouldn't want the token to expire in 3 hrs.
Or does the token last for the duration of the session?
If tso/ispf times out (sysprog is doing research or answering
mgmt questions), will they have to generate a new token?

If for example you’re configuring ZMFA to use a LDAP server as an “external” 
factor then this landing page has further details:
https://www.ibm.com/docs/en/zma/2.3.0?topic=customization-configuring-ldap

I put the word external in quotation marks because the LDAP server could be 
z/OS’s LDAP server or some other LDAP server running on the same IBM Z machine. 
And LDAP is just one example. Many “external” and external factors’ interfaces 
are supported.

You can configure ZMFA for “out-of-band” authentication so that users obtain 
what’s called a “cache token credential” (CTC) to log into RACF (via TSO/E for 
example). You can choose whether the CTC is reusable and how quickly it expires.

https://www.ibm.com/docs/en/zma/2.3.0?topic=policies-setting-policy-token-timeout
https://www.ibm.com/docs/en/zma/2.3.0?topic=policies-setting-cache-token-credential-be-reusable

—
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM Z/LinuxONE, Asia-Pacific
sipp...@sg.ibm.com


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

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


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

Re: RACF, external password management

[Frank Swarbrick]

I have a curious question about MFA on z/OS.  Does each login require a 
different token?  Meaning, if I log on to TSO and to CICS, can I use the same 
token?  I ask because I log on and off to various CICS regions throughout the 
day, and I'd hate to have to get a new token for each login.  (We don't use MFA 
right now, except for our mainframe "outsourcer" teams (Kyndryl).

I wish that you could just "logon to VTAM," as it were, and it would log you in 
to each VTAM application you use.  I don't think this is available right now, 
correct me if I'm wrong!

Frank

From: IBM Mainframe Discussion List  on behalf of 
Timothy Sipples 
Sent: Thursday, February 29, 2024 11:24 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: RACF, external password management

Linda Hagedorn wrote:
>This is very promising. Do you know where I can read more about ZMFA?

The documentation landing page is here:
https://www.ibm.com/docs/en/zma

>I'm interested in knowing how to configure the external source, and how
>the token is passed back to RACF, and how long the token lasts.
>For example, if systems programmers are working a problem, we
>wouldn't want the token to expire in 3 hrs.
>Or does the token last for the duration of the session?
>If tso/ispf times out (sysprog is doing research or answering
>mgmt questions), will they have to generate a new token?

If for example you’re configuring ZMFA to use a LDAP server as an “external” 
factor then this landing page has further details:
https://www.ibm.com/docs/en/zma/2.3.0?topic=customization-configuring-ldap

I put the word external in quotation marks because the LDAP server could be 
z/OS’s LDAP server or some other LDAP server running on the same IBM Z machine. 
And LDAP is just one example. Many “external” and external factors’ interfaces 
are supported.

You can configure ZMFA for “out-of-band” authentication so that users obtain 
what’s called a “cache token credential” (CTC) to log into RACF (via TSO/E for 
example). You can choose whether the CTC is reusable and how quickly it expires.

https://www.ibm.com/docs/en/zma/2.3.0?topic=policies-setting-policy-token-timeout
https://www.ibm.com/docs/en/zma/2.3.0?topic=policies-setting-cache-token-credential-be-reusable

—
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM Z/LinuxONE, Asia-Pacific
sipp...@sg.ibm.com


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

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

Re: RACF, external password management

[Seymour J Metz]

> And after the user is revoked. *permanently*.

Making a logon loop a convenient option for a DOS attack.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר


From: IBM Mainframe Discussion List  on behalf of 
Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu>
Sent: Friday, March 1, 2024 10:27 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF, external password management

W dniu 29.02.2024 o 21:53, Linda Hagedorn pisze:
> The regulations are from NY state, NYDFS.
> https://www.dfs.ny.gov/system/files/documents/2023/12/rf23_nycrr_part_500_amend02_20231101.pdf
>
>   500.7 Access privileges and management.
>
>   500.7(c) Each class A company shall monitor privileged access activity 
> and shall implement:
>   (1) a privileged access management solution; and
>   (2) an automated method of blocking commonly used passwords for all 
> accounts on
>   information systems owned or controlled by the class A company and 
> wherever feasible
>   for all other accounts.
>
> To automatically block commonly used passwords, a corpus is necessary.  For 
> example, Cybernews Investigation team was able to collect 15m passwords.*  If 
> they can do it, software vendors will see the opportunity here.
>
> It's one option to force all RACF password changes through a single point.  
> However, there's a lot of ways to reach the password change process in MVS, 
> and writing blocks for all of them isn't reasonable.
>
> The ZMFA holds promise, if I can find a software company that has 
> bought/collected the same 15m passwords that Cybernews did.  I can route all 
> RACF password changes to the  software company for 
> validation.
>
>
> *https://cybernews.com/best-password-managers/most-common-passwords/

I'm not a lawyer, however I did managed a lot of multi-million
contracts. And what I learned is accuracy and term definitions.
Regarding 500.7(c) (2)
1. What a complex numbering scheme :-)
2. Where "commonly used password" is defined? Is it as obvious as water,
Earth or kg?
3. What does it mean "blocking"? Should we check any *existing*
password? Or only new ones?
4. IMHO the ALPHANUM is the solution, because it "blocks" all English
dictionary. Of course one may say it doesn't block "PASSW0RD" (note the
zero, not o), but then we come back to the definition of "commonly used
password".
5. BTW: When you search "the most popular passwords" you will find
several lists, but majority of them contain lowercase strings, sometimes
mixed case. Conclusion: do not allow lowercase letters. :-)


Oh, BTW: I don't care how many passwords some company collected. First,
it is not applicable, second I do not trust them.
BTW2: most of us use 4-character password, no mixed case, no
punctuation, no alphabetic letter. Just four numbers. And the password
is used for access to our money. We call it PIN.
BTW3: Apples and oranges. There is no big reason to compare password
from completely different systems, usually poor social media, fora
(forums), e-shops, etc. Not to mention very few of top 10 would pass
regular syntax checking ALPHANUM.
BTW4: In RACF world we have limited number of attempts. And after the
user is revoked. *permanently*.



--

Radoslaw Skorupka
Lodz, Poland

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

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

Re: RACF, external password management

[Radoslaw Skorupka]

W dniu 29.02.2024 o 21:53, Linda Hagedorn pisze:

The regulations are from NY state, NYDFS.
https://www.dfs.ny.gov/system/files/documents/2023/12/rf23_nycrr_part_500_amend02_20231101.pdf

  500.7 Access privileges and management.

  500.7(c) Each class A company shall monitor privileged access activity 
and shall implement:
  (1) a privileged access management solution; and
  (2) an automated method of blocking commonly used passwords for all 
accounts on
  information systems owned or controlled by the class A company and 
wherever feasible
  for all other accounts.

To automatically block commonly used passwords, a corpus is necessary.  For 
example, Cybernews Investigation team was able to collect 15m passwords.*  If 
they can do it, software vendors will see the opportunity here.

It's one option to force all RACF password changes through a single point.  
However, there's a lot of ways to reach the password change process in MVS, and 
writing blocks for all of them isn't reasonable.
  
The ZMFA holds promise, if I can find a software company that has bought/collected the same 15m passwords that Cybernews did.  I can route all RACF password changes to the  software company for validation.



*https://cybernews.com/best-password-managers/most-common-passwords/   


I'm not a lawyer, however I did managed a lot of multi-million 
contracts. And what I learned is accuracy and term definitions.

Regarding 500.7(c) (2)
1. What a complex numbering scheme :-)
2. Where "commonly used password" is defined? Is it as obvious as water, 
Earth or kg?
3. What does it mean "blocking"? Should we check any *existing* 
password? Or only new ones?
4. IMHO the ALPHANUM is the solution, because it "blocks" all English 
dictionary. Of course one may say it doesn't block "PASSW0RD" (note the 
zero, not o), but then we come back to the definition of "commonly used 
password".
5. BTW: When you search "the most popular passwords" you will find 
several lists, but majority of them contain lowercase strings, sometimes 
mixed case. Conclusion: do not allow lowercase letters. :-)



Oh, BTW: I don't care how many passwords some company collected. First, 
it is not applicable, second I do not trust them.
BTW2: most of us use 4-character password, no mixed case, no 
punctuation, no alphabetic letter. Just four numbers. And the password 
is used for access to our money. We call it PIN.
BTW3: Apples and oranges. There is no big reason to compare password 
from completely different systems, usually poor social media, fora 
(forums), e-shops, etc. Not to mention very few of top 10 would pass 
regular syntax checking ALPHANUM.
BTW4: In RACF world we have limited number of attempts. And after the 
user is revoked. *permanently*.




--

Radoslaw Skorupka
Lodz, Poland

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

Re: RACF, external password management

[Radoslaw Skorupka]

It does not, however password exit can provide same functionality.

BTW: In my opinion it is big lack in RACF features.
IBM take care about GUI, java, python etc. to make the platform more 
attractive to young IT folks. However sometimes it would be nice to have 
sample job with list of words, it does not to be integrated with z/OSMF, 
API, java, go lang.


--
Radoslaw Skorupka
Lodz, Poland



W dniu 01.03.2024 o 05:08, Michael Brennan pisze:

Both ACF2 and Top Secret have common phrases that can not be used for
passwords and you can add or subtract from the list.  You would think RACF
would have the same. I have not dug through the RACF manuals to determine
if it does or not.

On Thu, Feb 29, 2024 at 12:09 AM Timothy Sipples  wrote:


Linda Hagedorn wrote:

My company wants an external password manager to substitute for RACF.
I need to know if anyone has experience with this, or common password
matching in RACF.
Background
Regulations NYDFS require preventing common passwords to be used.
Vendor tools (Courion, CyberArk, etc.) have a corpus to match password
changes to prevent the use of common passwords.
RACF passwords can be changed from TSO, the internal reader, JCL,
Candle Session manager, etc., so trying to block password changing through
RACF and forcing everyone through one of these 3rd party tools may be near
impossible.
Any input is appreciated.

This’d be easy to do with IBM Z Multi Factor Authentication (ZMFA).
Despite its name you could use ZMFA to support a single “external” factor
such as a super vetted passphrase verifier, although it’d obviously be best
to have a genuine second factor too (while you’re at it).

Let’s suppose for example you maintain/update these super rule compliant
passphrases in a LDAP server. OK, then configure ZMFA so that it validates
passphrases against the LDAP server and gives RACF yes or no decisions. You
could for example use “out-of-band” authentication so that users who clear
the ZMFA hurdle (log in via a secure Web page) get a one-time token that
they use to log into RACF (in place of a password). And then you’ve neatly
solved the problem of handling RACF password/passphrase changes everywhere.
Other variations are possible — this is just an example.

If you’re concerned about the “What if the LDAP server is down,
unreachable, or slow?” scenarios then one straightforward solution is to
use z/OS’s LDAP server and simply keep that LDAP server synced reasonably
well with another LDAP server. (LDAP supports syncing.) In that case ZMFA
simply loops back to z/OS LDAP, an ultra short loop. If the syncing is down
for a little while it’s not a calamity. Or use another LDAP server that
runs in the z/OS Container Extensions or in a Linux on IBM Z partition.
LDAP is just an example too, although it’s a common one.

https://www.ibm.com/products/ibm-multifactor-authentication-for-zos

—
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM Z/LinuxONE, Asia-Pacific
sipp...@sg.ibm.com


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





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

Re: RACF, external password management

[kekronbekron]

MFA and this aren't either or. They're different things.

Can the exit only run REXX, or can any language's compiled code be called there 
(with ADDRESS ...)?



On Friday, March 1st, 2024 at 18:17, Robert S. Hansel 
 wrote:

> Hi Linda,
> 
> Short term solution is to implement the RACF password change exit ICHPWX01 
> and its companion System REXX module IRRPWREX module. Relatively simple to 
> implement and governs all password changes. IRRPWREX has numerous options you 
> can activate, such as disallowing repeating characters and specific character 
> strings, that can address the common password prohibition requirement. The 
> IBM-provided exit code is available on GitHub:
> 
> https://github.com/IBM/IBM-Z-zOS/tree/main/zOS-RACF/Downloads/RexxPwExit
> 
> Also, implement KDFAES password encryption if you have not already done so. 
> And I recommend a single SETROPTS PASSWORD RULE of LENGTH(8) MIXEDALL(1:8), 
> which requires a password to be 8 characters in length and have at least one 
> letter, one number, and one special character (e.g., National Characters). 
> This rule alone will block many of the common passwords. Be sure all your 
> resource managers processing logons can handle special characters.
> 
> Longer term solution is MFA.
> 
> I recommend you contact the authors of this regulation and ask them to 
> provide you with the list of common passwords they expect you to disallow.
> 
> Regards, Bob
> 
> Robert S. Hansel 2024 IBM Champion
> Lead RACF Specialist
> RSH Consulting, Inc.
> 617-969-8211
> www.linkedin.com/in/roberthansel
> www.rshconsulting.com
> 
> -Original Message-
> Date: Thu, 29 Feb 2024 14:53:36 -0600
> From: Linda Hagedorn linda.haged...@gmail.com
> 
> Subject: Re: RACF, external password management
> 
> The regulations are from NY state, NYDFS.
> https://www.dfs.ny.gov/system/files/documents/2023/12/rf23_nycrr_part_500_amend02_20231101.pdf
> 
> 500.7 Access privileges and management.
> 
> 500.7(c) Each class A company shall monitor privileged access activity and 
> shall implement:
> (1) a privileged access management solution; and
> (2) an automated method of blocking commonly used passwords for all accounts 
> on
> information systems owned or controlled by the class A company and wherever 
> feasible
> for all other accounts.
> 
> To automatically block commonly used passwords, a corpus is necessary. For 
> example, Cybernews Investigation team was able to collect 15m passwords.* If 
> they can do it, software vendors will see the opportunity here.
> 
> It's one option to force all RACF password changes through a single point. 
> However, there's a lot of ways to reach the password change process in MVS, 
> and writing blocks for all of them isn't reasonable.
> 
> The ZMFA holds promise, if I can find a software company that has 
> bought/collected the same 15m passwords that Cybernews did. I can route all 
> RACF password changes to the  software company for 
> validation.
> 
> 
> 
> *https://cybernews.com/best-password-managers/most-common-passwords/
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Subject: Re: RACF, external password management

[billogden]

A simple suggestion: Do not let this project create an even worse situation!
More recent z/OS setups (with RACF) can "disable" a userid after "n"
password failures. ("n" is often 3.) If your userids are easily
found/duplicated, a really bad guy could, with relatively minor
Linux/Windows scripts, disable many of your userids! (RACF SPECIAL users
have a way around this, but that method depends on prompt z/OS operator
actions, etc. Unfortunately, some z/OS installations have almost banished
the operator functions and have very, very few SPECIAL users --- and these
few might not be readily available if this situation happens.)

Long, long ago I was involved in minor "checkups" of OS/390 security
situations. In those days, long ago, it was not too difficult to monitor
token-ring traffic to see userids/password. We also wrote a program that
checked a list of about 5000 "common passwords" we helped create. (A
surprisingly large number were variations of profane/obscene words.) This
list might have been useful to push users into a thought pattern for
"acceptable" passwords and this "thought pattern" itself was a bad result.
This was long ago, and I realize things are more sophisticated now.

Bill

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

Re: RACF, external password management

[Robert S. Hansel]

Hi Linda,

Short term solution is to implement the RACF password change exit ICHPWX01 and 
its companion System REXX module IRRPWREX module. Relatively simple to 
implement and governs all password changes. IRRPWREX has numerous options you 
can activate, such as disallowing repeating characters and specific character 
strings, that can address the common password prohibition requirement. The 
IBM-provided exit code is available on GitHub:

https://github.com/IBM/IBM-Z-zOS/tree/main/zOS-RACF/Downloads/RexxPwExit

Also, implement KDFAES password encryption if you have not already done so. And 
I recommend a single SETROPTS PASSWORD RULE of LENGTH(8) MIXEDALL(1:8), which 
requires a password to be 8 characters in length and have at least one letter, 
one number, and one special character (e.g., National Characters). This rule 
alone will block many of the common passwords. Be sure all your resource 
managers processing logons can handle special characters.

Longer term solution is MFA.

I recommend you contact the authors of this regulation and ask them to provide 
you with the list of common passwords they expect you to disallow.

Regards, Bob

Robert S. Hansel   2024 IBM Champion
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
www.rshconsulting.com

-Original Message-
Date:Thu, 29 Feb 2024 14:53:36 -0600
From:Linda Hagedorn 
Subject: Re: RACF, external password management

The regulations are from NY state, NYDFS.  
https://www.dfs.ny.gov/system/files/documents/2023/12/rf23_nycrr_part_500_amend02_20231101.pdf

 500.7 Access privileges and management.

 500.7(c) Each class A company shall monitor privileged access activity and 
shall implement:
 (1) a privileged access management solution; and
 (2) an automated method of blocking commonly used passwords for all 
accounts on
 information systems owned or controlled by the class A company and 
wherever feasible
 for all other accounts.  

To automatically block commonly used passwords, a corpus is necessary.  For 
example, Cybernews Investigation team was able to collect 15m passwords.*  If 
they can do it, software vendors will see the opportunity here.   

It's one option to force all RACF password changes through a single point.  
However, there's a lot of ways to reach the password change process in MVS, and 
writing blocks for all of them isn't reasonable.  
 
The ZMFA holds promise, if I can find a software company that has 
bought/collected the same 15m passwords that Cybernews did.  I can route all 
RACF password changes to the  software company for 
validation.  


*https://cybernews.com/best-password-managers/most-common-passwords/

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

Re: RACF, external password management

[Timothy Sipples]

Michael 
Brennan
 wrote:

>Both ACF2 and Top Secret have common phrases that can not be

>used for passwords and you can add or subtract from the list.

>You would think RACF would have the same. I have not dug through

>the RACF manuals to determine if it does or not.



RACF has a new-passphrase exit called ICHPWX11. IBM provides a sample exit 
routine, and you can use REXX to run whatever passphrase quality checks you 
wish. The REXX script could even make an external (or “external”) network call 
to check the passphrase against some database. But you’d have to write and 
maintain this REXX code, and it wouldn’t provide multi-factor authentication. 
It’d merely help strengthen new passphrase selections.



https://www.ibm.com/docs/en/zos/3.1.0?topic=users-assigning-password-phrases

—
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM Z/LinuxONE, Asia-Pacific
sipp...@sg.ibm.com


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

Re: RACF, external password management

[Timothy Sipples]

Linda Hagedorn wrote:
>It's one option to force all RACF password changes through a single
>point.  However, there's a lot of ways to reach the password change
>process in MVS, and writing blocks for all of them isn't reasonable.
>The ZMFA holds promise, if I can find a software company that has
>bought/collected the same 15m passwords that Cybernews did.
>I can route all RACF password changes to the 
>software company for validation.

Not that it’s necessarily the only way to do it, but what I’m thinking with 
ZMFA is that you’d already have passphrases somewhere that have been validated 
(and that are changed and managed) according to your requirements, including 
vetting against previously breached passphrases. These passphrases are already 
residing in an enterprise-wide LDAP server, for example. I’m assuming RACF 
isn’t the only security authenticator that needs to meet this requirement. You 
probably have many other systems and applications that also need to meet this 
requirement, and they’re depending on passphrases stored/managed somewhere.

So, users would stop changing or managing RACF passwords/passphrases. RACF 
wouldn’t even allow it, really, because their user IDs are marked as 
MFA-enabled IDs. That means RACF will loop through ZMFA when they try to log 
in. Users’ would instead first log into ZMFA “out-of-band,” provide their 
enterprise LDAP-stored passphrases, and get back 8 character tokens that 
expire. These tokens can be one-time use or multiple use (always within their 
validity periods). Users then treat the 8 character token as a RACF password to 
log in RACF, and since the user ID is MFA-enabled RACF checks with ZMFA that 
the token/password is valid. ZMFA says, “Yes, that’s the user I just gave that 
token to, it’s not an expired token, and (if one-time use) it hasn’t been used 
before” then tells RACF it’s OK to let that user in. When a user wants to 
change his/her passphrase they do that in the enterprise passphrase database, 
against that LDAP server, not in RACF at all. (They don’t get the opportunity 
to do so. Effectively they’re changing their password every time they grab a 
new token, and that password can be one-time use and always has a relatively 
short validity period.)

As Radoslaw Skorupka wisely pointed out, a passphrase, no matter how well 
managed and vetted, is only one factor. It’s best to authenticate with a second 
strong factor and the passphrase. ZMFA can do this, too. It has “Multi” in its 
name, after all. :-) You can adopt ZMFA in a phased approach if you’re not 
ready to add the second factor immediately. For example, you could first 
require “privileged” users to provide vetted/well-managed passphrases (stored 
in a LDAP server for example) to get their RACF log-in tokens. Then extend this 
requirement to every RACF user ID (except non-human machine ones of course). 
Then require “privileged” users to log in using 2 factors (the 
vetted/well-managed passphrase plus a 6 digit code from an IBM or Google 
authenticator app on their mobile device, for example). Then extend 2 factor 
authentication (2FA) to every user.

—
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM Z/LinuxONE, Asia-Pacific
sipp...@sg.ibm.com


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

Re: RACF, external password management

[Timothy Sipples]

Linda Hagedorn wrote:
>This is very promising. Do you know where I can read more about ZMFA?

The documentation landing page is here:
https://www.ibm.com/docs/en/zma

>I'm interested in knowing how to configure the external source, and how
>the token is passed back to RACF, and how long the token lasts.
>For example, if systems programmers are working a problem, we
>wouldn't want the token to expire in 3 hrs.
>Or does the token last for the duration of the session?
>If tso/ispf times out (sysprog is doing research or answering
>mgmt questions), will they have to generate a new token?

If for example you’re configuring ZMFA to use a LDAP server as an “external” 
factor then this landing page has further details:
https://www.ibm.com/docs/en/zma/2.3.0?topic=customization-configuring-ldap

I put the word external in quotation marks because the LDAP server could be 
z/OS’s LDAP server or some other LDAP server running on the same IBM Z machine. 
And LDAP is just one example. Many “external” and external factors’ interfaces 
are supported.

You can configure ZMFA for “out-of-band” authentication so that users obtain 
what’s called a “cache token credential” (CTC) to log into RACF (via TSO/E for 
example). You can choose whether the CTC is reusable and how quickly it expires.

https://www.ibm.com/docs/en/zma/2.3.0?topic=policies-setting-policy-token-timeout
https://www.ibm.com/docs/en/zma/2.3.0?topic=policies-setting-cache-token-credential-be-reusable

—
Timothy Sipples
Senior Architect
Digital Assets, Industry Solutions, and Cybersecurity
IBM Z/LinuxONE, Asia-Pacific
sipp...@sg.ibm.com


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

Re: RACF, external password management

[Michael Brennan]

Both ACF2 and Top Secret have common phrases that can not be used for
passwords and you can add or subtract from the list.  You would think RACF
would have the same. I have not dug through the RACF manuals to determine
if it does or not.

On Thu, Feb 29, 2024 at 12:09 AM Timothy Sipples  wrote:

> Linda Hagedorn wrote:
> >My company wants an external password manager to substitute for RACF.
> >I need to know if anyone has experience with this, or common password
> >matching in RACF.
> >Background
> >Regulations NYDFS require preventing common passwords to be used.
> >Vendor tools (Courion, CyberArk, etc.) have a corpus to match password
> >changes to prevent the use of common passwords.
> >RACF passwords can be changed from TSO, the internal reader, JCL,
> >Candle Session manager, etc., so trying to block password changing through
> >RACF and forcing everyone through one of these 3rd party tools may be near
> >impossible.
> >Any input is appreciated.
>
> This’d be easy to do with IBM Z Multi Factor Authentication (ZMFA).
> Despite its name you could use ZMFA to support a single “external” factor
> such as a super vetted passphrase verifier, although it’d obviously be best
> to have a genuine second factor too (while you’re at it).
>
> Let’s suppose for example you maintain/update these super rule compliant
> passphrases in a LDAP server. OK, then configure ZMFA so that it validates
> passphrases against the LDAP server and gives RACF yes or no decisions. You
> could for example use “out-of-band” authentication so that users who clear
> the ZMFA hurdle (log in via a secure Web page) get a one-time token that
> they use to log into RACF (in place of a password). And then you’ve neatly
> solved the problem of handling RACF password/passphrase changes everywhere.
> Other variations are possible — this is just an example.
>
> If you’re concerned about the “What if the LDAP server is down,
> unreachable, or slow?” scenarios then one straightforward solution is to
> use z/OS’s LDAP server and simply keep that LDAP server synced reasonably
> well with another LDAP server. (LDAP supports syncing.) In that case ZMFA
> simply loops back to z/OS LDAP, an ultra short loop. If the syncing is down
> for a little while it’s not a calamity. Or use another LDAP server that
> runs in the z/OS Container Extensions or in a Linux on IBM Z partition.
> LDAP is just an example too, although it’s a common one.
>
> https://www.ibm.com/products/ibm-multifactor-authentication-for-zos
>
> —
> Timothy Sipples
> Senior Architect
> Digital Assets, Industry Solutions, and Cybersecurity
> IBM Z/LinuxONE, Asia-Pacific
> sipp...@sg.ibm.com
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Michael Brennan

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

Re: RACF, external password management

[roscoe5]

I like it. And there are more than one potential software vendors reading your 
request on this site. ;-)

Sent from [Proton Mail](https://proton.me/mail/home) for iOS

On Thu, Feb 29, 2024 at 3:53 PM, Linda Hagedorn 
<[05cf4637de00-dmarc-requ...@listserv.ua.edu](mailto:On Thu, Feb 29, 2024 
at 3:53 PM, Linda Hagedorn < wrote:

> The regulations are from NY state, NYDFS.
> https://www.dfs.ny.gov/system/files/documents/2023/12/rf23_nycrr_part_500_amend02_20231101.pdf
>
> 500.7 Access privileges and management.
>
> 500.7(c) Each class A company shall monitor privileged access activity and 
> shall implement:
> (1) a privileged access management solution; and
> (2) an automated method of blocking commonly used passwords for all accounts 
> on
> information systems owned or controlled by the class A company and wherever 
> feasible
> for all other accounts.
>
> To automatically block commonly used passwords, a corpus is necessary. For 
> example, Cybernews Investigation team was able to collect 15m passwords.* If 
> they can do it, software vendors will see the opportunity here.
>
> It's one option to force all RACF password changes through a single point. 
> However, there's a lot of ways to reach the password change process in MVS, 
> and writing blocks for all of them isn't reasonable.
>
> The ZMFA holds promise, if I can find a software company that has 
> bought/collected the same 15m passwords that Cybernews did. I can route all 
> RACF password changes to the  software company for 
> validation.
>
> *https://cybernews.com/best-password-managers/most-common-passwords/
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: RACF, external password management

[Linda Hagedorn]

The regulations are from NY state, NYDFS.  
https://www.dfs.ny.gov/system/files/documents/2023/12/rf23_nycrr_part_500_amend02_20231101.pdf

 500.7 Access privileges and management.

 500.7(c) Each class A company shall monitor privileged access activity and 
shall implement:
 (1) a privileged access management solution; and
 (2) an automated method of blocking commonly used passwords for all 
accounts on
 information systems owned or controlled by the class A company and 
wherever feasible
 for all other accounts.  

To automatically block commonly used passwords, a corpus is necessary.  For 
example, Cybernews Investigation team was able to collect 15m passwords.*  If 
they can do it, software vendors will see the opportunity here.   

It's one option to force all RACF password changes through a single point.  
However, there's a lot of ways to reach the password change process in MVS, and 
writing blocks for all of them isn't reasonable.  
 
The ZMFA holds promise, if I can find a software company that has 
bought/collected the same 15m passwords that Cybernews did.  I can route all 
RACF password changes to the  software company for 
validation.  


*https://cybernews.com/best-password-managers/most-common-passwords/

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

Re: RACF, external password management

[Radoslaw Skorupka]

W dniu 28.02.2024 o 22:35, Linda Hagedorn pisze:

My company wants an external password manager to substitute for RACF.
I need to know if anyone has experience with this, or common password matching 
in RACF.

Background
Regulations NYDFS require preventing common passwords to be used.
Vendor tools (Courion, CyberArk, etc.) have a corpus to match password changes 
to prevent the use of common passwords.
RACF passwords can be changed from TSO, the internal reader, JCL, Candle 
Session manager, etc., so trying to block password changing through RACF and 
forcing everyone through one of these 3rd party tools may be near impossible.

Any input is appreciated.  Thanks!  Linda


My humble input: go MFA.
Explanation
You can easily forbid dictionary passwords by ALPHANUM - a mix of 
alphabetics and numbers.
So, no sophisticated English (or Polish) word will be accepted. However 
PASSWRD1 will be.

You can enforce use of uppercase and lowercase. Passwrd1 will be accepted.
You can turn off old passwords and enforce pass phrases. "My Password01" 
will be accepted. Yes, with the space.
You can create and maintain your own black list of forbidden passwords - 
now neither of the above will not be accepted. However this is a little 
bit more complex - you need to code and maintain password (passphrase) 
exit. It can be REXX code.


Finally you still have a problem - your employee used his car plate 
number, for example LDB-9091. Looks fine, but ethical hacker will try 
this id. Mother's name? Wife's car plate number? No. You are not able to 
collect that information, but ethical hacker would try it!


The solution is MFA. Yes, the password is still important, however the 
hacker has no token.

Advantage: JOHN will no longer be able to share his password with MARY.

--
Radoslaw Skorupka
Lodz, Poland

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

Re: RACF, external password management

[Howard Rifkind]

Sorry no; was this problem on the main frame?  

Sent from my iPhone

> On Feb 29, 2024, at 13:00, Linda Hagedorn 
> <05cf4637de00-dmarc-requ...@listserv.ua.edu> wrote:
> 
> In the process you describe, could I still while logged into tso/ispf change 
> my password in RACF, bypassing the AD routine?  
> 
> // JOB (ACCT INFO),'PGMR INFO',
> // CLASS=??,MSGCLASS=??,NOTIFY=userid,
> // USER=userid,PASSWORD=(OLDPASS,NEWPASS)
> //IEBFR14  EXEC  PGM=IEFBR14  
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: RACF, external password management

[Steve Thompson]

I think the exit point(s) mentioned by others is(are) where you 
would check the clear text against those common passwords, and 
reject that password change at that point.


Specifically to your question "any development to ingest": Unless 
you can find a vendor to provide you with such, your "shop" may 
have to do this, updating the table (or disk file) that contains 
the proscribed passwords.


And another thing you have to think about: Can you set rules that 
could keep such passwords from being tried?


Let's say they all have in common the use of $$, or ## or some 
such, so you would restrict any character from being repeated. 
But at the same time, suppose this is only seen in passwords of 
less than 10 characters...


[I've been exposed to many different systems with different rules].

Not that you would want to go this far, but you may need to go to 
2FA, depending on how secure you have to be (that could be a pain 
in your submit a job to change pswd


Another question: How do you make up your user-IDs? Now looking 
at the common passwords, can one know what user id was 
associated? This goes to the exposure you have to these common 
passwords.


   How many attempts to user-id revoked?
   How does one get their id restored?

   Suppose you are logged on, and a dictionary attack is done
   and your ID is now flagged as revoked. How do you get out of
   this?

Many things to think about. But mostly what is your exposure to 
an attack?


What if I wanted to shut down your biz? If I know how all of your 
user-ids are constructed, and I can get access to your system, 
somehow, and do dictionary attacks to cause all IDs to get 
revoked  It has been done.


Steve Thompson


On 2/29/2024 12:44 PM, Linda Hagedorn wrote:

Do you know if there's any development to ingest the list of passwords known to 
be involved in breaches, and match RACF password changes against them?

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


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

Re: RACF, external password management

[Linda Hagedorn]

In the process you describe, could I still while logged into tso/ispf change my 
password in RACF, bypassing the AD routine?  

// JOB (ACCT INFO),'PGMR INFO',
// CLASS=??,MSGCLASS=??,NOTIFY=userid,
// USER=userid,PASSWORD=(OLDPASS,NEWPASS)
//IEBFR14  EXEC  PGM=IEFBR14

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

Re: RACF, external password management

[Linda Hagedorn]

Do you know if there's any development to ingest the list of passwords known to 
be involved in breaches, and match RACF password changes against them?

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

Re: RACF, external password management

[Linda Hagedorn]

This is very promising.  Do you know where I can read more about ZMFA?  

I'm interested in knowing how to configure the external source, and how the 
token is passed back to RACF, and how long the token lasts.  

For example, if systems programmers are working a problem, we wouldn't want the 
token to expire in 3 hrs.  
Or does the token last for the duration of the session?  
If tso/ispf times out (sysprog is doing research or answering mgmt questions), 
will they have to generate a new token?

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

Re: RACF, external password management

[Linda Hagedorn]

Commonly used passwords and those found in breaches (dark web for example). 

P@$$w0rd, etc.

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

Re: RACF, external password management

[Linda Hagedorn]

This is exactly where I'm going.  

I think IBM should, if they haven't already, find a way to register the 
frequently found passwords and make an option to scan the PW in RACF.  
There may be a liability, but certainly a disclaimer can be included in the 
license.  

If this already exists, a referral to the manuals would be appreciated.  
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF, external password management

[kekronbekron]

Hi Bob,

If it is what I am thinking... I didn't think this day would come.
There are hashes of known, breached passwords generally collected.
Here's the most prominent one - https://haveibeenpwned.com/Passwords

There are blog posts on the same site explaining what it is, how to use that 
collection, etc.
Would be fun indeed if the collection can be brought to zOS and RACF/ACF2 
adapted to look up a new pw in it, before using/setting it.


On Thursday, February 29th, 2024 at 17:13, Robert S. Hansel 
 wrote:

> Hi Linda,
> 
> How do you define "common password"?
> 
> Regards, Bob
> 
> Robert S. Hansel 2024 IBM Champion
> Lead RACF Specialist
> RSH Consulting, Inc.
> 617-969-8211
> www.linkedin.com/in/roberthansel
> www.rshconsulting.com
> 
> -Original Message-
> Date: Wed, 28 Feb 2024 15:35:54 -0600
> From: Linda Hagedorn linda.haged...@gmail.com
> 
> Subject: RACF, external password management
> 
> My company wants an external password manager to substitute for RACF.
> I need to know if anyone has experience with this, or common password 
> matching in RACF.
> 
> Background
> Regulations NYDFS require preventing common passwords to be used.
> Vendor tools (Courion, CyberArk, etc.) have a corpus to match password 
> changes to prevent the use of common passwords.
> RACF passwords can be changed from TSO, the internal reader, JCL, Candle 
> Session manager, etc., so trying to block password changing through RACF and 
> forcing everyone through one of these 3rd party tools may be near impossible.
> 
> Any input is appreciated. Thanks! Linda
> 
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: RACF, external password management

[Robert S. Hansel]

Hi Linda,

How do you define "common password"?

Regards, Bob

Robert S. Hansel   2024 IBM Champion
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
www.rshconsulting.com

-Original Message-
Date:Wed, 28 Feb 2024 15:35:54 -0600
From:Linda Hagedorn 
Subject: RACF, external password management

My company wants an external password manager to substitute for RACF.  
I need to know if anyone has experience with this, or common password matching 
in RACF.  

Background
Regulations NYDFS require preventing common passwords to be used. 
Vendor tools (Courion, CyberArk, etc.) have a corpus to match password changes 
to prevent the use of common passwords.  
RACF passwords can be changed from TSO, the internal reader, JCL, Candle 
Session manager, etc., so trying to block password changing through RACF and 
forcing everyone through one of these 3rd party tools may be near impossible. 

Any input is appreciated.  Thanks!  Linda  

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

Re: RACF, external password management

[Jack Zukt]

Hi,
If what you need is to prevent users from using easy to guess passwords,
RACF already has the tools that you need, from implementing mixed case,
passphrases, and special characters, or/and using the password or
passphrase exit, which is very easy to implement, to validate password
complexity and preventing the use of any words you want.
Regards
Jack

On Wed, Feb 28, 2024, 21:36 Linda Hagedorn <
05cf4637de00-dmarc-requ...@listserv.ua.edu> wrote:

> My company wants an external password manager to substitute for RACF.
> I need to know if anyone has experience with this, or common password
> matching in RACF.
>
> Background
> Regulations NYDFS require preventing common passwords to be used.
> Vendor tools (Courion, CyberArk, etc.) have a corpus to match password
> changes to prevent the use of common passwords.
> RACF passwords can be changed from TSO, the internal reader, JCL, Candle
> Session manager, etc., so trying to block password changing through RACF
> and forcing everyone through one of these 3rd party tools may be near
> impossible.
>
> Any input is appreciated.  Thanks!  Linda
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: RACF, external password management

[Steve Thompson]

Hi Linda:

Could you define common passwords?

Are we talking about commonly used passwords? Or are we talking 
about a password that is common to multiple users IDs?


Suppose you were to use three Chars and then numbers to make up a 
TSO ID. These are the IDs used by people that do not need access 
to system level datasets other than read (PROCLIBs, MACRO, COPY, 
etc.). So for an example we have ABC01234. So ABC needs a second 
ID (I'm used to having 3 or more), so we have ABC1234, ABC1235, 
ABC1237 (someone else got in there).  Are these three prohibited 
from having the same password?


Now, take me for example. Not only do I have those IDs that I use 
for programming, looking at DUMPS and tests, I also have an ID 
for updating certain system files. So we will do this one 
differently. ABCX001 is my system level ID. I would NOT have it 
have the same password, but you might want to enforce that.


RACF, as I understand it, may have the ability to keep a history 
so that a password can't be reused within 6 months or 9 90day 
cycles which ever is more restrictive. (I had to take RACF admin 
classes, I don't remember a lot because I never intended to be a 
RACF admin - it was needed for "SAF" and product security).


So are these questions and "contrived" circumstances matching 
your situation for what you have to handle?


Another thing that has to be recognized -- changing of passwords 
too often can result in problems for history. But changing not 
often enough is a different exposure.


So, is this being driven by auditors, or something else?

Steve Thompson


On 2/28/2024 4:35 PM, Linda Hagedorn wrote:

My company wants an external password manager to substitute for RACF.
I need to know if anyone has experience with this, or common password matching 
in RACF.

Background
Regulations NYDFS require preventing common passwords to be used.
Vendor tools (Courion, CyberArk, etc.) have a corpus to match password changes 
to prevent the use of common passwords.
RACF passwords can be changed from TSO, the internal reader, JCL, Candle 
Session manager, etc., so trying to block password changing through RACF and 
forcing everyone through one of these 3rd party tools may be near impossible.

Any input is appreciated.  Thanks!  Linda

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


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

Re: RACF, external password management

[Jousma, David]

Linda,

I'd think twice on this topic.   We do vault our elevated access id's and I am 
fine with that, but to hand off all password management is a solution looking 
for a problem.

There is the racf password quality exit that can be coded up to disallow 
"common" passwords.  On top of that, you can "Force" passphrase use with 
minimum length requirements making such common passwords pretty much a thing of 
the past.

Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of 
Linda Hagedorn <05cf4637de00-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, February 28, 2024 4:35:54 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: RACF, external password management

My company wants an external password manager to substitute for RACF. I need to 
know if anyone has experience with this, or common password matching in RACF. 
Background Regulations NYDFS require preventing common passwords to be used. 
Vendor


My company wants an external password manager to substitute for RACF.
I need to know if anyone has experience with this, or common password matching 
in RACF.

Background
Regulations NYDFS require preventing common passwords to be used.
Vendor tools (Courion, CyberArk, etc.) have a corpus to match password changes 
to prevent the use of common passwords.
RACF passwords can be changed from TSO, the internal reader, JCL, Candle 
Session manager, etc., so trying to block password changing through RACF and 
forcing everyone through one of these 3rd party tools may be near impossible.

Any input is appreciated.  Thanks!  Linda

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


This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: RACF, external password management

[roscoe5]

We had our typical users (some exceptions for Security team, etc) change their 
password on AD (Ctrl-Alt-Del) with a 3rd party tool providing extra controls as 
desired. Then we scripted a send of the accepted pw/phrase up to RACF with the 
request to set the password/phrase there. The basic RACF rules had to be 
basically the same as the AD rules as far as complexity, history, etc. But all 
the expansive lists and restrictions were done once by the other product and 
RACF was happy with the complexity of the password supplied.
It worked for us. Just an idea.
R.
Sent from [Proton Mail](https://proton.me/mail/home) for iOS

On Wed, Feb 28, 2024 at 4:35 PM, Linda Hagedorn 
<[05cf4637de00-dmarc-requ...@listserv.ua.edu](mailto:On Wed, Feb 28, 2024 
at 4:35 PM, Linda Hagedorn < wrote:

> My company wants an external password manager to substitute for RACF.
> I need to know if anyone has experience with this, or common password 
> matching in RACF.
>
> Background
> Regulations NYDFS require preventing common passwords to be used.
> Vendor tools (Courion, CyberArk, etc.) have a corpus to match password 
> changes to prevent the use of common passwords.
> RACF passwords can be changed from TSO, the internal reader, JCL, Candle 
> Session manager, etc., so trying to block password changing through RACF and 
> forcing everyone through one of these 3rd party tools may be near impossible.
>
> Any input is appreciated. Thanks! Linda
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: RACF Automation (Cross Posted)

[Mike Cairns]

The last major RACF project I architected was for something I presume would 
probably fit your clients bill here.  Some of the necessary elements we 
incorporated were:

Delegated (though not via RACF means) Ownership of all RACF general resource 
and dataset profiles - thereby making sure that there were people distributed 
throughout the organisation who a) knew what their security requirements were, 
at least conceptually, and b) took responsibility for authorising requests for 
access to or changes made to the RACF definitions they 'owned'.

A naming convention that meant ownership of RACF definitions was able to be 
related to specific application systems (z/OS itself was considered just 
another application system running on the mainframe also - it's owner was of 
course the systems programming management).

A request workflow that walked ordinary users through the process of raising a 
change record for RACF definitions.  We used ServiceNow for this, with heavily 
customised workflows that linked into a Configuration Management Database that 
was a mirror, refreshed frequently, of the content of the RACF database.

The previously mentioned CMDB was an essential part of ensuring that we had 
auditable, documented, reliable oversight - governance they like to call it 
nowadays - of the process of RACF change management.  The CMDB relied heavily 
on the naming convention being used to identify which application (and 
therefore which responsible Owner) would be allowed to authorise requests.

An in house written started task that issued the necessary RACF commands based 
on authorised changes coming through the ServiceNow workflow.

Standardisation of the format for Installation Data - which we used to describe 
things such as a profiles security classification - i.e Public, Internal, 
Confidential, Secret - something like that, the labels are up to you.  This 
'data classification' was used to provide different versions of the ServiceNow 
workflow to suit the sensitivity of the resources being manipulated.  (I would 
have liked to use/abuse SECLABEL/SECLEVEL for this but that made some people 
nervous :-).

A lot of SMF based audit reports, especially with respect of the more highly 
classifiied resource profiles.

Two years work with a couple of sysprogs, a project manager and assistant plus 
a great deal of support from the organisations management to get this task 
done.  The alternative, was that we were going to need a team minimum 4 people 
with solid RACF knowledge to be available as mainframe security management - so 
the cost benefit analysis was quite crystal clear.

There were many other considerations that our RACF Automation project had to 
consider, and we solved a lot of other historical audit related issues during 
the process also and were very fortunate that we could implement some worlds 
best practice mainframe security constructs (i.e. separating all batch access 
on an application by application basis) as a part of the project.

Happy to discuss offline in case anyone is interested.

Cheers - Mike

PS:  the organisation already had a fully integrated IAM solution for 
provisioning mainframe access and an RBAC-like construct for this, that's the 
easy part - anyone without this nowadays is simply dragging the chain.

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

Re: RACF Automation (Cross Posted)

[Allan Staller]

Classification: Confidential

Try Vanguard software.  http://www.go2vanguard.com/

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Bob 
Bridges
Sent: Thursday, January 25, 2024 4:52 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF Automation (Cross Posted)

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don't click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Back when my client in Ohio installed it, we called it "Sam-Jupiter".  I don't 
know what the extra name implies.  The client seemed content with their choice, 
although it was really designed to work with RACF and this is an ACF2 client.

Also Sailpoint, but I think you mentioned that possibility already.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Getting an inch of snow is like winning 10 cents in the lottery.  -from 
_Calvin & Hobbes_ */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Thursday, January 25, 2024 14:08

See if SAM (Security Administration Manager) still exists (possibly rebranded). 
The company no longer exists but I found 
https://dl.acm.org/doi/pdf/10.1145/266741.266758 which described the product.

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

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


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

Re: RACF Automation (Cross Posted)

[Bob Bridges]

ACF2 has since added full support for RACF-style groups, and some ACF2 shops 
have made the change to using those instead of UID strings.  This was before 
that, though, and I'm pretty sure they handled it by storing, for each role, 
groups of UID strings.

I don't remember the details of how that worked, but I was their ETL guy and I 
remember creating lots of mass-import data for pouring into SAM-Jupiter.  The 
problem it is was more than twenty years ago, so it's all pretty fuzzy...

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* It's extremely difficult to distinguish a Canadian from an American.  In 
fact the most reliable way of doing so is to make that observation in the 
presence of a Canadian.  -attributed at the Gunroom to a "British man of 
letters" */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Thursday, January 25, 2024 18:53

It appears that Beta Systems acquired the product and call it Beta-Access. 
https://www.betasystems.com/en/products/beta-access/

It also appears they removed everything except for RACF support.

RACF had groups which made implementing role-based administration easier. ACF2 
and Top-Secret have a different architecture which some customer 
implementations were burdensome to implement within SAM. It also had 
performance implications. However, it had the benefit for customers acquiring 
other companies where they could use the same SAF logic regardless of the SAF 
products being used. It also allowed conversion between SAF products.

--- On Thu, 25 Jan 2024 17:51:46 -0500, Bob Bridges  
wrote:
>Back when my client in Ohio installed it, we called it "Sam-Jupiter". 

> The client seemed content with their choice, although it was really 
> designed to work with RACF and this is an ACF2 client.

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

Re: RACF Automation (Cross Posted)

[Jon Perryman]

On Thu, 25 Jan 2024 17:51:46 -0500, Bob Bridges  wrote:

>Back when my client in Ohio installed it, we called it "Sam-Jupiter". 

It appears that Beta Systems acquired the product and call it Beta-Access. 
https://www.betasystems.com/en/products/beta-access/

It also appears they removed everything except for RACF support.

> The client seemed content with their choice, although it was 
> really designed to work with RACF and this is an ACF2 client.

RACF had groups which made implementing role-based administration easier. ACF2 
and Top-Secret have a different architecture which some customer 
implementations were burdensome to implement within SAM. It also had 
performance implications. However, it had the benefit for customers acquiring 
other companies where they could use the same SAF logic regardless of the SAF 
products being used. It also allowed conversion between SAF products.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: RACF Automation (Cross Posted)

[Bob Bridges]

Back when my client in Ohio installed it, we called it "Sam-Jupiter".  I don't 
know what the extra name implies.  The client seemed content with their choice, 
although it was really designed to work with RACF and this is an ACF2 client.

Also Sailpoint, but I think you mentioned that possibility already.

---
Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313

/* Getting an inch of snow is like winning 10 cents in the lottery.  -from 
_Calvin & Hobbes_ */

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Jon 
Perryman
Sent: Thursday, January 25, 2024 14:08

See if SAM (Security Administration Manager) still exists (possibly rebranded). 
The company no longer exists but I found 
https://dl.acm.org/doi/pdf/10.1145/266741.266758 which described the product. 

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

Re: RACF Automation (Cross Posted)

[Jon Perryman]

On Thu, 25 Jan 2024 10:15:57 -0600, Steve Beaver  wrote:

>I don't even know if the product still exists. -- The closest IVP that I know 
>of is OKTA.

See if SAM (Security Administration Manager) still exists (possibly rebranded). 
The company no longer exists but I found 
https://dl.acm.org/doi/pdf/10.1145/266741.266758 which described the product. 

>The down side of ROLLING your own you have to administer and maintain it
>And no one wants to spend the couple hundred thousand to write and watch 
>people retire.

You haven't defined the customer's expectation of "Automate RACF". To say 
"couple hundred thousand $" is meaningless because at this point you don't know 
the customers problem.. Maybe the customer simply needs standards that simplify 
and consolidate the process. Products like AutoOperator may simplify 
distribution of security definitions to a few simple execs.

What is the problem that the customer trying to solve? Maybe the customer will 
find an 80% solution written in 2 weeks is acceptable. 

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

Re: RACF Automation (Cross Posted)

[Steve Beaver]

I don't even know if the product still exists. -- The closest IVP that I know 
of is OKTA.  OTKA 
Can administer lockouts and password.  However in our world there is nothing 
cheap
And easy.  The down side of ROLLING your own you have to administer and 
maintain it
And no one wants to spend the couple hundred thousand to write and watch people 
retire.


Steve 


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Jon Perryman
Sent: Thursday, January 25, 2024 10:07 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF Automation (Cross Posted)

On Tue, 23 Jan 2024 12:39:47 -0600, Steve Beaver  wrote:

>I have a customer that would like to AUTOMATE RACF. 

Did you solve your problem?

You need to clarify what AUTOMATE RACF means to the customer. What is the 
problem the customer is trying to solve because they can't mean automate. 
Security definitions requires someone to fill in the blanks. Are they looking 
to simplify the process and streamline it with a company's security strategy.

I worked on a product that centralized security thru a single interface (RACF, 
TopSecret, ACF2, Unix, Windows and others. It's been many years and I don't 
even know if the product still exists.

If you can describe the problem, then we might have some suggestions to solve 
your problem.

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

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

Re: RACF Automation (Cross Posted)

[Jon Perryman]

On Tue, 23 Jan 2024 12:39:47 -0600, Steve Beaver  wrote:

>I have a customer that would like to AUTOMATE RACF. 

Did you solve your problem?

You need to clarify what AUTOMATE RACF means to the customer. What is the 
problem the customer is trying to solve because they can't mean automate. 
Security definitions requires someone to fill in the blanks. Are they looking 
to simplify the process and streamline it with a company's security strategy.

I worked on a product that centralized security thru a single interface (RACF, 
TopSecret, ACF2, Unix, Windows and others. It's been many years and I don't 
even know if the product still exists.

If you can describe the problem, then we might have some suggestions to solve 
your problem.

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

Re: Racf Userid

[Radoslaw Skorupka]

To complement:
Last access is not last activity.
Depending on many factors user can be logged on for a long time, even 
months.
In the past I had found a TSO session still logged on, several weeks 
after the user left the company. Despite JWT/TWT settings (cancel 
session for inactivity).


--
Radoslaw Skorupka
Lodz, Poland




W dniu 11.01.2024 o 14:10, Chalk, Shelia pisze:

Thank you so much.  I pulled smf-type 80 records and found it.

Thanks again.

Shelia Chalk
Mainframe System Programmer
sch...@ssfcu.org

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Robert S. Hansel (RSH)
Sent: Thursday, January 11, 2024 7:02 AM
To:IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: Racf Userid

Please Note: This email is from an [EXTERNAL] sender. Do not click on links or 
attachments unless you expect them from the sender and know the content is 
safe. Please contact the Service Desk if you have any concerns regarding this 
message.



Hi Shelia,

First off, in output of the LISTUSER command, find the most recent LAST-CONNECT 
date/time in the group connect information for all ID's groups. Most likely it 
will be associated with the ID's default group. If it is the same as the 
LAST-ACCESS date/time, then the later was updated due to a logon. If the 
LAST-ACCESS date/time is later, then someone did an ALTUSER RESUME on the ID, 
in which case you'll want to examine SMF type 80 records for ALTUSER events.

If it appears to be a logon, you will want to examine SMF type 80 records for 
event JOBINIT (logon) and INITOEDP (Unix dub) as well as type 30 subtype 1 
records (TSO, Batch, and Started Task logons). Note that successful logons are 
often not logged. It all depends on how the resource manager processing the 
logon is designed and configured.

The SMF event names I'm referring to appear in the output of RACF's SMF unload 
utility. This utility converts raw SMF 80 and 30 records into text or XML 
output. If you have RACF administration add-on product such as zSecure, it will 
provide its own mechanisms for reporting from SMF data.

If the above doesn't yield any useful information, try adding the UAUDIT 
attribute to the ID to record all its access activity. This activity might 
provide some clues as to how and from where the ID is being used. If you have 
zSecure Access Monitor, it can also provide helpful access activity information.

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
http://www.linkedin.com/in/roberthansel
http://www.rshconsulting.com/

-Original Message-
Date:Wed, 10 Jan 2024 21:37:46 +
From:"Chalk, Shelia"
Subject: Racf Userid

Hello,

I have a userid abc that was last access in racf on 1/7/24 at 5:06 a.m.  Is 
there a report or something that will tell me who (batch job, script, etc..) is 
using this userid?

Thanks
Shelia Chalk
Mainframe System Programmer
sch...@ssfcu.org




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

Re: Racf Userid

[Chalk, Shelia]

Thank you so much.  I pulled smf-type 80 records and found it.

Thanks again.

Shelia Chalk
Mainframe System Programmer
sch...@ssfcu.org

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Robert S. Hansel (RSH)
Sent: Thursday, January 11, 2024 7:02 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: Racf Userid

Please Note: This email is from an [EXTERNAL] sender. Do not click on links or 
attachments unless you expect them from the sender and know the content is 
safe. Please contact the Service Desk if you have any concerns regarding this 
message.



Hi Shelia,

First off, in output of the LISTUSER command, find the most recent LAST-CONNECT 
date/time in the group connect information for all ID's groups. Most likely it 
will be associated with the ID's default group. If it is the same as the 
LAST-ACCESS date/time, then the later was updated due to a logon. If the 
LAST-ACCESS date/time is later, then someone did an ALTUSER RESUME on the ID, 
in which case you'll want to examine SMF type 80 records for ALTUSER events.

If it appears to be a logon, you will want to examine SMF type 80 records for 
event JOBINIT (logon) and INITOEDP (Unix dub) as well as type 30 subtype 1 
records (TSO, Batch, and Started Task logons). Note that successful logons are 
often not logged. It all depends on how the resource manager processing the 
logon is designed and configured.

The SMF event names I'm referring to appear in the output of RACF's SMF unload 
utility. This utility converts raw SMF 80 and 30 records into text or XML 
output. If you have RACF administration add-on product such as zSecure, it will 
provide its own mechanisms for reporting from SMF data.

If the above doesn't yield any useful information, try adding the UAUDIT 
attribute to the ID to record all its access activity. This activity might 
provide some clues as to how and from where the ID is being used. If you have 
zSecure Access Monitor, it can also provide helpful access activity information.

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
http://www.linkedin.com/in/roberthansel
http://www.rshconsulting.com/

-Original Message-
Date:Wed, 10 Jan 2024 21:37:46 +
From:"Chalk, Shelia" 
Subject: Racf Userid

Hello,

I have a userid abc that was last access in racf on 1/7/24 at 5:06 a.m.  Is 
there a report or something that will tell me who (batch job, script, etc..) is 
using this userid?

Thanks
Shelia Chalk
Mainframe System Programmer
sch...@ssfcu.org

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

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

Re: Racf Userid

[Robert S. Hansel (RSH)]

Hi Shelia,

First off, in output of the LISTUSER command, find the most recent LAST-CONNECT 
date/time in the group connect information for all ID's groups. Most likely it 
will be associated with the ID's default group. If it is the same as the 
LAST-ACCESS date/time, then the later was updated due to a logon. If the 
LAST-ACCESS date/time is later, then someone did an ALTUSER RESUME on the ID, 
in which case you'll want to examine SMF type 80 records for ALTUSER events.

If it appears to be a logon, you will want to examine SMF type 80 records for 
event JOBINIT (logon) and INITOEDP (Unix dub) as well as type 30 subtype 1 
records (TSO, Batch, and Started Task logons). Note that successful logons are 
often not logged. It all depends on how the resource manager processing the 
logon is designed and configured.

The SMF event names I'm referring to appear in the output of RACF's SMF unload 
utility. This utility converts raw SMF 80 and 30 records into text or XML 
output. If you have RACF administration add-on product such as zSecure, it will 
provide its own mechanisms for reporting from SMF data.

If the above doesn't yield any useful information, try adding the UAUDIT 
attribute to the ID to record all its access activity. This activity might 
provide some clues as to how and from where the ID is being used. If you have 
zSecure Access Monitor, it can also provide helpful access activity information.

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel 
www.rshconsulting.com 

-Original Message-
Date:Wed, 10 Jan 2024 21:37:46 +
From:"Chalk, Shelia" 
Subject: Racf Userid

Hello,

I have a userid abc that was last access in racf on 1/7/24 at 5:06 a.m.  Is 
there a report or something that will tell me who (batch job, script, etc..) is 
using this userid?

Thanks
Shelia Chalk
Mainframe System Programmer
sch...@ssfcu.org

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

Re: Racf Userid

[Allan Staller]

Classification: Confidential

Suspend it and see who complains. Alternatively, t he type 8x SMF records carry 
the RACF UID
(actually most of the job/dataset oriented records type 30, 14, 15), so you can 
check there as well.

Select by userid and filter out what you know. That which remains is the 
culprit.

MICS, MXG make this trivial.

HTH,

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Chalk, Shelia
Sent: Wednesday, January 10, 2024 3:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Racf Userid

[CAUTION: This Email is from outside the Organization. Unless you trust the 
sender, Don’t click links or open attachments as it may be a Phishing email, 
which can steal your Information and compromise your Computer.]

Hello,

I have a userid abc that was last access in racf on 1/7/24 at 5:06 a.m.  Is 
there a report or something that will tell me who (batch job, script, etc..) is 
using this userid?

Thanks
Shelia Chalk
Mainframe System Programmer
sch...@ssfcu.org


==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

The contents of this e-mail and any attachment(s) are confidential and intended 
for the named recipient(s) only. E-mail transmission is not guaranteed to be 
secure or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or may contain viruses in transmission. 
The e mail and its contents (with or without referred errors) shall therefore 
not attach any liability on the originator or HCL or its affiliates. Views or 
opinions, if any, presented in this email are solely those of the author and 
may not necessarily reflect the views or opinions of HCL or its affiliates. Any 
form of reproduction, dissemination, copying, disclosure, modification, 
distribution and / or publication of this message without the prior written 
consent of authorized representative of HCL is strictly prohibited. If you have 
received this email in error please delete it and notify the sender 
immediately. Before opening any email and/or attachments, please check them for 
viruses and other defects.


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

Re: Racf Userid

[Wayne Bickerdike]

documented here:

https://www.ibm.com/docs/en/zos/2.3.0?topic=records-record-type-80-racf-processing-record



On Thu, Jan 11, 2024 at 11:21 AM Wayne Bickerdike  wrote:

> SMF type 80 records.
>
> On Thu, Jan 11, 2024 at 8:38 AM Chalk, Shelia  wrote:
>
>> Hello,
>>
>> I have a userid abc that was last access in racf on 1/7/24 at 5:06 a.m.
>> Is there a report or something that will tell me who (batch job, script,
>> etc..) is using this userid?
>>
>> Thanks
>> Shelia Chalk
>> Mainframe System Programmer
>> sch...@ssfcu.org
>>
>>
>> ==
>> This email, and any files transmitted with it, is confidential and
>> intended solely for the use of the individual or entity to which it is
>> addressed. If you have received this email in error, please notify the
>> system manager. This message contains confidential information and is
>> intended only for the individual named. If you are not the named addressee,
>> you should not disseminate, distribute or copy this e-mail. Please notify
>> the sender immediately by e-mail if you have received this message by
>> mistake and delete this e-mail from your system. If you are not the
>> intended recipient, you are notified that disclosing, copying, distributing
>> or taking any action in reliance on the contents of this information is
>> strictly prohibited.
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>>
>
>
> --
> Wayne V. Bickerdike
>
>

-- 
Wayne V. Bickerdike

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

Re: Racf Userid

[Wayne Bickerdike]

SMF type 80 records.

On Thu, Jan 11, 2024 at 8:38 AM Chalk, Shelia  wrote:

> Hello,
>
> I have a userid abc that was last access in racf on 1/7/24 at 5:06 a.m.
> Is there a report or something that will tell me who (batch job, script,
> etc..) is using this userid?
>
> Thanks
> Shelia Chalk
> Mainframe System Programmer
> sch...@ssfcu.org
>
>
> ==
> This email, and any files transmitted with it, is confidential and
> intended solely for the use of the individual or entity to which it is
> addressed. If you have received this email in error, please notify the
> system manager. This message contains confidential information and is
> intended only for the individual named. If you are not the named addressee,
> you should not disseminate, distribute or copy this e-mail. Please notify
> the sender immediately by e-mail if you have received this message by
> mistake and delete this e-mail from your system. If you are not the
> intended recipient, you are notified that disclosing, copying, distributing
> or taking any action in reliance on the contents of this information is
> strictly prohibited.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>


-- 
Wayne V. Bickerdike

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

Re: RACF and Encryption (Cross Posted

[Colin Paice]

I wrote One minute MVS – Using individual data set encryption on z/OS

which may help you get started.  For example you'll need ICSF.

Colin

On Thu, 4 Jan 2024 at 20:36, Steve Beaver <
050e0c375a14-dmarc-requ...@listserv.ua.edu> wrote:

> Basically I have to set up data at rest (encrypted on DASD).
>
>
>
> In that I don't have my clearance yet, or a ID with SPECIAL my hands are
> kind of tied.
>
>
>
> I do know all the RACF work has to be done before anything else.
>
>
>
> Also as I understand it, we will have to unload a file, and reload the
>
> File to get the Data at Rest.
>
>
>
>
>
> Steve
>
>
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: RACF, the FACILITY class, and z/XDC

[Jack Zukt]

Hi,
Rver since IBM gave us CDT, user defined classes migration stopped being a
problem. You no longer need the assembler macros to define user classes.
Everything is in the RACF database.
Best wishes
Jack

On Mon, Nov 13, 2023, 08:42 Rob Scott  wrote:

> Although setting up your own SAF class is not difficult, it is another
> step in the installation/migration process and my instinct  (bearing in
> mind the squeeze on staffing resources) is always to tend to "zero-config"
> wherever possible.
>
> If you stay within your lanes as far as the profile namespace is concerned
> ,then XFACILIT makes sense in most cases.
>
> Rob Scott
> Rocket Software
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Phil Smith III
> Sent: Sunday, November 12, 2023 8:38 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: RACF, the FACILITY class, and z/XDC
>
> EXTERNAL EMAIL
>
>
>
>
>
> Ed Jaffe recommended against creating a SAF class. I'll respectfully
> suggest that it's not that hard.
>
> First, if you do, IBM told us, "Start the class name with a dollar
> sign-we'll never use those". Of course you could collide with another
> vendor, but that's unlikely.
>
> We've had customers doing so for 13 years or so. Besides some folks who
> didn't understand how to use their own ESM, we've had no problems. ACF2 and
> TSS were easy, too.
>
> Now, I admit that our usage is pretty simple: we have named data
> protection entities called Cryptids, and you can use them to protect
> (encrypt/tokenize/hash) or access (decrypt/detokenize) data. So if you have
> a Cryptid named BANANA, a user needs READ or greater authority to
> PROTECT.BANANA or ACCESS.BANANA, as appropriate to use BANANA to protect or
> access.
>
> For something like EJES, with possibly dozens of subtleties, it would
> surely be harder. The complexity of SAF related to certificates comes to
> mind, though I suspect some of that is due to some historical mistakes.
> Still, once you've defined a scheme, it's just PERMITs, right?
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> 
> Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA
> 02451 ■ Main Office Toll Free Number: +1 855.577.4323
> Contact Customer Support:
> https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
> Unsubscribe from Marketing Messages/Manage Your Subscription Preferences -
> http://www.rocketsoftware.com/manage-your-email-preferences
> Privacy Policy -
> http://www.rocketsoftware.com/company/legal/privacy-policy
> 
>
> This communication and any attachments may contain confidential
> information of Rocket Software, Inc. All unauthorized use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> notify Rocket Software immediately and destroy all copies of this
> communication. Thank you.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: RACF, the FACILITY class, and z/XDC

[Radoslaw Skorupka]

Since everyone already answered, here is my answer :-)
1. You can choose your own class.
Advantages:
You choose max. profile length, etc.
Naming conventions is completely up to you, that means no interference 
with other products/profiles, no reserved names/prefixes.

Disadvantage:
Some people are reluctant to create yet another RACF class. And sometime 
they make errors (sample definition should solve it).


2. XFACILIT
Advantages:
Length up to 246 chars
...and something nobody mentioned yet: GXFACILI grouping class. While 
long profiles allow wise naming convention, there is still way to group 
some unlikely named resource names into single profile.

(the same feature can be made in user-defined class as well)

HTH

--
Radoslaw Skorupka
Lodz, Poland





W dniu 12.11.2023 o 11:40, David Cole pisze:
I've got a problem. Decades ago, I made some assumptions about RACF's 
FACILITY class that have turned out to be wrong.


Currently, I'm working on implementing a new security rule for z/XDC, 
and the individual rules ("entities") can be up to 59 characters long.


Decades ago, when I was porting z/XDC's security rules from ACF2 to 
RACF, I made the decision to piggy-back my security rules into RACF's 
FACILITY class. I didn't know much about RACF then (and I still 
don't), and it did not occur to me that rule length would be an issue. 
I was wrong. It is an issue.


Yesterday, I was testing with an instance of the new rule that was 44 
characters long. Boom! My "RACROUTE REQUEST=AUTH" (racheck) call 
failed with "ICH409I 282-054 ABEND DURING RACHECK PROCESSING". This 
basically means that the entity I passed (my 44-character rule) was 
too long for its class (FACILITY).


Ouch!

So now I have several questions that I'm hoping someone here can 
provide answers to.

   * What is the longest entity the FACILITY class will accept?
   * Where do I find that specific fact doc'd?
   * Is there a command that will display that information?
   * Is there a catch-all class that z/XDC can use for its rules other 
than FACILITY?

   * Where do other vendors put their rules?

Asking for a friend [:-J]
Dave Cole



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

Re: RACF, the FACILITY class, and z/XDC

[Ituriel do Neto]

David,

Why don't you give the option to select the RACF class to the customer? You can 
give the instructions to create a new class in CDT or instruct them to use the 
XFACILIT class.


Best Regards

Ituriel do Nascimento Neto
z/OS System Programmer






Em segunda-feira, 13 de novembro de 2023 às 18:27:18 BRT, David Cole 
 escreveu: 





Hi Jon,

Thanks for your thoughts, but I'm not trying to 
decide if I should use FACILITY. I'm trying to 
decide how I should go about discontinuing using FACILITY.

Based on suggestions from others on this thread, 
I've made the decision to switch to using a class named XFACILIT.

[Switching will be tricky though. I don't want to 
leave existing customers high and dry, so I'll 
have to "dual path" (soft of). But I don't want 
to create security exposures by doing it wrong.]

Dave








At 11/13/2023 02:51 PM, Jon Perryman wrote:
>On Mon, 13 Nov 2023 13:30:56 -0500, David Cole  wrote:
>
> >so while creating a "$XDC" class perhaps might be "easy", to
> >paraphrase Peter, why would I make a customer 
> do that when I don't have to...
> >
> >So thank you to those who tipped me off about the XFACILIT. It sounds
> >perfect for my needs.
>
>Dave, as food for thought:
>
>RACF FACILITY is a special class which needs 
>special consideration in recommending it. For 
>instance, ask yourself why the resource name is restricted to 39 characters.
>
>If you choose to recommend FACILITY, you might 
>need to document special considerations and 
>include sections for each of the security 
>products (e.g. RACF, ACF2 and Top-secret).
>
>It's been a very long time for me, but I think 
>these are in storage rules. Probably not a big 
>deal if you only have a couple of rules but it's 
>something you should consider. Additionally, I 
>believe FACILITY requires a refresh in RACF. I 
>can't remember about ACF2 and Top-secret. These are customer considerations.
>
>If I remember correctly, RACF uses class numbers 
>which has a limit. classes are associated to a 
>number and mutliple classes can use the same 
>number. It's not unusual for customers to 
>combine classes into a single class but they 
>must avoid resource name collisions. It's a good 
>practice to uniquely identify your product in the resource name.
>
>Â I can't recall how ACF2 and Top-secret handle 
>these situations. Maybe they have a facility to equate multiple RACF classes.
>
>As an alternative to FACILITY, you might 
>consider a class that is not special but exists 
>at all. For example, I've had customers use the dataset class.
>
>You may want to continue with class $XDC as your 
>recommendation with alternatives. Equating 
>classes can be useful. For instance, companies 
>acquire other companies which means staff is 
>dealing with multiple unique environments. It 
>easier to manage XDC rules when class $XDC is 
>specified although it has a different meaning in each environment.
>
>I'm not suggesting you take this as advice but 
>simply to make you aware of these points.
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN


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

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

Re: RACF, the FACILITY class, and z/XDC

[David Cole]

Hi Jon,

Thanks for your thoughts, but I'm not trying to 
decide if I should use FACILITY. I'm trying to 
decide how I should go about discontinuing using FACILITY.


Based on suggestions from others on this thread, 
I've made the decision to switch to using a class named XFACILIT.


[Switching will be tricky though. I don't want to 
leave existing customers high and dry, so I'll 
have to "dual path" (soft of). But I don't want 
to create security exposures by doing it wrong.]


Dave








At 11/13/2023 02:51 PM, Jon Perryman wrote:

On Mon, 13 Nov 2023 13:30:56 -0500, David Cole  wrote:

>so while creating a "$XDC" class perhaps might be "easy", to
>paraphrase Peter, why would I make a customer 
do that when I don't have to...

>
>So thank you to those who tipped me off about the XFACILIT. It sounds
>perfect for my needs.

Dave, as food for thought:

RACF FACILITY is a special class which needs 
special consideration in recommending it. For 
instance, ask yourself why the resource name is restricted to 39 characters.


If you choose to recommend FACILITY, you might 
need to document special considerations and 
include sections for each of the security 
products (e.g. RACF, ACF2 and Top-secret).


It's been a very long time for me, but I think 
these are in storage rules. Probably not a big 
deal if you only have a couple of rules but it's 
something you should consider. Additionally, I 
believe FACILITY requires a refresh in RACF. I 
can't remember about ACF2 and Top-secret. These are customer considerations.


If I remember correctly, RACF uses class numbers 
which has a limit. classes are associated to a 
number and mutliple classes can use the same 
number. It's not unusual for customers to 
combine classes into a single class but they 
must avoid resource name collisions. It's a good 
practice to uniquely identify your product in the resource name.


 I can't recall how ACF2 and Top-secret handle 
these situations. Maybe they have a facility to equate multiple RACF classes.


As an alternative to FACILITY, you might 
consider a class that is not special but exists 
at all. For example, I've had customers use the dataset class.


You may want to continue with class $XDC as your 
recommendation with alternatives. Equating 
classes can be useful. For instance, companies 
acquire other companies which means staff is 
dealing with multiple unique environments. It 
easier to manage XDC rules when class $XDC is 
specified although it has a different meaning in each environment.


I'm not suggesting you take this as advice but 
simply to make you aware of these points.


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


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

Re: RACF, the FACILITY class, and z/XDC

[Jon Perryman]

On Mon, 13 Nov 2023 13:30:56 -0500, David Cole  wrote:

>so while creating a "$XDC" class perhaps might be "easy", to
>paraphrase Peter, why would I make a customer do that when I don't have to...
>
>So thank you to those who tipped me off about the XFACILIT. It sounds
>perfect for my needs.

Dave, as food for thought:

RACF FACILITY is a special class which needs special consideration in 
recommending it. For instance, ask yourself why the resource name is restricted 
to 39 characters.

If you choose to recommend FACILITY, you might need to document special 
considerations and include sections for each of the security products (e.g. 
RACF, ACF2 and Top-secret).

It's been a very long time for me, but I think these are in storage rules. 
Probably not a big deal if you only have a couple of rules but it's something 
you should consider. Additionally, I believe FACILITY requires a refresh in 
RACF. I can't remember about ACF2 and Top-secret. These are customer 
considerations.

If I remember correctly, RACF uses class numbers which has a limit. classes are 
associated to a number and mutliple classes can use the same number. It's not 
unusual for customers to combine classes into a single class but they must 
avoid resource name collisions. It's a good practice to uniquely identify your 
product in the resource name.

 I can't recall how ACF2 and Top-secret handle these situations. Maybe they 
have a facility to equate multiple RACF classes.

As an alternative to FACILITY, you might consider a class that is not special 
but exists at all. For example, I've had customers use the dataset class. 

You may want to continue with class $XDC as your recommendation with 
alternatives. Equating classes can be useful. For instance, companies acquire 
other companies which means staff is dealing with multiple unique environments. 
It easier to manage XDC rules when class $XDC is specified although it has a 
different meaning in each environment.

I'm not suggesting you take this as advice but simply to make you aware of 
these points.

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

Re: RACF, the FACILITY class, and z/XDC

[Binyamin Dissen]

On Mon, 13 Nov 2023 12:58:16 + Peter Relson  wrote:

:>Regardless of whether it is hard or easy, why would you
:>want to bother creating a new class when there is an
:>existing class (XFACILIT) that completely addresses the problem
:>(and thus would be easier for a customer)?

DEFAULTRC
OPERATIONS
Unexpected masked rules
More hands in the pot

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

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

Re: RACF, the FACILITY class, and z/XDC

[Hayim Sokolsky]

While some have suggested creating your own class, there is an off-the-shelf 
class suitable for XDC's use: XFACILIT.

- Maximum resource length is 246
- Default return code is 8 (everything is denied if the resource is not defined)

This is just as suitable as creating your own class name, and possible 
preferable if there are going to be a small number of resources.


Just my 2¢..


Hayim

Hayim Sokolsky (he/him/his)
Director, Software Engineering
Rocket Software, USA
E: hsokol...@rocketsoftware.com
W:RocketSoftware.com




-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Cole
Sent: Sunday, November 12, 2023 05:40
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RACF, the FACILITY class, and z/XDC

EXTERNAL EMAIL





I've got a problem. Decades ago, I made some assumptions about RACF's FACILITY 
class that have turned out to be wrong.

Currently, I'm working on implementing a new security rule for z/XDC, and the 
individual rules ("entities") can be up to 59 characters long.

Decades ago, when I was porting z/XDC's security rules from ACF2 to RACF, I 
made the decision to piggy-back my security rules into RACF's FACILITY class. I 
didn't know much about RACF then (and I still don't), and it did not occur to 
me that rule length would be an issue. I was wrong. It is an issue.

Yesterday, I was testing with an instance of the new rule that was 44 
characters long. Boom! My "RACROUTE REQUEST=AUTH" (racheck) call failed with 
"ICH409I 282-054 ABEND DURING RACHECK PROCESSING". This basically means that 
the entity I passed (my 44-character rule) was too long for its class 
(FACILITY).

Ouch!

So now I have several questions that I'm hoping someone here can provide 
answers to.
* What is the longest entity the FACILITY class will accept?
* Where do I find that specific fact doc'd?
* Is there a command that will display that information?
* Is there a catch-all class that z/XDC can use for its rules other than 
FACILITY?
* Where do other vendors put their rules?

Asking for a friend [:-J]
Dave Cole

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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: RACF, the FACILITY class, and z/XDC

[Peter Relson]

Regardless of whether it is hard or easy, why would you
want to bother creating a new class when there is an
existing class (XFACILIT) that completely addresses the problem
(and thus would be easier for a customer)?

Peter Relson
z/OS Core Technology Design


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

Re: RACF, the FACILITY class, and z/XDC

[Rob Scott]

Although setting up your own SAF class is not difficult, it is another step in 
the installation/migration process and my instinct  (bearing in mind the 
squeeze on staffing resources) is always to tend to "zero-config" wherever 
possible.

If you stay within your lanes as far as the profile namespace is concerned 
,then XFACILIT makes sense in most cases.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Phil Smith III
Sent: Sunday, November 12, 2023 8:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF, the FACILITY class, and z/XDC

EXTERNAL EMAIL





Ed Jaffe recommended against creating a SAF class. I'll respectfully suggest 
that it's not that hard.

First, if you do, IBM told us, "Start the class name with a dollar sign-we'll 
never use those". Of course you could collide with another vendor, but that's 
unlikely.

We've had customers doing so for 13 years or so. Besides some folks who didn't 
understand how to use their own ESM, we've had no problems. ACF2 and TSS were 
easy, too.

Now, I admit that our usage is pretty simple: we have named data protection 
entities called Cryptids, and you can use them to protect 
(encrypt/tokenize/hash) or access (decrypt/detokenize) data. So if you have a 
Cryptid named BANANA, a user needs READ or greater authority to PROTECT.BANANA 
or ACCESS.BANANA, as appropriate to use BANANA to protect or access.

For something like EJES, with possibly dozens of subtleties, it would surely be 
harder. The complexity of SAF related to certificates comes to mind, though I 
suspect some of that is due to some historical mistakes. Still, once you've 
defined a scheme, it's just PERMITs, right?


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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: RACF, the FACILITY class, and z/XDC

[Phil Smith III]

Ed Jaffe recommended against creating a SAF class. I'll respectfully suggest 
that it's not that hard.

First, if you do, IBM told us, "Start the class name with a dollar sign-we'll 
never use those". Of course you could collide with
another vendor, but that's unlikely.

We've had customers doing so for 13 years or so. Besides some folks who didn't 
understand how to use their own ESM, we've had no
problems. ACF2 and TSS were easy, too.

Now, I admit that our usage is pretty simple: we have named data protection 
entities called Cryptids, and you can use them to
protect (encrypt/tokenize/hash) or access (decrypt/detokenize) data. So if you 
have a Cryptid named BANANA, a user needs READ or
greater authority to PROTECT.BANANA or ACCESS.BANANA, as appropriate to use 
BANANA to protect or access. 

For something like EJES, with possibly dozens of subtleties, it would surely be 
harder. The complexity of SAF related to
certificates comes to mind, though I suspect some of that is due to some 
historical mistakes. Still, once you've defined a scheme,
it's just PERMITs, right?


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

Re: RACF, the FACILITY class, and z/XDC

[Binyamin Dissen]

On Sun, 12 Nov 2023 10:46:36 -0800 Ed Jaffe 
wrote:

:>On 11/12/2023 10:30 AM, Binyamin Dissen wrote:
:>> With the CDT class, it is just a few RACF commands.

:>> RDEFINE CDT class  +
:>>   CDTINFO(+
:>>  MAXLENGTH(100) +
:>>  RACLIST(ALLOWED) +
:>>  GENLIST(ALLOWED)+
:>>  FIRST(ALPHA,NATIONAL,NUMERIC) +
:>>  OTHER(ALPHA,NUMERIC,NATIONAL,SPECIAL) +
:>>  POSIT(posit) +
:>>  DEFAULTRC(rc) /* 8=fail w/o profile, 4=use OPER */ +
:>>  OPERATIONS(oper) /* YES=Operations always allowed */ +
:>>)
 
:>> SETROPTS RACLIST(CDT) REFRESH

:>> No need for assemblies or anything. If they are going to write rules, they
:>> need the RACF knowledge anyway.

:>Can you provide the same procedure for the other two popular ESMs: ACF2 
:>and TSS?

I would have to look it up. But I would bet in their manuals they explain
exactly how to map it.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

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

Re: RACF, the FACILITY class, and z/XDC

[Ed Jaffe]

On 11/12/2023 10:30 AM, Binyamin Dissen wrote:

With the CDT class, it is just a few RACF commands.

RDEFINE CDT class  +
  CDTINFO(+
 MAXLENGTH(100) +
 RACLIST(ALLOWED) +
 GENLIST(ALLOWED)+
 FIRST(ALPHA,NATIONAL,NUMERIC) +
 OTHER(ALPHA,NUMERIC,NATIONAL,SPECIAL) +
 POSIT(posit) +
 DEFAULTRC(rc) /* 8=fail w/o profile, 4=use OPER */ +
 OPERATIONS(oper) /* YES=Operations always allowed */ +
   )

SETROPTS RACLIST(CDT) REFRESH


No need for assemblies or anything. If they are going to write rules, they
need the RACF knowledge anyway.


Can you provide the same procedure for the other two popular ESMs: ACF2 
and TSS?


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: RACF, the FACILITY class, and z/XDC

[Binyamin Dissen]

On Sun, 12 Nov 2023 07:13:03 -0800 Ed Jaffe 
wrote:

:>On 11/12/2023 3:02 AM, Binyamin Dissen wrote:
:>> You should make your own class.
:>>
:>> Classes can be dynamically added by adding to the CDT class.
:>
:>This is extra hassle at client sites and IMHO should be avoided.

With the CDT class, it is just a few RACF commands.

RDEFINE CDT class  +  
 CDTINFO(+ 
MAXLENGTH(100) +   
RACLIST(ALLOWED) + 
GENLIST(ALLOWED)+  
FIRST(ALPHA,NATIONAL,NUMERIC) +
OTHER(ALPHA,NUMERIC,NATIONAL,SPECIAL) +
POSIT(posit) + 
DEFAULTRC(rc) /* 8=fail w/o profile, 4=use OPER */ +   
OPERATIONS(oper) /* YES=Operations always allowed */ + 
  )
   
SETROPTS RACLIST(CDT) REFRESH  

No need for assemblies or anything. If they are going to write rules, they
need the RACF knowledge anyway.


:>Long ago, we suggested clients create an "EJES" class for our (E)JES 
:>product. There are three popular security products: RACF, ACF2, and TSS. 
:>Unless you are well-versed in all three of them, I recommend you steer 
:>clear of recommending new classes be created. (These days we recommend 
:>clients use the existing "SDSF" class for (E)JES resources.)

Yeah, if you have a mirror class, great.

:>I recommend you use the XFACILIT class instead of FACILITY. Its raison 
:>d'être addresses exactly your issue: resources in FACILITY are too short.

To each their own. For a distributed product I would recommend defining your
own class. Much more flexibility and you don't have to worry about something
else screwing with you.

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

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

Re: RACF, the FACILITY class, and z/XDC

[Ed Jaffe]

On 11/12/2023 3:02 AM, Binyamin Dissen wrote:

You should make your own class.

Classes can be dynamically added by adding to the CDT class.


This is extra hassle at client sites and IMHO should be avoided.

Long ago, we suggested clients create an "EJES" class for our (E)JES 
product. There are three popular security products: RACF, ACF2, and TSS. 
Unless you are well-versed in all three of them, I recommend you steer 
clear of recommending new classes be created. (These days we recommend 
clients use the existing "SDSF" class for (E)JES resources.)


I recommend you use the XFACILIT class instead of FACILITY. Its raison 
d'être addresses exactly your issue: resources in FACILITY are too short.


--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: RACF, the FACILITY class, and z/XDC

[Rob Scott]

Another option is the XFACILIT class which supports much longer profile names ( 
up to 246 characters).

Rob Scott
Rocket Software

Sent from Samsung Mobile on O2
Sent from Outlook for Android<https://aka.ms/AAb9ysg>

From: IBM Mainframe Discussion List  on behalf of 
Binyamin Dissen 
Sent: Sunday, November 12, 2023 11:02:01 AM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: RACF, the FACILITY class, and z/XDC

EXTERNAL EMAIL




You should make your own class.

Classes can be dynamically added by adding to the CDT class.

On Sun, 12 Nov 2023 05:40:03 -0500 David Cole  wrote:

:>I've got a problem. Decades ago, I made some assumptions about RACF's
:>FACILITY class that have turned out to be wrong.

:>Currently, I'm working on implementing a new security rule for z/XDC,
:>and the individual rules ("entities") can be up to 59 characters long.

:>Decades ago, when I was porting z/XDC's security rules from ACF2 to
:>RACF, I made the decision to piggy-back my security rules into RACF's
:>FACILITY class. I didn't know much about RACF then (and I still
:>don't), and it did not occur to me that rule length would be an
:>issue. I was wrong. It is an issue.

:>Yesterday, I was testing with an instance of the new rule that was 44
:>characters long. Boom! My "RACROUTE REQUEST=AUTH" (racheck) call
:>failed with "ICH409I 282-054 ABEND DURING RACHECK PROCESSING". This
:>basically means that the entity I passed (my 44-character rule) was
:>too long for its class (FACILITY).

:>Ouch!

:>So now I have several questions that I'm hoping someone here can
:>provide answers to.
:> * What is the longest entity the FACILITY class will accept?
:> * Where do I find that specific fact doc'd?
:> * Is there a command that will display that information?
:> * Is there a catch-all class that z/XDC can use for its rules
:>other than FACILITY?
:> * Where do other vendors put their rules?

--
Binyamin Dissen 
http://www.dissensoftware.com<http://www.dissensoftware.com>

Director, Dissen Software, Bar & Grill - Israel

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


Rocket Software, Inc. and subsidiaries ? 77 Fourth Avenue, Waltham MA 02451 ? 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: RACF, the FACILITY class, and z/XDC

[Binyamin Dissen]

You should make your own class.

Classes can be dynamically added by adding to the CDT class.

On Sun, 12 Nov 2023 05:40:03 -0500 David Cole  wrote:

:>I've got a problem. Decades ago, I made some assumptions about RACF's 
:>FACILITY class that have turned out to be wrong.

:>Currently, I'm working on implementing a new security rule for z/XDC, 
:>and the individual rules ("entities") can be up to 59 characters long.

:>Decades ago, when I was porting z/XDC's security rules from ACF2 to 
:>RACF, I made the decision to piggy-back my security rules into RACF's 
:>FACILITY class. I didn't know much about RACF then (and I still 
:>don't), and it did not occur to me that rule length would be an 
:>issue. I was wrong. It is an issue.

:>Yesterday, I was testing with an instance of the new rule that was 44 
:>characters long. Boom! My "RACROUTE REQUEST=AUTH" (racheck) call 
:>failed with "ICH409I 282-054 ABEND DURING RACHECK PROCESSING". This 
:>basically means that the entity I passed (my 44-character rule) was 
:>too long for its class (FACILITY).

:>Ouch!

:>So now I have several questions that I'm hoping someone here can 
:>provide answers to.
:>* What is the longest entity the FACILITY class will accept?
:>* Where do I find that specific fact doc'd?
:>* Is there a command that will display that information?
:>* Is there a catch-all class that z/XDC can use for its rules 
:>other than FACILITY?
:>* Where do other vendors put their rules?

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

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

Re: RACF, the FACILITY class, and z/XDC

[Gadi Ben-Avi]

The properties for the supplied classes in RACF can be found here 
https://www.ibm.com/docs/en/zos/2.3.0?topic=reference-supplied-class-descriptor-table-entries
You can easily add new classes by adding a profile in the CDT class.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Cole
Sent: יום א 12 נובמבר 2023 12:40
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RACF, the FACILITY class, and z/XDC

[You don't often get email from dbc...@colesoft.com. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

I've got a problem. Decades ago, I made some assumptions about RACF's FACILITY 
class that have turned out to be wrong.

Currently, I'm working on implementing a new security rule for z/XDC, and the 
individual rules ("entities") can be up to 59 characters long.

Decades ago, when I was porting z/XDC's security rules from ACF2 to RACF, I 
made the decision to piggy-back my security rules into RACF's FACILITY class. I 
didn't know much about RACF then (and I still don't), and it did not occur to 
me that rule length would be an issue. I was wrong. It is an issue.

Yesterday, I was testing with an instance of the new rule that was 44 
characters long. Boom! My "RACROUTE REQUEST=AUTH" (racheck) call failed with 
"ICH409I 282-054 ABEND DURING RACHECK PROCESSING". This basically means that 
the entity I passed (my 44-character rule) was too long for its class 
(FACILITY).

Ouch!

So now I have several questions that I'm hoping someone here can provide 
answers to.
* What is the longest entity the FACILITY class will accept?
* Where do I find that specific fact doc'd?
* Is there a command that will display that information?
* Is there a catch-all class that z/XDC can use for its rules other than 
FACILITY?
* Where do other vendors put their rules?

Asking for a friend [:-J]
Dave Cole

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

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

Re: RACF, the FACILITY class, and z/XDC

[Gadi Ben-Avi]

The longest profile name in FACILITY is 39 characters (At least in z/OS v2.3)
I would say that if you need something longer, you should create a dedicated 
class with the properties you want. 

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
David Cole
Sent: יום א 12 נובמבר 2023 12:40
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RACF, the FACILITY class, and z/XDC

[You don't often get email from dbc...@colesoft.com. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

I've got a problem. Decades ago, I made some assumptions about RACF's FACILITY 
class that have turned out to be wrong.

Currently, I'm working on implementing a new security rule for z/XDC, and the 
individual rules ("entities") can be up to 59 characters long.

Decades ago, when I was porting z/XDC's security rules from ACF2 to RACF, I 
made the decision to piggy-back my security rules into RACF's FACILITY class. I 
didn't know much about RACF then (and I still don't), and it did not occur to 
me that rule length would be an issue. I was wrong. It is an issue.

Yesterday, I was testing with an instance of the new rule that was 44 
characters long. Boom! My "RACROUTE REQUEST=AUTH" (racheck) call failed with 
"ICH409I 282-054 ABEND DURING RACHECK PROCESSING". This basically means that 
the entity I passed (my 44-character rule) was too long for its class 
(FACILITY).

Ouch!

So now I have several questions that I'm hoping someone here can provide 
answers to.
* What is the longest entity the FACILITY class will accept?
* Where do I find that specific fact doc'd?
* Is there a command that will display that information?
* Is there a catch-all class that z/XDC can use for its rules other than 
FACILITY?
* Where do other vendors put their rules?

Asking for a friend [:-J]
Dave Cole

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

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

Re: RACF ICH408I messages

[Chalk, Shelia]

I will look at vanguard.

Thanks
Shelia Chalk

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Robert S. Hansel (RSH)
Sent: Thursday, October 5, 2023 4:38 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: [EXT] Re: RACF ICH408I messages

Please Note: This email is from an [EXTERNAL] sender. Do not click on links or 
attachments unless you expect them from the sender and know the content is 
safe. Please contact the Service Desk if you have any concerns regarding this 
message.



Hi Shelia,

Assuming your RACF monitoring options have been set correctly, the ICH408I 
messages will likely have corresponding SMF records. You can use RACF's SMF 
Unload utility to generate text or XML output from these records for research 
and reporting. If you have an adjunct RACF SMF reporting product (e.g., zSecure 
Audit or Vanguard Advisor), it will provide ISPF menus for generating reports.

For more on setting up RACF monitoring options and using the SMF Unload, see 
our presentation on this topic.

https://www.rshconsulting.com/RSHpres/RSH_Consulting__RACF_Monitoring_&_Reporting__May_2019.pdf

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
http://www.linkedin.com/in/roberthansel
http://www.rshconsulting.com/

Upcoming RSH RACF Training - WebEx
- RACF Level I Administration - DEC 4-8, 2023
- RACF Level II Administration - NOV 13-17, 2023
- RACF Level III Admin, Audit, & Compliance - OCT 30 - NOV 3, 2023***Date 
Change***
- RACF - Securing z/OS UNIX  - FEB 26 - MAR 1, 2024
-

-Original Message-
Date:Wed, 4 Oct 2023 17:38:18 +
From:"Chalk, Shelia" 
Subject: RACF ICH408I messages

Hello,

Is there a report that I can run to list all the ICH408i messages within a time 
period?

Thanks
Shelia Chalk

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

==
This email, and any files transmitted with it, is confidential and intended 
solely for the use of the individual or entity to which it is addressed. If you 
have received this email in error, please notify the system manager. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee, you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this message by mistake and delete 
this e-mail from your system. If you are not the intended recipient, you are 
notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

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

Re: RACF ICH408I messages

[Robert S. Hansel (RSH)]

Hi Shelia,

Assuming your RACF monitoring options have been set correctly, the ICH408I 
messages will likely have corresponding SMF records. You can use RACF's SMF 
Unload utility to generate text or XML output from these records for research 
and reporting. If you have an adjunct RACF SMF reporting product (e.g., zSecure 
Audit or Vanguard Advisor), it will provide ISPF menus for generating reports.

For more on setting up RACF monitoring options and using the SMF Unload, see 
our presentation on this topic.

https://www.rshconsulting.com/RSHpres/RSH_Consulting__RACF_Monitoring_&_Reporting__May_2019.pdf

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
www.rshconsulting.com

Upcoming RSH RACF Training - WebEx
- RACF Level I Administration - DEC 4-8, 2023
- RACF Level II Administration - NOV 13-17, 2023
- RACF Level III Admin, Audit, & Compliance - OCT 30 - NOV 3, 2023***Date 
Change***
- RACF - Securing z/OS UNIX  - FEB 26 - MAR 1, 2024
-

-Original Message-
Date:Wed, 4 Oct 2023 17:38:18 +
From:"Chalk, Shelia" 
Subject: RACF ICH408I messages

Hello,

Is there a report that I can run to list all the ICH408i messages within a time 
period?

Thanks
Shelia Chalk

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

Re: RACF ICH408I messages

[Lionel B. Dyck]

See File 417 on the www.cbttape.org site (check the
https://cbttape.org/updates.htm for updates to the file) which contains the
RACFADM ISPF dialog.  The M option will do exactly what you are asking for.

Hope this helps.


Lionel B. Dyck <><
Website: https://www.lbdsoftware.com
Github: https://github.com/lbdyck

“Worry more about your character than your reputation. Character is what you
are, reputation merely what others think you are.”   - - - John Wooden

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of
Chalk, Shelia
Sent: Wednesday, October 4, 2023 12:38 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RACF ICH408I messages

Hello,

Is there a report that I can run to list all the ICH408i messages within a
time period?

Thanks
Shelia Chalk

==
This email, and any files transmitted with it, is confidential and intended
solely for the use of the individual or entity to which it is addressed. If
you have received this email in error, please notify the system manager.
This message contains confidential information and is intended only for the
individual named. If you are not the named addressee, you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this message by mistake and
delete this e-mail from your system. If you are not the intended recipient,
you are notified that disclosing, copying, distributing or taking any action
in reliance on the contents of this information is strictly prohibited.

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

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

Re: RACF for using SDSF

[Rahim Azizarab]

Did you do SETROPTS RACLIST(ADCDA) REFRESH

without the REFRESH your changes will not take effect.


regards;

Rahim 



   

 

On Monday, September 4, 2023 at 09:57:20 AM CDT, Joseph Reichman 
 wrote:  
 
 You got it did the connect and I am good 

thanks

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Itschak Mugzach
Sent: Monday, September 4, 2023 10:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF for using SDSF

You do not need to have sys1 as a default group. Che k if you are authorised to 
sdsf isf.connect profile

ITschak

בתאריך יום ב׳, 4 בספט׳ 2023 ב-17:34 מאת Rob Scott :

> Joseph,
>
> I think you need to use the "CONNECT" command instead of ALTUSER :
>
> CONNECT userid GROUP(group_name)
>
> Afterwards a "LISTUSER userid" command should list all groups that the 
> user is connected to.
>
> As most sites run with "list of groups checking", there is normally no 
> need to change the default group after a CONNECT.
>
> Rob Scott
> Rocket Software
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Joseph Reichman
> Sent: Monday, September 4, 2023 3:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: RACF for using SDSF
>
> EXTERNAL EMAIL
>
>
>
>
>
> Hi
>
>
>
> I am getting the following message on my ADCD system
>
>
>
> ISF024I USER ADCDA    NOT AUTHORIZED TO SDSF, NO GROUP ASSIGNMENT
>
>
>
> I tried  ALU ADCDA GROUP(SYS1) this is the group that my other tso Is 
> which has access to SDSF
>
>
>
> Regardless after I do the command and do a LU ADCDA the group still 
> shows up as TEST
>
>
>
> When doing ALU ADCDA DFLTGRP(SYS1) racf says its not connected
>
>
>
> thanks
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> 
> Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA
> 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer 
> Support:
> https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
> Unsubscribe from Marketing Messages/Manage Your Subscription 
> Preferences - 
> http://www.rocketsoftware.com/manage-your-email-preferences
> Privacy Policy -
> http://www.rocketsoftware.com/company/legal/privacy-policy
> 
>
> This communication and any attachments may contain confidential 
> information of Rocket Software, Inc. All unauthorized use, disclosure 
> or distribution is prohibited. If you are not the intended recipient, 
> please notify Rocket Software immediately and destroy all copies of 
> this communication. Thank you.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

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

Re: RACF for using SDSF

[Radoslaw Skorupka]

Joseph,

All you need is READ access to one of the following profiles:
GROUP.ISFOPER.*
GROUP.ISFSPROG.*
GROUP.ISFUSER.*

All profiles in CLASS(SDSF).

Which one to use? ISFSPROG is the best, ISFUSER is the worst.
Just try one after another and you will see the differences.

Note: in the old days before z/OS 2.5 it was possible to use ISFPRMxx 
customization *and* some TSOAUTH profiles (I can't remember which ones). 
Same effect.


HTH

--
Radoslaw Skorupka
Lodz, Poland




W dniu 04.09.2023 o 16:18, Joseph Reichman pisze:

Hi

  


I am getting the following message on my ADCD system

  


ISF024I USER ADCDANOT AUTHORIZED TO SDSF, NO GROUP ASSIGNMENT

  


I tried  ALU ADCDA GROUP(SYS1) this is the group that my other tso Is which
has access to SDSF

  


Regardless after I do the command and do a LU ADCDA the group still shows up
as TEST

  


When doing ALU ADCDA DFLTGRP(SYS1) racf says its not connected


thanks



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

Re: RACF for using SDSF

[Joseph Reichman]

You got it did the connect and I am good 

thanks

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Itschak Mugzach
Sent: Monday, September 4, 2023 10:37 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF for using SDSF

You do not need to have sys1 as a default group. Che k if you are authorised to 
sdsf isf.connect profile

ITschak

בתאריך יום ב׳, 4 בספט׳ 2023 ב-17:34 מאת Rob Scott :

> Joseph,
>
> I think you need to use the "CONNECT" command instead of ALTUSER :
>
> CONNECT userid GROUP(group_name)
>
> Afterwards a "LISTUSER userid" command should list all groups that the 
> user is connected to.
>
> As most sites run with "list of groups checking", there is normally no 
> need to change the default group after a CONNECT.
>
> Rob Scott
> Rocket Software
>
> -Original Message-
> From: IBM Mainframe Discussion List  On 
> Behalf Of Joseph Reichman
> Sent: Monday, September 4, 2023 3:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: RACF for using SDSF
>
> EXTERNAL EMAIL
>
>
>
>
>
> Hi
>
>
>
> I am getting the following message on my ADCD system
>
>
>
> ISF024I USER ADCDANOT AUTHORIZED TO SDSF, NO GROUP ASSIGNMENT
>
>
>
> I tried  ALU ADCDA GROUP(SYS1) this is the group that my other tso Is 
> which has access to SDSF
>
>
>
> Regardless after I do the command and do a LU ADCDA the group still 
> shows up as TEST
>
>
>
> When doing ALU ADCDA DFLTGRP(SYS1) racf says its not connected
>
>
>
> thanks
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> 
> Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA
> 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer 
> Support:
> https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
> Unsubscribe from Marketing Messages/Manage Your Subscription 
> Preferences - 
> http://www.rocketsoftware.com/manage-your-email-preferences
> Privacy Policy -
> http://www.rocketsoftware.com/company/legal/privacy-policy
> 
>
> This communication and any attachments may contain confidential 
> information of Rocket Software, Inc. All unauthorized use, disclosure 
> or distribution is prohibited. If you are not the intended recipient, 
> please notify Rocket Software immediately and destroy all copies of 
> this communication. Thank you.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send 
> email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

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

Re: RACF for using SDSF

[Itschak Mugzach]

You do not need to have sys1 as a default group. Che k if you are
authorised to sdsf isf.connect profile

ITschak

בתאריך יום ב׳, 4 בספט׳ 2023 ב-17:34 מאת Rob Scott :

> Joseph,
>
> I think you need to use the "CONNECT" command instead of ALTUSER :
>
> CONNECT userid GROUP(group_name)
>
> Afterwards a "LISTUSER userid" command should list all groups that the
> user is connected to.
>
> As most sites run with "list of groups checking", there is normally no
> need to change the default group after a CONNECT.
>
> Rob Scott
> Rocket Software
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf
> Of Joseph Reichman
> Sent: Monday, September 4, 2023 3:19 PM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: RACF for using SDSF
>
> EXTERNAL EMAIL
>
>
>
>
>
> Hi
>
>
>
> I am getting the following message on my ADCD system
>
>
>
> ISF024I USER ADCDANOT AUTHORIZED TO SDSF, NO GROUP ASSIGNMENT
>
>
>
> I tried  ALU ADCDA GROUP(SYS1) this is the group that my other tso Is
> which has access to SDSF
>
>
>
> Regardless after I do the command and do a LU ADCDA the group still shows
> up as TEST
>
>
>
> When doing ALU ADCDA DFLTGRP(SYS1) racf says its not connected
>
>
>
> thanks
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions, send email
> to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> 
> Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA
> 02451 ■ Main Office Toll Free Number: +1 855.577.4323
> Contact Customer Support:
> https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
> Unsubscribe from Marketing Messages/Manage Your Subscription Preferences -
> http://www.rocketsoftware.com/manage-your-email-preferences
> Privacy Policy -
> http://www.rocketsoftware.com/company/legal/privacy-policy
> 
>
> This communication and any attachments may contain confidential
> information of Rocket Software, Inc. All unauthorized use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> notify Rocket Software immediately and destroy all copies of this
> communication. Thank you.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: RACF for using SDSF

[Rob Scott]

Joseph,

I think you need to use the "CONNECT" command instead of ALTUSER :

CONNECT userid GROUP(group_name)

Afterwards a "LISTUSER userid" command should list all groups that the user is 
connected to.

As most sites run with "list of groups checking", there is normally no need to 
change the default group after a CONNECT.

Rob Scott
Rocket Software

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Joseph Reichman
Sent: Monday, September 4, 2023 3:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RACF for using SDSF

EXTERNAL EMAIL





Hi



I am getting the following message on my ADCD system



ISF024I USER ADCDANOT AUTHORIZED TO SDSF, NO GROUP ASSIGNMENT



I tried  ALU ADCDA GROUP(SYS1) this is the group that my other tso Is which has 
access to SDSF



Regardless after I do the command and do a LU ADCDA the group still shows up as 
TEST



When doing ALU ADCDA DFLTGRP(SYS1) racf says its not connected



thanks


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


Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ 
Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: 
https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - 
http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy


This communication and any attachments may contain confidential information of 
Rocket Software, Inc. All unauthorized use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please notify Rocket 
Software immediately and destroy all copies of this communication. Thank you.

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

Re: RACF for using SDSF

[Joseph Reichman]

Joe Reichman
Yep even did setropts refresh

On Mon, Sep 4, 2023 at 10:22 AM Colin Paice  wrote:

> did you logoff and logon again?
>
> On Mon, 4 Sept 2023 at 15:19, Joseph Reichman 
> wrote:
>
> > Hi
> >
> >
> >
> > I am getting the following message on my ADCD system
> >
> >
> >
> > ISF024I USER ADCDANOT AUTHORIZED TO SDSF, NO GROUP ASSIGNMENT
> >
> >
> >
> > I tried  ALU ADCDA GROUP(SYS1) this is the group that my other tso Is
> which
> > has access to SDSF
> >
> >
> >
> > Regardless after I do the command and do a LU ADCDA the group still shows
> > up
> > as TEST
> >
> >
> >
> > When doing ALU ADCDA DFLTGRP(SYS1) racf says its not connected
> >
> >
> >
> > thanks
> >
> >
> > --
> > For IBM-MAIN subscribe / signoff / archive access instructions,
> > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
> >
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: RACF for using SDSF

[Colin Paice]

did you logoff and logon again?

On Mon, 4 Sept 2023 at 15:19, Joseph Reichman  wrote:

> Hi
>
>
>
> I am getting the following message on my ADCD system
>
>
>
> ISF024I USER ADCDANOT AUTHORIZED TO SDSF, NO GROUP ASSIGNMENT
>
>
>
> I tried  ALU ADCDA GROUP(SYS1) this is the group that my other tso Is which
> has access to SDSF
>
>
>
> Regardless after I do the command and do a LU ADCDA the group still shows
> up
> as TEST
>
>
>
> When doing ALU ADCDA DFLTGRP(SYS1) racf says its not connected
>
>
>
> thanks
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: RACF passphrase support

[Seymour J Metz]

Don't forget session managers.


From: IBM Mainframe Discussion List  on behalf of 
Chicklon, Thomas <01fbdb5fcb44-dmarc-requ...@listserv.ua.edu>
Sent: Wednesday, June 14, 2023 11:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF passphrase support

Good point, the original question was how to force users to use phrases instead 
of passwords, which is quite easy.

Potentially much more difficult is making sure all applications that accept an 
ID and PW support a 100 character password field and know what to do with that 
data depending on whether the length entered is 1-8 or 9-100 characters.

TSO requires a change in PARMLIB(IKJTSO00), I believe CICS has a different log 
on trans (CESL vs. CESN), and I believe FTP supported long PWs with no changes. 
You would really need to look at every logon processing application in your 
shop.

Tom Chicklon

From: IBM Mainframe Discussion List  On Behalf Of 
Colin Paice
Sent: Wednesday, June 14, 2023 11:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF passphrase support

My logon screen only has space for an 8 char password. See Activating password 
phrase support 


My logon screen only has space for an 8 char password.  See Activating

password phrase support

<https://urldefense.com/v3/__https://www.ibm.com/docs/en/zos/2.5.0?topic=process-activating-password-phrase-support__;!!MwwqYLOC6b6whF7V!kylPYKnwdjWq2zinwEHX6KCGkN7b-FOLONDAQXt48DW1bdf5DxDIMxHFDZ0Gxj-G1aZW8BUTita5a-dbsu_xn3dQ$<https://urldefense.com/v3/__https:/www.ibm.com/docs/en/zos/2.5.0?topic=process-activating-password-phrase-support__;!!MwwqYLOC6b6whF7V!kylPYKnwdjWq2zinwEHX6KCGkN7b-FOLONDAQXt48DW1bdf5DxDIMxHFDZ0Gxj-G1aZW8BUTita5a-dbsu_xn3dQ$>>

on how to change it.



On Wed, 14 Jun 2023 at 15:30, Chicklon, Thomas <

01fbdb5fcb44-dmarc-requ...@listserv.ua.edu<mailto:01fbdb5fcb44-dmarc-requ...@listserv.ua.edu>>
 wrote:



> Probably the easiest would be to remove a user’s password and set a phrase

> for them.

>

> ALU userid NOPASSWORD PHRASE(‘This user must use a phrase now’) EXPIRED

>

> Tom Chicklon

>

> From: IBM Mainframe Discussion List 
> mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf

> Of rpinion865

> Sent: Wednesday, June 14, 2023 9:25 AM

> To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>

> Subject: RACF passphrase support

>

> If I want to move away from passwords and use passphrases, how do I force

> users to use passphrases, i. e. RACF exit(s)? Sent with [Proton

> Mail](https: //urldefense. com/v3/__https: //proton.

> me/__;!!MwwqYLOC6b6whF7V!g4K8lA4n8TXZEHOf91ceeBwpEiRFj0H1g790KV4_VVVs7EeisjYHAMzTyuUxvBny2g-VoVTM6v3WrjPby9VOaAp0mKbSfYGR7_0dTg$)

>

>

> If I want to move away from passwords and use passphrases, how do I force

> users to use passphrases, i.e. RACF exit(s)?

>

>

>

> Sent with [Proton Mail](

> https://urldefense.com/v3/__https://proton.me/__;!!MwwqYLOC6b6whF7V!g4K8lA4n8TXZEHOf91ceeBwpEiRFj0H1g790KV4_VVVs7EeisjYHAMzTyuUxvBny2g-VoVTM6v3WrjPby9VOaAp0mKbSfYGR7_0dTg$<https://urldefense.com/v3/__https:/proton.me/__;!!MwwqYLOC6b6whF7V!g4K8lA4n8TXZEHOf91ceeBwpEiRFj0H1g790KV4_VVVs7EeisjYHAMzTyuUxvBny2g-VoVTM6v3WrjPby9VOaAp0mKbSfYGR7_0dTg$%3e>

><https://urldefense.com/v3/__https:/proton.me/__;!!MwwqYLOC6b6whF7V!g4K8lA4n8TXZEHOf91ceeBwpEiRFj0H1g790KV4_VVVs7EeisjYHAMzTyuUxvBny2g-VoVTM6v3WrjPby9VOaAp0mKbSfYGR7_0dTg$%3e><

> https://urldefense.com/v3/__https:/proton.me/__;!!MwwqYLOC6b6whF7V!g4K8lA4n8TXZEHOf91ceeBwpEiRFj0H1g790KV4_VVVs7EeisjYHAMzTyuUxvBny2g-VoVTM6v3WrjPby9VOaAp0mKbSfYGR7_0dTg$>)<https://urldefense.com/v3/__https:/proton.me/__;!!MwwqYLOC6b6whF7V!g4K8lA4n8TXZEHOf91ceeBwpEiRFj0H1g790KV4_VVVs7EeisjYHAMzTyuUxvBny2g-VoVTM6v3WrjPby9VOaAp0mKbSfYGR7_0dTg$%3e)%3e>

><https://urldefense.com/v3/__https:/proton.me/__;!!MwwqYLOC6b6whF7V!g4K8lA4n8TXZEHOf91ceeBwpEiRFj0H1g790KV4_VVVs7EeisjYHAMzTyuUxvBny2g-VoVTM6v3WrjPby9VOaAp0mKbSfYGR7_0dTg$%3e)%3e>secure
> email.

>

>

>

> --

>

> For IBM-MAIN subscribe / signoff / archive access instructions,

>

> send email to 
> lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu%3cmailto:lists...@listserv.ua.edu>>

> with the message: INFO IBM-MAIN

>

> This e-mail transmission contains information that is confidential and may

> be privileged.   It is intended only for the addressee(s) named above. If

> you receive this e-mail in error, please do not read, copy or disseminate

> it in any manner. If you are not the intended recipient, any disclosure,

> copying, distribution or use of the contents of this information is

> prohibited. Please reply to the message immediately by informing the sender

> that the message was mis

Re: RACF passphrase support

[Chicklon, Thomas]

Good point, the original question was how to force users to use phrases instead 
of passwords, which is quite easy.

Potentially much more difficult is making sure all applications that accept an 
ID and PW support a 100 character password field and know what to do with that 
data depending on whether the length entered is 1-8 or 9-100 characters.

TSO requires a change in PARMLIB(IKJTSO00), I believe CICS has a different log 
on trans (CESL vs. CESN), and I believe FTP supported long PWs with no changes. 
You would really need to look at every logon processing application in your 
shop.

Tom Chicklon

From: IBM Mainframe Discussion List  On Behalf Of 
Colin Paice
Sent: Wednesday, June 14, 2023 11:12 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF passphrase support

My logon screen only has space for an 8 char password. See Activating password 
phrase support 


My logon screen only has space for an 8 char password.  See Activating

password phrase support

<https://urldefense.com/v3/__https://www.ibm.com/docs/en/zos/2.5.0?topic=process-activating-password-phrase-support__;!!MwwqYLOC6b6whF7V!kylPYKnwdjWq2zinwEHX6KCGkN7b-FOLONDAQXt48DW1bdf5DxDIMxHFDZ0Gxj-G1aZW8BUTita5a-dbsu_xn3dQ$<https://urldefense.com/v3/__https:/www.ibm.com/docs/en/zos/2.5.0?topic=process-activating-password-phrase-support__;!!MwwqYLOC6b6whF7V!kylPYKnwdjWq2zinwEHX6KCGkN7b-FOLONDAQXt48DW1bdf5DxDIMxHFDZ0Gxj-G1aZW8BUTita5a-dbsu_xn3dQ$>>

on how to change it.



On Wed, 14 Jun 2023 at 15:30, Chicklon, Thomas <

01fbdb5fcb44-dmarc-requ...@listserv.ua.edu<mailto:01fbdb5fcb44-dmarc-requ...@listserv.ua.edu>>
 wrote:



> Probably the easiest would be to remove a user’s password and set a phrase

> for them.

>

> ALU userid NOPASSWORD PHRASE(‘This user must use a phrase now’) EXPIRED

>

> Tom Chicklon

>

> From: IBM Mainframe Discussion List 
> mailto:IBM-MAIN@LISTSERV.UA.EDU>> On Behalf

> Of rpinion865

> Sent: Wednesday, June 14, 2023 9:25 AM

> To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>

> Subject: RACF passphrase support

>

> If I want to move away from passwords and use passphrases, how do I force

> users to use passphrases, i. e. RACF exit(s)? Sent with [Proton

> Mail](https: //urldefense. com/v3/__https: //proton.

> me/__;!!MwwqYLOC6b6whF7V!g4K8lA4n8TXZEHOf91ceeBwpEiRFj0H1g790KV4_VVVs7EeisjYHAMzTyuUxvBny2g-VoVTM6v3WrjPby9VOaAp0mKbSfYGR7_0dTg$)

>

>

> If I want to move away from passwords and use passphrases, how do I force

> users to use passphrases, i.e. RACF exit(s)?

>

>

>

> Sent with [Proton Mail](

> https://urldefense.com/v3/__https://proton.me/__;!!MwwqYLOC6b6whF7V!g4K8lA4n8TXZEHOf91ceeBwpEiRFj0H1g790KV4_VVVs7EeisjYHAMzTyuUxvBny2g-VoVTM6v3WrjPby9VOaAp0mKbSfYGR7_0dTg$<https://urldefense.com/v3/__https:/proton.me/__;!!MwwqYLOC6b6whF7V!g4K8lA4n8TXZEHOf91ceeBwpEiRFj0H1g790KV4_VVVs7EeisjYHAMzTyuUxvBny2g-VoVTM6v3WrjPby9VOaAp0mKbSfYGR7_0dTg$%3e>

><https://urldefense.com/v3/__https:/proton.me/__;!!MwwqYLOC6b6whF7V!g4K8lA4n8TXZEHOf91ceeBwpEiRFj0H1g790KV4_VVVs7EeisjYHAMzTyuUxvBny2g-VoVTM6v3WrjPby9VOaAp0mKbSfYGR7_0dTg$%3e><

> https://urldefense.com/v3/__https:/proton.me/__;!!MwwqYLOC6b6whF7V!g4K8lA4n8TXZEHOf91ceeBwpEiRFj0H1g790KV4_VVVs7EeisjYHAMzTyuUxvBny2g-VoVTM6v3WrjPby9VOaAp0mKbSfYGR7_0dTg$>)<https://urldefense.com/v3/__https:/proton.me/__;!!MwwqYLOC6b6whF7V!g4K8lA4n8TXZEHOf91ceeBwpEiRFj0H1g790KV4_VVVs7EeisjYHAMzTyuUxvBny2g-VoVTM6v3WrjPby9VOaAp0mKbSfYGR7_0dTg$%3e)%3e>

><https://urldefense.com/v3/__https:/proton.me/__;!!MwwqYLOC6b6whF7V!g4K8lA4n8TXZEHOf91ceeBwpEiRFj0H1g790KV4_VVVs7EeisjYHAMzTyuUxvBny2g-VoVTM6v3WrjPby9VOaAp0mKbSfYGR7_0dTg$%3e)%3e>secure
> email.

>

>

>

> --

>

> For IBM-MAIN subscribe / signoff / archive access instructions,

>

> send email to 
> lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu%3cmailto:lists...@listserv.ua.edu>>

> with the message: INFO IBM-MAIN

>

> This e-mail transmission contains information that is confidential and may

> be privileged.   It is intended only for the addressee(s) named above. If

> you receive this e-mail in error, please do not read, copy or disseminate

> it in any manner. If you are not the intended recipient, any disclosure,

> copying, distribution or use of the contents of this information is

> prohibited. Please reply to the message immediately by informing the sender

> that the message was misdirected. After replying, please erase it from your

> computer system. Your assistance in correcting this error is appreciated.

>

> --

> For IBM-MAIN subscribe / signoff / archive access instructions,

> send email to 

Re: RACF passphrase support

[Colin Paice]

My logon screen only has space for an 8 char password.  See Activating
password phrase support

on how to change it.

On Wed, 14 Jun 2023 at 15:30, Chicklon, Thomas <
01fbdb5fcb44-dmarc-requ...@listserv.ua.edu> wrote:

> Probably the easiest would be to remove a user’s password and set a phrase
> for them.
>
> ALU userid NOPASSWORD PHRASE(‘This user must use a phrase now’) EXPIRED
>
> Tom Chicklon
>
> From: IBM Mainframe Discussion List  On Behalf
> Of rpinion865
> Sent: Wednesday, June 14, 2023 9:25 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: RACF passphrase support
>
> If I want to move away from passwords and use passphrases, how do I force
> users to use passphrases, i. e. RACF exit(s)? Sent with [Proton
> Mail](https: //urldefense. com/v3/__https: //proton.
> me/__;!!MwwqYLOC6b6whF7V!g4K8lA4n8TXZEHOf91ceeBwpEiRFj0H1g790KV4_VVVs7EeisjYHAMzTyuUxvBny2g-VoVTM6v3WrjPby9VOaAp0mKbSfYGR7_0dTg$)
>
>
> If I want to move away from passwords and use passphrases, how do I force
> users to use passphrases, i.e. RACF exit(s)?
>
>
>
> Sent with [Proton Mail](
> https://urldefense.com/v3/__https://proton.me/__;!!MwwqYLOC6b6whF7V!g4K8lA4n8TXZEHOf91ceeBwpEiRFj0H1g790KV4_VVVs7EeisjYHAMzTyuUxvBny2g-VoVTM6v3WrjPby9VOaAp0mKbSfYGR7_0dTg$
> <
> https://urldefense.com/v3/__https:/proton.me/__;!!MwwqYLOC6b6whF7V!g4K8lA4n8TXZEHOf91ceeBwpEiRFj0H1g790KV4_VVVs7EeisjYHAMzTyuUxvBny2g-VoVTM6v3WrjPby9VOaAp0mKbSfYGR7_0dTg$>)
> secure email.
>
>
>
> --
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
>
> send email to lists...@listserv.ua.edu
> with the message: INFO IBM-MAIN
>
> This e-mail transmission contains information that is confidential and may
> be privileged.   It is intended only for the addressee(s) named above. If
> you receive this e-mail in error, please do not read, copy or disseminate
> it in any manner. If you are not the intended recipient, any disclosure,
> copying, distribution or use of the contents of this information is
> prohibited. Please reply to the message immediately by informing the sender
> that the message was misdirected. After replying, please erase it from your
> computer system. Your assistance in correcting this error is appreciated.
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>

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

Re: RACF passphrase support

[Radoslaw Skorupka]

W dniu 14.06.2023 o 15:24, rpinion865 pisze:

If I want to move away from passwords and use passphrases, how do I force users 
to use passphrases, i.e. RACF exit(s)?


Quite simple.
You have to set initial passphrase for every user you want to migrate. 
And give them the passphrases (I assume unique initial passphrases, not 
the common one).
Then ALU each-user NOPASSWORD  - that disallow password. Note, this is 
relatively new feature, AFAIR introduced in z/OS 2.2.
For older systems it is enough to ALU user PASSWORD(random keystrokes 
you forget)  - the password would exist, but no one would know it.



--
Radoslaw Skorupka
Lodz, Poland

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

Re: RACF passphrase support

[Lennie Dymoke-Bradshaw]

I recommend posting to the RACF-L list.
You'll get a lot of help there.

Lennie Dymoke-Bradshaw
https://rsclweb.com 
‘Dance like no one is watching. Encrypt like everyone is.’

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
rpinion865
Sent: 14 June 2023 14:25
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RACF passphrase support

If I want to move away from passwords and use passphrases, how do I force users 
to use passphrases, i.e. RACF exit(s)?

Sent with [Proton Mail](https://proton.me/) secure email.

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

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

Re: RACF passphrase support

[Chicklon, Thomas]

Probably the easiest would be to remove a user’s password and set a phrase for 
them.

ALU userid NOPASSWORD PHRASE(‘This user must use a phrase now’) EXPIRED

Tom Chicklon

From: IBM Mainframe Discussion List  On Behalf Of 
rpinion865
Sent: Wednesday, June 14, 2023 9:25 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: RACF passphrase support

If I want to move away from passwords and use passphrases, how do I force users 
to use passphrases, i. e. RACF exit(s)? Sent with [Proton Mail](https: 
//urldefense. com/v3/__https: //proton. 
me/__;!!MwwqYLOC6b6whF7V!g4K8lA4n8TXZEHOf91ceeBwpEiRFj0H1g790KV4_VVVs7EeisjYHAMzTyuUxvBny2g-VoVTM6v3WrjPby9VOaAp0mKbSfYGR7_0dTg$)


If I want to move away from passwords and use passphrases, how do I force users 
to use passphrases, i.e. RACF exit(s)?



Sent with [Proton 
Mail](https://urldefense.com/v3/__https://proton.me/__;!!MwwqYLOC6b6whF7V!g4K8lA4n8TXZEHOf91ceeBwpEiRFj0H1g790KV4_VVVs7EeisjYHAMzTyuUxvBny2g-VoVTM6v3WrjPby9VOaAp0mKbSfYGR7_0dTg$)
 secure email.



--

For IBM-MAIN subscribe / signoff / archive access instructions,

send email to lists...@listserv.ua.edu with 
the message: INFO IBM-MAIN

This e-mail transmission contains information that is confidential and may be 
privileged.   It is intended only for the addressee(s) named above. If you 
receive this e-mail in error, please do not read, copy or disseminate it in any 
manner. If you are not the intended recipient, any disclosure, copying, 
distribution or use of the contents of this information is prohibited. Please 
reply to the message immediately by informing the sender that the message was 
misdirected. After replying, please erase it from your computer system. Your 
assistance in correcting this error is appreciated.

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

Re: RACF and Subject Alternate Name

[Michael Babcock]

Thanks all!   The gskkyman utility seems to do what I want.

On Fri, Jun 9, 2023 at 9:27 AM Matt Hogstrom  wrote:

> At Broadcom we’ve have customers that have experienced similar issues and
> we’ve suggested the same workaround that Charles describes with no issues.
> The CSR generation functionality is platform dependent (ie RACF’s
> restriction) but the process is the same for all certs regardless of where
> they are initiated.
>
> Matt Hogstrom
>
> “It may be cognitive, but, it ain’t intuitive."
> — Hogstrom
>
>
>
> > On Jun 8, 2023, at 11:29 AM, Charles Mills  wrote:
> >
> > Yes, you can generate a CSR, typically including multiple SANs, with
> OpenSSL (any platform), gskkyman, or even on a CA Web site (or in the case
> of an in-house CA, using their certificate management tools).
> >
> > Yes, you should be able to import that certificate when signed and its
> private key into RACF. Check out RACDCERT IMPORT.
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
-- 
Michael Babcock
OneMain Financial
z/OS Systems Programmer, Lead

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

Re: RACF and Subject Alternate Name

[Matt Hogstrom]

At Broadcom we’ve have customers that have experienced similar issues and we’ve 
suggested the same workaround that Charles describes with no issues.  The CSR 
generation functionality is platform dependent (ie RACF’s restriction) but the 
process is the same for all certs regardless of where they are initiated.

Matt Hogstrom

“It may be cognitive, but, it ain’t intuitive."
— Hogstrom



> On Jun 8, 2023, at 11:29 AM, Charles Mills  wrote:
> 
> Yes, you can generate a CSR, typically including multiple SANs, with OpenSSL 
> (any platform), gskkyman, or even on a CA Web site (or in the case of an 
> in-house CA, using their certificate management tools).
> 
> Yes, you should be able to import that certificate when signed and its 
> private key into RACF. Check out RACDCERT IMPORT. 


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

Re: RACF and Subject Alternate Name

[Walt Farrell]

On Thu, 8 Jun 2023 05:29:41 -0500, Michael Babcock  
wrote:
>
>And I simply don't see why RACF could not be made to generate more than
>one SAN.   Will that change with z/OS 3.1?

The RACF-L mailing list would be a better place for that part of your question, 
and (perhaps) for the complete question.

-- 
Walt

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

Re: RACF and Subject Alternate Name

[Charles Mills]

Let me do my best here.

Yes, you can generate a CSR, typically including multiple SANs, with OpenSSL 
(any platform), gskkyman, or even on a CA Web site (or in the case of an 
in-house CA, using their certificate management tools).

Yes, you should be able to import that certificate when signed and its private 
key into RACF. Check out RACDCERT IMPORT. There is a risk in having the private 
key floating around in e-mails or whatever. It is supposed to be private after 
all.

I don't know health checker at all but I would ber very surprised if it 
"discriminated against" certificates imported from elsewhere. It supports CA 
certificates, right? They are pretty much always imported.

>And I simply don't see why RACF could not be made to generate more than
>one SAN.   Will that change with z/OS 3.1?

The people who actually know about such things seem to indicate that IBM is 
quite content with the current state of affairs. Could it change? Yes. Will it? 
I doubt it. I believe IBM markets "extra cost" tools that support this 
functionality.

Charles

On Thu, 8 Jun 2023 05:29:41 -0500, Michael Babcock  
wrote:

>Our corporate certificate management folks are now mandating that all
>Subject Alternate Names be placed in the CSR.   That's a problem for
>RACF which cannot add more than one SAN (we are at z/OS 2.5). How do
>others generate the CSR?   If we generate a cert say in USS, using
>openssl or gskkyman, send that off to our local certificate folks, get
>back a certificate, then what?   I assume we will need to export that
>cert (along with it's private key) and import that cert into RACF.   The
>export/import process is what I'm unsure of.
>
>I also use the z/OS Health Checker to see which RACF Certs are expiring
>in the next 60 days.  Will importing a certificate not created in RACF
>cause the cert to not show up in the HC?
>
>And I simply don't see why RACF could not be made to generate more than
>one SAN.   Will that change with z/OS 3.1?

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

Re: RACF MFA

[Jousma, David]

MFA is a separately charged product from IBM, and is licensed in blocks of 500 
users.  So there will be a software purchase and install on top of the racf 
changes

Dave Jousma

Vice President | Director, Technology Engineering


Fifth Third Bank  |  1830 East Paris Ave, SE  |  MD RSCB2H  |  Grand Rapids, MI 
49546

616.653.8429

From: IBM Mainframe Discussion List  on behalf of 
Bill Giannelli 
Sent: Wednesday, April 26, 2023 12:55:04 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: RACF MFA

what is needed to implement MFA (Multi Factor Authentication) in RACF aside 
from the RACF changes? would network changes be needed also? thanks Bill 
-- For 
IBM-MAIN subscribe
ZjQcmQRYFpfptBannerStart
CAUTION EXTERNAL EMAIL
This message came from outside your organization.
DO NOT open attachments or click on links from unknown senders or unexpected 
emails.

ZjQcmQRYFpfptBannerEnd

what is needed to implement MFA (Multi Factor Authentication) in RACF aside 
from the RACF changes?
would network changes be needed also?
thanks
Bill

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

This e-mail transmission contains information that is confidential and may be 
privileged.
It is intended only for the addressee(s) named above. If you receive this 
e-mail in error,
please do not read, copy or disseminate it in any manner.  If you are not the 
intended 
recipient, any disclosure, copying, distribution or use of the contents of this 
information
is prohibited. Please reply to the message immediately by informing the sender 
that the 
message was misdirected. After replying, please erase it from your computer 
system. Your 
assistance in correcting this error is appreciated.




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

Re: RACF - SDSF question

[Ed Jaffe]

On 2/8/2023 3:10 PM, Lennie Dymoke-Bradshaw wrote:

Ed,


We have NO discrete profiles, but we do have generic profiles with no wildcard 
characters in them.

You can do that with profiles in the DATASET class but I don't think you can do 
it with general classes.


Good point. I should have said we have NO discrete profiles in the 
DATASET class... :-[



--
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

Re: RACF - SDSF question

[Lennie Dymoke-Bradshaw]

Ed,

> We have NO discrete profiles, but we do have generic profiles with no 
> wildcard characters in them.

You can do that with profiles in the DATASET class but I don't think you can do 
it with general classes. 
There is no GENERIC parameter on the RDEFINE command. 
Or do you use some local code to achieve this?

Lennie

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of Ed 
Jaffe
Sent: 08 February 2023 02:32
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

On 2/7/2023 5:14 PM, Seymour J Metz wrote:
> Generic is usually more useful, but you can certainly use specific profiles.

Even discrete profiles can be made generic by specifying GENERIC when created.

That's what we do here. We have NO discrete profiles, but we do have generic 
profiles with no wildcard characters in them.


-- 
Phoenix Software International
Edward E. Jaffe
831 Parkview Drive North
El Segundo, CA 90245
https://www.phoenixsoftware.com/



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

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

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

Re: RACF - SDSF question

[Shaffer, Terri]

Thank you, with your input and Robs, I now know the order of the checks, which 
was the piece I didn't fully understand.

I have now cleaned up my extra rules and added rules under jesspool and they 
are now stopped.

Rob, thanks for the slides!

Ms Terri E Shaffer
Senior Systems Engineer,
z/OS Support:
ACIWorldwide - Telecommuter
H(412-766-2697) C(412-519-2592)
terri.shaf...@aciworldwide.com

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Robert S. Hansel (RSH)
Sent: Wednesday, February 8, 2023 8:00 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: RACF - SDSF question

EXTERNAL EMAIL: Do not click links or open attachments unless you know the 
content is safe.


Hi Terri,

Here are a couple of thoughts to add to what others have mentioned.

Since SDSF is issuing a JES2 cancel job $CJ command, the name of the OPERCMDS 
resource being checked is JES2.CANCEL.BAT. Profile JES2.CANCEL.BAT.C30TCI* is 
superfluous since the resource name never includes the jobname, so you can 
delete it. Profile JES2.CANCEL.BAT.** is guarding JES2.CANCEL.BAT because the 
.** generic suffix applies to zero or more qualifiers, and in this case it is 
zero qualifiers. The suggestions to lock down MVS cancel job commands won't 
help in this situation because SDSF is issuing JES2 commands instead of MVS 
commands, so the OPERCMDS MVS.CANCEL.JOB.jobname resources won't be checked.

As was mentioned, to cancel a job typically also requires ALTER access to the 
JESSPOOL resource guarding the job. Look into setting up appropriate JESSPOOL 
profiles to isolate and restrict ALTER access to these jobs. Also consider 
whether users have been (inadvertently) set up as Destination Operators. If 
they have READ access to SDSF resource ISFOPER.DEST.JES2 and ALTER access to 
SDSF resources prefixed ISFAUTH.DEST., they can cancel jobs while bypassing 
JESSPOOL profile checks.

If the CONSOLE class is active, you can permit ID(*) UPDATE access to 
JES2.CANCEL.BAT.** conditionally by adding operand WHEN(CONSOLE(SDSF)) to the 
PERMIT command so that users can only issue JES2 cancel job commands from 
within SDSF panels. This would prevent them from cancelling jobs outside of 
SDSF, to include when using the SDSF / command. You would need to remove 
UACC(UPDATE) or ID(*) UPDATE permission, whichever applies, for the conditional 
permission to take effect. Operations and Tech Support staff will need 
'regular' UPDATE access permission. (CONSOLE is a Default Return Code 8 class, 
so don't activate it without first creating a ** profile with UACC(READ).)

To see exactly what resource names are being checked that are allowing the 
unwanted job cancellations, issue the SDSF command SET SECTRACE ON, cancel the 
job, and then issue the SDSF command ULOG. ULOG will show you all the access 
checks SDSF is making along with the results of each of these checks. SECTRACE 
is a phenomenal diagnostic tool that we use often.

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.  *** Celebrating our 30th Anniversary ***
617-969-8211
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Froberthansel=05%7C01%7Cterri.shaffer%40ACIWORLDWIDE.COM%7Ca4b8cc465d9d4ac4987c08db09d46b79%7Cd1b7f1185cb24d4e85a382e07efb07e9%7C1%7C0%7C638114580161994985%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Em%2B3BnJ2qLn7XTrRRvmVtmo5gWOhCx2xDk%2FCAaEkZUg%3D=0
https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rshconsulting.com%2F=05%7C01%7Cterri.shaffer%40ACIWORLDWIDE.COM%7Ca4b8cc465d9d4ac4987c08db09d46b79%7Cd1b7f1185cb24d4e85a382e07efb07e9%7C1%7C0%7C638114580161994985%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=NHrWwR8EBpDn81MjpoubOzpQSJr1NGjmwVVmlYYzMjg%3D=0

-Original Message-
Date:Tue, 7 Feb 2023 13:31:41 +
From:"Shaffer, Terri" 
Subject: RACF - SDSF question

Hi,
 I know there is a RACF group, but hopefully this is simple and I am just 
missing something I have done 100 times over with no issues.

We run our CICS regions as batch jobs, and I just found out a user instead of 
them issuing a CEMT PERF SHUT command, they are canceling it.

Which then causing a 100 vsam messages on startup with all the verifies, and if 
something goes wrong they call me...

So I tried to stop this habit, I know they are putting a C beside the CICS and 
a $CJ(x) command

So I have 2 rules in RACF under OPERCMDS

JES2.CANCEL.BAT.C30TCI* (G)
JES2.CANCEL.BAT.** (G)

If I restrict the BAT.**  then they cant cancel even their own batch jobs, So I 
always thought more specific is looked at first?

One of my previous co-workers implemented SDSF-RACF rules converted from 
ISFPARMS.

Lastly, I understand this doesn't stop them from canceling any other jobs, but 
since this is a development shop we allow more access than most.

But I don't want users