Re: help with REXX code reading RACF LU function

[Robert S. Hansel]

HI Lizette,

Why not use the RACF database unload IRRDBU00 output instead?

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:Sun, 8 Sep 2024 12:53:31 -0700
From:Lizette Koehler 
Subject: help with REXX code reading RACF LU function

I am coding a REXX to read the output from LU userid 

 

I am working on learning IRRXUTIL   but that will be a bit later

 

I need to capture the name and installation date

 

The Installation date can be long

 

 

INSTALLATION-DATA=*** ** **
** *

My challenge is creating a one line entry for my results.  It may go into
excel later.

 

Output keeps wrapping when I run  REXX in batch with SAY commands

 

Output will be

 

USERID  dlm  NAME  dlm  Owner dlm Create Date dlm Last Logon dlm
Installation-data

 

Since the Installation- data can vary in length - the long lines  wrap

 

What is a good solution to create a 200 Lrecl output using SAY using
ISIPF/REXX process

 

Lizette

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

Re: help with REXX code reading RACF LU function

[Seymour J Metz]

For long lines, EXECIO and stream I/O are the preferred tools unless ISPF 
services are available. The say statement is intended for human-readable output.


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




From: IBM Mainframe Discussion List  on behalf of 
Lizette Koehler 
Sent: Sunday, September 8, 2024 3:53 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: help with REXX code reading RACF LU function

I am coding a REXX to read the output from LU userid



I am working on learning IRRXUTIL   but that will be a bit later



I need to capture the name and installation date



The Installation date can be long





INSTALLATION-DATA=*** ** **
** *

My challenge is creating a one line entry for my results.  It may go into
excel later.



Output keeps wrapping when I run  REXX in batch with SAY commands



Output will be



USERID  dlm  NAME  dlm  Owner dlm Create Date dlm Last Logon dlm
Installation-data



Since the Installation- data can vary in length - the long lines  wrap



What is a good solution to create a 200 Lrecl output using SAY using
ISIPF/REXX process



Lizette






--
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: help with REXX code reading RACF LU function

[ITschak Mugzach]

/* rexx */

TrapMode = outtrap('racf.')
'lu s22'
TrapMode = OutTrap('OFF')

SinglLine = ''

Do i = 1 to racf.0
   singleLine = SingleLine Racf.i
   End

If (Pos('NO-INSTALLATION-DATA',SingleLine) = 0) Then Do
   xInstData = ''
   parse Var SingleLine . 'NAME=' xName 'OWNER=' . 'INSTALLATION-DATA'
   End

Else Do
   parse Var SingleLine . 'NAME=' xName 'OWNER=' . 'INSTALLATION-DATA'
   End



ITschak Mugzach
*|** IronSphere Platform* *|* *Information Security Continuous Monitoring
for z/OS, x/Linux & IBM I **| z/VM coming soon  *




On Sun, Sep 8, 2024 at 10:53 PM Lizette Koehler 
wrote:

> I am coding a REXX to read the output from LU userid
>
>
>
> I am working on learning IRRXUTIL   but that will be a bit later
>
>
>
> I need to capture the name and installation date
>
>
>
> The Installation date can be long
>
>
>
>
>
> INSTALLATION-DATA=*** ** **
> ** *
>
> My challenge is creating a one line entry for my results.  It may go into
> excel later.
>
>
>
> Output keeps wrapping when I run  REXX in batch with SAY commands
>
>
>
> Output will be
>
>
>
> USERID  dlm  NAME  dlm  Owner dlm Create Date dlm Last Logon dlm
> Installation-data
>
>
>
> Since the Installation- data can vary in length - the long lines  wrap
>
>
>
> What is a good solution to create a 200 Lrecl output using SAY using
> ISIPF/REXX process
>
>
>
> Lizette
>
>
>
>
>
>
> --
> 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

help with REXX code reading RACF LU function

[Lizette Koehler]

I am coding a REXX to read the output from LU userid 

 

I am working on learning IRRXUTIL   but that will be a bit later

 

I need to capture the name and installation date

 

The Installation date can be long

 

 

INSTALLATION-DATA=*** ** **
** *

My challenge is creating a one line entry for my results.  It may go into
excel later.

 

Output keeps wrapping when I run  REXX in batch with SAY commands

 

Output will be

 

USERID  dlm  NAME  dlm  Owner dlm Create Date dlm Last Logon dlm
Installation-data

 

Since the Installation- data can vary in length - the long lines  wrap

 

What is a good solution to create a 200 Lrecl output using SAY using
ISIPF/REXX process

 

Lizette

 

 


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

Re: Sharing RACF DB in monoplex

[roscoe5]

Thanks Hayim,
That was my experience. I inherited RACF at my old shop, and never thought much 
about the sharing setup; it worked fine.
We had one box, w Prod/Test/Tech LPARs, and one RACF. No problems.
It’s good to know the options.

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

On Tue, Jul 23, 2024 at 11:21 AM, Hayim Sokolsky 
<[062497e865c9-dmarc-requ...@listserv.ua.edu](mailto:On Tue, Jul 23, 2024 
at 11:21 AM, Hayim Sokolsky < wrote:

> Normally I'd recommend asking this question in the RACF-L.
>
> RACF has supported sharing the RACF Database long before the existence of GRS 
> or Sysplex. The critical rule is that the RACF Database must be shared the 
> same way across all the systems using that RACF Database. The ways of sharing 
> are:
>
> 1. Shared disk with Reserve/Release - this is what RACF did prior to sysplex.
> 2. Simple sharing within a sysplex without a coupling facility - 
> SYSPLEX(NODATASHARING)
> 3. Sysplex with a coupling facility - SYSPLEX(DATSHARING)
>
> As long as all systems have the same setup listed above, things work fine. 
> However, if some systems are using SYSPLEX (DATASHARING or NODATASHARING) and 
> others are not using SYSPLEX, the RACF Database will quickly get destroyed 
> because they are not serializing changes the same way. Once broken, there is 
> no remedy except restoring an old copy of the RACF Database prior to the 
> damage.
>
> Hayim Sokolsky (he/him/his)
> Director, Software Engineering
> Rocket Software, USA
> E: hsokol...@rocketsoftware.com
> W:RocketSoftware.com
>
> The views I have expressed in this email are my own personal views, and are 
> not endorsed or supported by, and do not necessarily express or reflect the 
> views, positions, or strategies of my employer.
>
> -Original Message-
> From: IBM Mainframe Discussion List  On Behalf Of 
> Peter
> Sent: Tuesday, July 23, 2024 12:49 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Sharing RACF DB in monoplex
>
> EXTERNAL EMAIL
>
> Hello
>
> Good evening
>
> Is it possible to share one RACF DB in a monoplex environment of 4 LPARS ?
> Without using RRSF and making GRS for serialization across the 4 LPARS
>
> Any experience or advise is much appreciated
>
> Peter
>
> --
> 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: Sharing RACF DB in monoplex

[Hayim Sokolsky]

Normally I'd recommend asking this question in the RACF-L.

RACF has supported sharing the RACF Database long before the existence of GRS 
or Sysplex. The critical rule is that the RACF Database must be shared the same 
way across all the systems using that RACF Database. The ways of sharing are:

1. Shared disk with Reserve/Release - this is what RACF did prior to sysplex.
2. Simple sharing within a sysplex without a coupling facility - 
SYSPLEX(NODATASHARING)
3. Sysplex with a coupling facility - SYSPLEX(DATSHARING)

As long as all systems have the same setup listed above, things work fine. 
However, if some systems are using SYSPLEX (DATASHARING or NODATASHARING) and 
others are not using SYSPLEX, the RACF Database will quickly get destroyed 
because they are not serializing changes the same way. Once broken, there is no 
remedy except restoring an old copy of the RACF Database prior to the damage.


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

The views I have expressed in this email are my own personal views, and are not 
endorsed or supported by, and do not necessarily express or reflect the views, 
positions, or strategies of my employer.

-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter
Sent: Tuesday, July 23, 2024 12:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Sharing RACF DB in monoplex

EXTERNAL EMAIL





Hello

Good evening

Is it possible to share one RACF DB in a monoplex environment of 4 LPARS ?
Without using RRSF and making GRS for serialization across the 4 LPARS

Any experience or advise is much appreciated

Peter

--
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: Sharing RACF DB in monoplex

[Allan Staller]

Classification: Confidential

Possible, but highly risky. I would not do it.
It's not my dog.

However, I would suggest MIMGR or excluding all RACF database calls from GRS.
Beware the performance impacts and possible resource deadlocks.

My USD $0.02 worth.



-Original Message-
From: IBM Mainframe Discussion List  On Behalf Of 
Peter
Sent: Monday, July 22, 2024 11:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Sharing RACF DB in monoplex

[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

Good evening

Is it possible to share one RACF DB in a monoplex environment of 4 LPARS ?
Without using RRSF and making GRS for serialization across the 4 LPARS

Any experience or advise is much appreciated

Peter

--
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

Sharing RACF DB in monoplex

[Peter]

Hello

Good evening

Is it possible to share one RACF DB in a monoplex environment of 4 LPARS ?
Without using RRSF and making GRS for serialization across the 4 LPARS

Any experience or advise is much appreciated

Peter

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

Re: RACF permission to INETD OTELNET port?

[Robert S. Hansel]

Binyamin,

Along these same lines, see if PORT statements for these reserved ports assign 
SAF values, and then check the profiles protecting them in the SERVAUTH class. 
The format of the SAF resource name is EZB.PORTACCESS.sysname.tcpname.resname, 
where 'resname' is the SAF value assigned by the PORT statement. That said, I 
would have expected you to have seen ICH408I violation messages if this were 
the case.

Our presentation on SERVAUTH might also be of help in troubleshooting this.

https://www.rshconsulting.com/RSHpres/RSH_Consulting__SERVAUTH_Class__June_2021.pdf

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:Mon, 17 Jun 2024 15:28:13 -0500
From:Stuart Holland 
Subject: Re: RACF permission to INETD OTELNET port?

Check the PROFILE.TCPIP data set. PORT statements in there reserve ports 
to specific job names. Anything else trying to use that port will be 
rejected.

On 6/17/24 1:30 PM, Tom Brennan wrote:
> Well that destroys my theory that the problem was caused by a non-root 
> id :)  Like you say, there must be something else involved. Sounds 
> like you're making progress though.
>
> Just curious, what made you choose port 323?
>
> On 6/17/2024 9:26 AM, Binyamin Dissen wrote:
>> Changed it to 323 and it works.
>>
>> I cannot figure out which BPX* resource would control this (23) and how.
>>
>> On Mon, 17 Jun 2024 06:01:03 -0700 Tom Brennan 
>> 
>> wrote:
>>
>> :>I'm not sure if Attila was saying to try this, but if you can 
>> change the
>> :>port to something higher than 1024 and the bind works, that would
>> :>indicate you're not really root at the time of the bind. Then if the
>> :>userid starting the task is root, maybe somebody is doing a 
>> setuid() or
>> :>similar before the bind.
>> :>
>> :>On 6/17/2024 1:26 AM, Attila Fogarasi wrote:
>> :>> Is INETD configured correctly?  Your config is in 
>> etc/inetd/conf*. *TELNET
>> :>> is delivered specifying an ID of OMVSKERN and must be defined 
>> with both
>> :>> superuser and daemon authority.  Guessing you are using OMVSKERN 
>> based on
>> :>> uid(0).  Your port 722 is presumably defined in the /etc/services 
>> file
>> :>>
>> :>> On Mon, Jun 17, 2024 at 6:10?PM Attila Fogarasi 
>>  wrote:
>> :>>
>> :>>> Brave man running uid(0) for other than the OMVS kernel ... 
>> usually uid(0)
>> :>>> does give superuser authority, but you may need to be in 
>> group(SYS1) and
>> :>>> have a GID.  Another possibility is having root as HOME('/').  
>> good luck,
>> :>>> its frustrating that simply things like getting a reason code for
>> :>>> "permission denied" is not so easy.
>> :>>>
>> :>>> On Mon, Jun 17, 2024 at 5:19?PM Binyamin Dissen <
>> :>>> 0662573e2c3a-dmarc-requ...@listserv.ua.edu> wrote:
>> :>>>
>> :>>>> Took a dump of the address space, and the associated userid has 
>> UID(0)
>> :>>>>
>> :>>>> What else would be required for root access?
>> :>>>>
>> :>>>> On Mon, 17 Jun 2024 06:29:01 +1000 Attila Fogarasi
>> :>>>> <05b6fee9abb7-dmarc-requ...@listserv.ua.edu> wrote:
>> :>>>>
>> :>>>> :>port 722 is a privileged port, usually means your program 
>> needs root
>> :>>>> :>access, all of that is configured outside of RACF.
>> :>>>> :>
>> :>>>> :>On Mon, Jun 17, 2024 at 6:16?AM Binyamin Dissen <
>> :>>>> :>0662573e2c3a-dmarc-requ...@listserv.ua.edu> wrote:
>> :>>>> :>
>> :>>>> :>> On Sun, 16 Jun 2024 09:47:20 -0500 Walt Farrell
>> :>>>> :>> <05bd6dbb44aa-dmarc-requ...@listserv.ua.edu> wrote:
>> :>>>> :>>
>> :>>>> :>> :>On Sun, 16 Jun 2024 17:20:34 +0300, Binyamin Dissen <
>> :>>>> :>> bdis...@dissensoftware.com> wrote:
>> :>>>> :>>
>> :>>>> :>> :>>Getting
>> :>>>> :>>
>> :>>>> :>> :>>BPXF024I (TCPIP) Jun 16 06:38:15 inetd 65583 : FOMN0091
>> :>>>> *:otelnet/tcp:
>> :>>>> :>> :>>722 bind: EDC5111I Permission denied., rsn=744C7246
>> :>>>> :>>
>> :>>>> :>> :>>Not sure where it got 722 - looked in all the /etc places.
>> :>>>> :>>
>> :>>>> :>> :>>Also, what permission would be required to all;ow access 
>> to 722?
>> :>>>> Don't
>> :>>>> :>> seer
>> :>>>> :>> :>>anything obvious.
>> :>>>> :>>
>> :>>>> :>> :>What evidence do you have that it's a RACF issue?
>> :>>>> :>>
>> :>>>> :>> I am guessing from "permission denied"
>> :>>>>
>> :>>>> --
>> :>>>> 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 permission to INETD OTELNET port?

[Stuart Holland]

Check the PROFILE.TCPIP data set. PORT statements in there reserve ports 
to specific job names. Anything else trying to use that port will be 
rejected.


On 6/17/24 1:30 PM, Tom Brennan wrote:
Well that destroys my theory that the problem was caused by a non-root 
id :)  Like you say, there must be something else involved. Sounds 
like you're making progress though.


Just curious, what made you choose port 323?

On 6/17/2024 9:26 AM, Binyamin Dissen wrote:

Changed it to 323 and it works.

I cannot figure out which BPX* resource would control this (23) and how.

On Mon, 17 Jun 2024 06:01:03 -0700 Tom Brennan 


wrote:

:>I'm not sure if Attila was saying to try this, but if you can 
change the

:>port to something higher than 1024 and the bind works, that would
:>indicate you're not really root at the time of the bind. Then if the
:>userid starting the task is root, maybe somebody is doing a 
setuid() or

:>similar before the bind.
:>
:>On 6/17/2024 1:26 AM, Attila Fogarasi wrote:
:>> Is INETD configured correctly?  Your config is in 
etc/inetd/conf*. *TELNET
:>> is delivered specifying an ID of OMVSKERN and must be defined 
with both
:>> superuser and daemon authority.  Guessing you are using OMVSKERN 
based on
:>> uid(0).  Your port 722 is presumably defined in the /etc/services 
file

:>>
:>> On Mon, Jun 17, 2024 at 6:10?PM Attila Fogarasi 
 wrote:

:>>
:>>> Brave man running uid(0) for other than the OMVS kernel ... 
usually uid(0)
:>>> does give superuser authority, but you may need to be in 
group(SYS1) and
:>>> have a GID.  Another possibility is having root as HOME('/').  
good luck,

:>>> its frustrating that simply things like getting a reason code for
:>>> "permission denied" is not so easy.
:>>>
:>>> On Mon, Jun 17, 2024 at 5:19?PM Binyamin Dissen <
:>>> 0662573e2c3a-dmarc-requ...@listserv.ua.edu> wrote:
:>>>
:>>>> Took a dump of the address space, and the associated userid has 
UID(0)

:>>>>
:>>>> What else would be required for root access?
:>>>>
:>>>> On Mon, 17 Jun 2024 06:29:01 +1000 Attila Fogarasi
:>>>> <05b6fee9abb7-dmarc-requ...@listserv.ua.edu> wrote:
:>>>>
:>>>> :>port 722 is a privileged port, usually means your program 
needs root

:>>>> :>access, all of that is configured outside of RACF.
:>>>> :>
:>>>> :>On Mon, Jun 17, 2024 at 6:16?AM Binyamin Dissen <
:>>>> :>0662573e2c3a-dmarc-requ...@listserv.ua.edu> wrote:
:>>>> :>
:>>>> :>> On Sun, 16 Jun 2024 09:47:20 -0500 Walt Farrell
:>>>> :>> <05bd6dbb44aa-dmarc-requ...@listserv.ua.edu> wrote:
:>>>> :>>
:>>>> :>> :>On Sun, 16 Jun 2024 17:20:34 +0300, Binyamin Dissen <
:>>>> :>> bdis...@dissensoftware.com> wrote:
:>>>> :>>
:>>>> :>> :>>Getting
:>>>> :>>
:>>>> :>> :>>BPXF024I (TCPIP) Jun 16 06:38:15 inetd 65583 : FOMN0091
:>>>> *:otelnet/tcp:
:>>>> :>> :>>722 bind: EDC5111I Permission denied., rsn=744C7246
:>>>> :>>
:>>>> :>> :>>Not sure where it got 722 - looked in all the /etc places.
:>>>> :>>
:>>>> :>> :>>Also, what permission would be required to all;ow access 
to 722?

:>>>> Don't
:>>>> :>> seer
:>>>> :>> :>>anything obvious.
:>>>> :>>
:>>>> :>> :>What evidence do you have that it's a RACF issue?
:>>>> :>>
:>>>> :>> I am guessing from "permission denied"
:>>>>
:>>>> --
:>>>> 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

:>>>>
:>>>
:>>
:>> 
--

:>> 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

--
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




--
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 permission to INETD OTELNET port?

[Tom Brennan]

Well that destroys my theory that the problem was caused by a non-root 
id :)  Like you say, there must be something else involved.  Sounds like 
you're making progress though.


Just curious, what made you choose port 323?

On 6/17/2024 9:26 AM, Binyamin Dissen wrote:

Changed it to 323 and it works.

I cannot figure out which BPX* resource would control this (23) and how.

On Mon, 17 Jun 2024 06:01:03 -0700 Tom Brennan 
wrote:

:>I'm not sure if Attila was saying to try this, but if you can change the
:>port to something higher than 1024 and the bind works, that would
:>indicate you're not really root at the time of the bind.  Then if the
:>userid starting the task is root, maybe somebody is doing a setuid() or
:>similar before the bind.
:>
:>On 6/17/2024 1:26 AM, Attila Fogarasi wrote:
:>> Is INETD configured correctly?  Your config is in  etc/inetd/conf*. *TELNET
:>> is delivered specifying an ID of OMVSKERN and must be defined with both
:>> superuser and daemon authority.  Guessing you are using OMVSKERN based on
:>> uid(0).  Your port 722 is presumably defined in the /etc/services file
:>>
:>> On Mon, Jun 17, 2024 at 6:10?PM Attila Fogarasi  wrote:
:>>
:>>> Brave man running uid(0) for other than the OMVS kernel ... usually uid(0)
:>>> does give superuser authority, but you may need to be in group(SYS1) and
:>>> have a GID.  Another possibility is having root as HOME('/').  good luck,
:>>> its frustrating that simply things like getting a reason code for
:>>> "permission denied" is not so easy.
:>>>
:>>> On Mon, Jun 17, 2024 at 5:19?PM Binyamin Dissen <
:>>> 0662573e2c3a-dmarc-requ...@listserv.ua.edu> wrote:
:>>>
:>>>> Took a dump of the address space, and the associated userid has UID(0)
:>>>>
:>>>> What else would be required for root access?
:>>>>
:>>>> On Mon, 17 Jun 2024 06:29:01 +1000 Attila Fogarasi
:>>>> <05b6fee9abb7-dmarc-requ...@listserv.ua.edu> wrote:
:>>>>
:>>>> :>port 722 is a privileged port, usually means your program needs root
:>>>> :>access, all of that is configured outside of RACF.
:>>>> :>
:>>>> :>On Mon, Jun 17, 2024 at 6:16?AM Binyamin Dissen <
:>>>> :>0662573e2c3a-dmarc-requ...@listserv.ua.edu> wrote:
:>>>> :>
:>>>> :>> On Sun, 16 Jun 2024 09:47:20 -0500 Walt Farrell
:>>>> :>> <05bd6dbb44aa-dmarc-requ...@listserv.ua.edu> wrote:
:>>>> :>>
:>>>> :>> :>On Sun, 16 Jun 2024 17:20:34 +0300, Binyamin Dissen <
:>>>> :>> bdis...@dissensoftware.com> wrote:
:>>>> :>>
:>>>> :>> :>>Getting
:>>>> :>>
:>>>> :>> :>>BPXF024I (TCPIP) Jun 16 06:38:15 inetd 65583 : FOMN0091
:>>>> *:otelnet/tcp:
:>>>> :>> :>>722 bind: EDC5111I Permission denied., rsn=744C7246
:>>>> :>>
:>>>> :>> :>>Not sure where it got 722 - looked in all the /etc places.
:>>>> :>>
:>>>> :>> :>>Also, what permission would be required to all;ow access to 722?
:>>>> Don't
:>>>> :>> seer
:>>>> :>> :>>anything obvious.
:>>>> :>>
:>>>> :>> :>What evidence do you have that it's a RACF issue?
:>>>> :>>
:>>>> :>> I am guessing from "permission denied"
:>>>>
:>>>> --
:>>>> 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
:>>>>
:>>>
:>>
:>> --
:>> 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

--
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




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

Re: RACF permission to INETD OTELNET port?

[Binyamin Dissen]

Changed it to 323 and it works.

I cannot figure out which BPX* resource would control this (23) and how.

On Mon, 17 Jun 2024 06:01:03 -0700 Tom Brennan 
wrote:

:>I'm not sure if Attila was saying to try this, but if you can change the 
:>port to something higher than 1024 and the bind works, that would 
:>indicate you're not really root at the time of the bind.  Then if the 
:>userid starting the task is root, maybe somebody is doing a setuid() or 
:>similar before the bind.
:>
:>On 6/17/2024 1:26 AM, Attila Fogarasi wrote:
:>> Is INETD configured correctly?  Your config is in  etc/inetd/conf*. *TELNET
:>> is delivered specifying an ID of OMVSKERN and must be defined with both
:>> superuser and daemon authority.  Guessing you are using OMVSKERN based on
:>> uid(0).  Your port 722 is presumably defined in the /etc/services file
:>> 
:>> On Mon, Jun 17, 2024 at 6:10?PM Attila Fogarasi  wrote:
:>> 
:>>> Brave man running uid(0) for other than the OMVS kernel ... usually uid(0)
:>>> does give superuser authority, but you may need to be in group(SYS1) and
:>>> have a GID.  Another possibility is having root as HOME('/').  good luck,
:>>> its frustrating that simply things like getting a reason code for
:>>> "permission denied" is not so easy.
:>>>
:>>> On Mon, Jun 17, 2024 at 5:19?PM Binyamin Dissen <
:>>> 0662573e2c3a-dmarc-requ...@listserv.ua.edu> wrote:
:>>>
:>>>> Took a dump of the address space, and the associated userid has UID(0)
:>>>>
:>>>> What else would be required for root access?
:>>>>
:>>>> On Mon, 17 Jun 2024 06:29:01 +1000 Attila Fogarasi
:>>>> <05b6fee9abb7-dmarc-requ...@listserv.ua.edu> wrote:
:>>>>
:>>>> :>port 722 is a privileged port, usually means your program needs root
:>>>> :>access, all of that is configured outside of RACF.
:>>>> :>
:>>>> :>On Mon, Jun 17, 2024 at 6:16?AM Binyamin Dissen <
:>>>> :>0662573e2c3a-dmarc-requ...@listserv.ua.edu> wrote:
:>>>> :>
:>>>> :>> On Sun, 16 Jun 2024 09:47:20 -0500 Walt Farrell
:>>>> :>> <05bd6dbb44aa-dmarc-requ...@listserv.ua.edu> wrote:
:>>>> :>>
:>>>> :>> :>On Sun, 16 Jun 2024 17:20:34 +0300, Binyamin Dissen <
:>>>> :>> bdis...@dissensoftware.com> wrote:
:>>>> :>>
:>>>> :>> :>>Getting
:>>>> :>>
:>>>> :>> :>>BPXF024I (TCPIP) Jun 16 06:38:15 inetd 65583 : FOMN0091
:>>>> *:otelnet/tcp:
:>>>> :>> :>>722 bind: EDC5111I Permission denied., rsn=744C7246
:>>>> :>>
:>>>> :>> :>>Not sure where it got 722 - looked in all the /etc places.
:>>>> :>>
:>>>> :>> :>>Also, what permission would be required to all;ow access to 722?
:>>>> Don't
:>>>> :>> seer
:>>>> :>> :>>anything obvious.
:>>>> :>>
:>>>> :>> :>What evidence do you have that it's a RACF issue?
:>>>> :>>
:>>>> :>> I am guessing from "permission denied"
:>>>>
:>>>> --
:>>>> 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
:>>>>
:>>>
:>> 
:>> --
:>> 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

--
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 permission to INETD OTELNET port?

[Tom Brennan]

I'm not sure if Attila was saying to try this, but if you can change the 
port to something higher than 1024 and the bind works, that would 
indicate you're not really root at the time of the bind.  Then if the 
userid starting the task is root, maybe somebody is doing a setuid() or 
similar before the bind.


On 6/17/2024 1:26 AM, Attila Fogarasi wrote:

Is INETD configured correctly?  Your config is in  etc/inetd/conf*. *TELNET
is delivered specifying an ID of OMVSKERN and must be defined with both
superuser and daemon authority.  Guessing you are using OMVSKERN based on
uid(0).  Your port 722 is presumably defined in the /etc/services file

On Mon, Jun 17, 2024 at 6:10 PM Attila Fogarasi  wrote:


Brave man running uid(0) for other than the OMVS kernel ... usually uid(0)
does give superuser authority, but you may need to be in group(SYS1) and
have a GID.  Another possibility is having root as HOME('/').  good luck,
its frustrating that simply things like getting a reason code for
"permission denied" is not so easy.

On Mon, Jun 17, 2024 at 5:19 PM Binyamin Dissen <
0662573e2c3a-dmarc-requ...@listserv.ua.edu> wrote:


Took a dump of the address space, and the associated userid has UID(0)

What else would be required for root access?

On Mon, 17 Jun 2024 06:29:01 +1000 Attila Fogarasi
<05b6fee9abb7-dmarc-requ...@listserv.ua.edu> wrote:

:>port 722 is a privileged port, usually means your program needs root
:>access, all of that is configured outside of RACF.
:>
:>On Mon, Jun 17, 2024 at 6:16?AM Binyamin Dissen <
:>0662573e2c3a-dmarc-requ...@listserv.ua.edu> wrote:
:>
:>> On Sun, 16 Jun 2024 09:47:20 -0500 Walt Farrell
:>> <05bd6dbb44aa-dmarc-requ...@listserv.ua.edu> wrote:
:>>
:>> :>On Sun, 16 Jun 2024 17:20:34 +0300, Binyamin Dissen <
:>> bdis...@dissensoftware.com> wrote:
:>>
:>> :>>Getting
:>>
:>> :>>BPXF024I (TCPIP) Jun 16 06:38:15 inetd 65583 : FOMN0091
*:otelnet/tcp:
:>> :>>722 bind: EDC5111I Permission denied., rsn=744C7246
:>>
:>> :>>Not sure where it got 722 - looked in all the /etc places.
:>>
:>> :>>Also, what permission would be required to all;ow access to 722?
Don't
:>> seer
:>> :>>anything obvious.
:>>
:>> :>What evidence do you have that it's a RACF issue?
:>>
:>> I am guessing from "permission denied"

--
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





--
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 permission to INETD OTELNET port?

[Attila Fogarasi]

Is INETD configured correctly?  Your config is in  etc/inetd/conf*. *TELNET
is delivered specifying an ID of OMVSKERN and must be defined with both
superuser and daemon authority.  Guessing you are using OMVSKERN based on
uid(0).  Your port 722 is presumably defined in the /etc/services file

On Mon, Jun 17, 2024 at 6:10 PM Attila Fogarasi  wrote:

> Brave man running uid(0) for other than the OMVS kernel ... usually uid(0)
> does give superuser authority, but you may need to be in group(SYS1) and
> have a GID.  Another possibility is having root as HOME('/').  good luck,
> its frustrating that simply things like getting a reason code for
> "permission denied" is not so easy.
>
> On Mon, Jun 17, 2024 at 5:19 PM Binyamin Dissen <
> 0662573e2c3a-dmarc-requ...@listserv.ua.edu> wrote:
>
>> Took a dump of the address space, and the associated userid has UID(0)
>>
>> What else would be required for root access?
>>
>> On Mon, 17 Jun 2024 06:29:01 +1000 Attila Fogarasi
>> <05b6fee9abb7-dmarc-requ...@listserv.ua.edu> wrote:
>>
>> :>port 722 is a privileged port, usually means your program needs root
>> :>access, all of that is configured outside of RACF.
>> :>
>> :>On Mon, Jun 17, 2024 at 6:16?AM Binyamin Dissen <
>> :>0662573e2c3a-dmarc-requ...@listserv.ua.edu> wrote:
>> :>
>> :>> On Sun, 16 Jun 2024 09:47:20 -0500 Walt Farrell
>> :>> <05bd6dbb44aa-dmarc-requ...@listserv.ua.edu> wrote:
>> :>>
>> :>> :>On Sun, 16 Jun 2024 17:20:34 +0300, Binyamin Dissen <
>> :>> bdis...@dissensoftware.com> wrote:
>> :>>
>> :>> :>>Getting
>> :>>
>> :>> :>>BPXF024I (TCPIP) Jun 16 06:38:15 inetd 65583 : FOMN0091
>> *:otelnet/tcp:
>> :>> :>>722 bind: EDC5111I Permission denied., rsn=744C7246
>> :>>
>> :>> :>>Not sure where it got 722 - looked in all the /etc places.
>> :>>
>> :>> :>>Also, what permission would be required to all;ow access to 722?
>> Don't
>> :>> seer
>> :>> :>>anything obvious.
>> :>>
>> :>> :>What evidence do you have that it's a RACF issue?
>> :>>
>> :>> I am guessing from "permission denied"
>>
>> --
>> 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
>>
>

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

Re: RACF permission to INETD OTELNET port?

[Attila Fogarasi]

Brave man running uid(0) for other than the OMVS kernel ... usually uid(0)
does give superuser authority, but you may need to be in group(SYS1) and
have a GID.  Another possibility is having root as HOME('/').  good luck,
its frustrating that simply things like getting a reason code for
"permission denied" is not so easy.

On Mon, Jun 17, 2024 at 5:19 PM Binyamin Dissen <
0662573e2c3a-dmarc-requ...@listserv.ua.edu> wrote:

> Took a dump of the address space, and the associated userid has UID(0)
>
> What else would be required for root access?
>
> On Mon, 17 Jun 2024 06:29:01 +1000 Attila Fogarasi
> <05b6fee9abb7-dmarc-requ...@listserv.ua.edu> wrote:
>
> :>port 722 is a privileged port, usually means your program needs root
> :>access, all of that is configured outside of RACF.
> :>
> :>On Mon, Jun 17, 2024 at 6:16?AM Binyamin Dissen <
> :>0662573e2c3a-dmarc-requ...@listserv.ua.edu> wrote:
> :>
> :>> On Sun, 16 Jun 2024 09:47:20 -0500 Walt Farrell
> :>> <05bd6dbb44aa-dmarc-requ...@listserv.ua.edu> wrote:
> :>>
> :>> :>On Sun, 16 Jun 2024 17:20:34 +0300, Binyamin Dissen <
> :>> bdis...@dissensoftware.com> wrote:
> :>>
> :>> :>>Getting
> :>>
> :>> :>>BPXF024I (TCPIP) Jun 16 06:38:15 inetd 65583 : FOMN0091
> *:otelnet/tcp:
> :>> :>>722 bind: EDC5111I Permission denied., rsn=744C7246
> :>>
> :>> :>>Not sure where it got 722 - looked in all the /etc places.
> :>>
> :>> :>>Also, what permission would be required to all;ow access to 722?
> Don't
> :>> seer
> :>> :>>anything obvious.
> :>>
> :>> :>What evidence do you have that it's a RACF issue?
> :>>
> :>> I am guessing from "permission denied"
>
> --
> 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
>

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

Re: RACF permission to INETD OTELNET port?

[Binyamin Dissen]

Took a dump of the address space, and the associated userid has UID(0)

What else would be required for root access?

On Mon, 17 Jun 2024 06:29:01 +1000 Attila Fogarasi
<05b6fee9abb7-dmarc-requ...@listserv.ua.edu> wrote:

:>port 722 is a privileged port, usually means your program needs root
:>access, all of that is configured outside of RACF.
:>
:>On Mon, Jun 17, 2024 at 6:16?AM Binyamin Dissen <
:>0662573e2c3a-dmarc-requ...@listserv.ua.edu> wrote:
:>
:>> On Sun, 16 Jun 2024 09:47:20 -0500 Walt Farrell
:>> <05bd6dbb44aa-dmarc-requ...@listserv.ua.edu> wrote:
:>>
:>> :>On Sun, 16 Jun 2024 17:20:34 +0300, Binyamin Dissen <
:>> bdis...@dissensoftware.com> wrote:
:>>
:>> :>>Getting
:>>
:>> :>>BPXF024I (TCPIP) Jun 16 06:38:15 inetd 65583 : FOMN0091 *:otelnet/tcp:
:>> :>>722 bind: EDC5111I Permission denied., rsn=744C7246
:>>
:>> :>>Not sure where it got 722 - looked in all the /etc places.
:>>
:>> :>>Also, what permission would be required to all;ow access to 722? Don't
:>> seer
:>> :>>anything obvious.
:>>
:>> :>What evidence do you have that it's a RACF issue?
:>>
:>> I am guessing from "permission denied"

--
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 permission to INETD OTELNET port?

[Attila Fogarasi]

port 722 is a privileged port, usually means your program needs root
access, all of that is configured outside of RACF.

On Mon, Jun 17, 2024 at 6:16 AM Binyamin Dissen <
0662573e2c3a-dmarc-requ...@listserv.ua.edu> wrote:

> On Sun, 16 Jun 2024 09:47:20 -0500 Walt Farrell
> <05bd6dbb44aa-dmarc-requ...@listserv.ua.edu> wrote:
>
> :>On Sun, 16 Jun 2024 17:20:34 +0300, Binyamin Dissen <
> bdis...@dissensoftware.com> wrote:
>
> :>>Getting
>
> :>>BPXF024I (TCPIP) Jun 16 06:38:15 inetd 65583 : FOMN0091 *:otelnet/tcp:
> :>>722 bind: EDC5111I Permission denied., rsn=744C7246
>
> :>>Not sure where it got 722 - looked in all the /etc places.
>
> :>>Also, what permission would be required to all;ow access to 722? Don't
> seer
> :>>anything obvious.
>
> :>What evidence do you have that it's a RACF issue?
>
> I am guessing from "permission denied"
>
> --
> 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
>

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

Re: RACF permission to INETD OTELNET port?

[Binyamin Dissen]

On Sun, 16 Jun 2024 09:47:20 -0500 Walt Farrell
<05bd6dbb44aa-dmarc-requ...@listserv.ua.edu> wrote:

:>On Sun, 16 Jun 2024 17:20:34 +0300, Binyamin Dissen 
 wrote:

:>>Getting

:>>BPXF024I (TCPIP) Jun 16 06:38:15 inetd 65583 : FOMN0091 *:otelnet/tcp:
:>>722 bind: EDC5111I Permission denied., rsn=744C7246

:>>Not sure where it got 722 - looked in all the /etc places.

:>>Also, what permission would be required to all;ow access to 722? Don't seer
:>>anything obvious.

:>What evidence do you have that it's a RACF issue?

I am guessing from "permission denied"

--
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 permission to INETD OTELNET port?

[Walt Farrell]

On Sun, 16 Jun 2024 17:20:34 +0300, Binyamin Dissen 
 wrote:

>Getting
>
>BPXF024I (TCPIP) Jun 16 06:38:15 inetd 65583 : FOMN0091 *:otelnet/tcp:
>722 bind: EDC5111I Permission denied., rsn=744C7246
>
>Not sure where it got 722 - looked in all the /etc places.
>
>Also, what permission would be required to all;ow access to 722? Don't seer
>anything obvious.

What evidence do you have that it's a RACF issue?

-- 
Walt

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

RACF permission to INETD OTELNET port?

[Binyamin Dissen]

Getting

BPXF024I (TCPIP) Jun 16 06:38:15 inetd 65583 : FOMN0091 *:otelnet/tcp:
722 bind: EDC5111I Permission denied., rsn=744C7246  

Not sure where it got 722 - looked in all the /etc places.

Also, what permission would be required to all;ow access to 722? Don't seer
anything obvious.

--
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 - 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 JES

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.

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.

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 

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.  *** Ce

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 10

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

RACF/DB2 Search Question?

[Shaffer, Terri]

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



 [https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] 
<http://www.aciworldwide.com>
This email message and any attachments may contain confidential, proprietary or 
non-public information. The information is intended solely for the designated 
recipient(s). If an addressing or transmission error has misdirected this 
email, please notify the sender immediately and destroy this email. Any review, 
dissemination, use or reliance upon this information by unintended recipients 
is prohibited. Any opinions expressed in this email are those of the author 
personally.

--
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<https://www.mail-archive.com/search?l=ibm-main@listserv.ua.edu&q=from:%22Michael+Brennan%22>
 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

RACF, external password management

[Timothy Sipples]

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

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

RACF, external password management

[Linda Hagedorn]

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: How can I determine the User Name associated with the current Batch JOB RACF ID?

[Jon Perryman]

On Wed, 31 Jan 2024 13:36:56 -0600, Charles Mills  wrote:

> the ACEEUNAM seems to be a supported programming interface and should be safe.

All documented control blocks have a supported (or unsupported) programming 
interface section. ACEEUNAM is not excluded in the ACEE so the assumption is 
that it is supported.

https://www.ibm.com/docs/en/zos/2.4.0?topic=areas-acee-accessor-environment-element#d82132e41

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

Re: How can I determine the User Name associated with the current Batch JOB RACF ID?

[Charles Mills]

De nada.

The bottom line would appear to be that if you want the user name, then control 
block chasing to the ACEE and picking up the ACEEUNAM seems to be a supported 
programming interface and should be safe.

Be aware of all of the potential issues of multiple ACEEs, no ACEE, etc. But 
for @Cameron's sort of situation -- "I have a batch COBOL program that runs 
every night and it wants to know the name of the user that owns the job" then 
control block chasing to ACEEUNAM should be fine.

Charles

On Wed, 31 Jan 2024 13:06:06 +, Peter Relson  wrote:

>I had written
>
>At least in the past (I don't know if still true), there are cases where the 
>ACEE might be what, very loosely, is referred to as encrypted in which case it 
>would not be readable as-is. It's not truly encrypted such that you need some 
>cryptography to decrypt it, but the intent is that the security product know 
>what to do to provide you the "decrypted" info
>
>
>Charles M helped me realize that I was mis-thinking. It's the utoken that can 
>be "encrypted", not the ACEE.
>Thanks, Charles.
>
>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

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

Re: How can I determine the User Name associated with the current Batch JOB RACF ID?

[Peter Relson]

I had written

At least in the past (I don't know if still true), there are cases where the 
ACEE might be what, very loosely, is referred to as encrypted in which case it 
would not be readable as-is. It's not truly encrypted such that you need some 
cryptography to decrypt it, but the intent is that the security product know 
what to do to provide you the "decrypted" info


Charles M helped me realize that I was mis-thinking. It's the utoken that can 
be "encrypted", not the ACEE.
Thanks, Charles.

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: How can I determine the User Name associated with the current Batch JOB RACF ID?

[Steve Thompson]

Great point.

CICS is a good example.

Connect:Direct is another.

On 1/30/2024 3:21 PM, Jon Perryman wrote:


You can get it from ACEEUNAM.


The intended interface is likely one of the RACROUTE variants (EXTRACT?).

Also keep in mind multi-user address spaces and that you are referencing the 
correct ACEE. MUSAS can occur in unexpected places. E.g. Just because your TSO 
address space is single user does not mean embedded TSO in my products address 
space is single user.

--
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: How can I determine the User Name associated with the current Batch JOB RACF ID?

[Jon Perryman]

>
>You can get it from ACEEUNAM.
>
>
>The intended interface is likely one of the RACROUTE variants (EXTRACT?).

Also keep in mind multi-user address spaces and that you are referencing the 
correct ACEE. MUSAS can occur in unexpected places. E.g. Just because your TSO 
address space is single user does not mean embedded TSO in my products address 
space is single user.

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

Re: How can I determine the User Name associated with the current Batch JOB RACF ID?

[Peter Relson]

You can get it from ACEEUNAM.


The intended interface is likely one of the RACROUTE variants (EXTRACT?).

At least in the past (I don't know if still true), there are cases where the 
ACEE might be what, very loosely, is referred to as encrypted in which case it 
would not be readable as-is. It's not truly encrypted such that you need some 
cryptography to decrypt it, but the intent is that the security product know 
what to do to provide you the "decrypted" info

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

Sv: How can I determine the User Name associated with the current Batch JOB RACF ID?

[Lars Höglund]

Or check out

COB2JOB from https://gsf-soft.com/Freeware/

//Lasse

-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List  För David Spiegel
Skickat: den 30 januari 2024 03:56
Till: IBM-MAIN@LISTSERV.UA.EDU
Ämne: Re: How can I determine the User Name associated with the current Batch 
JOB RACF ID?

Hi Cameron,
Can you please send me the source of your working program?
My email address is da...@ddstar.com

Thanks and regards,
David

On 2024-01-29 16:49, Cameron Conacher wrote:
> Thanks everyone,
> This is just what I needed.
>
> Appreciate the help.
>
>
> Thanks
>
> …….Cameron
>
> From: IBM Mainframe Discussion List  On 
> Behalf Of Lars Höglund
> Sent: Monday, January 29, 2024 11:10 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Sv: How can I determine the User Name associated with the current 
> Batch JOB RACF ID?
>
> Something like this Code Extract: LINKAGE SECTION. 01 CB1. 05 PTR1 
> POINTER OCCURS 512. 01 CVT. 05 CVT1 POINTER OCCURS 512. 01 CB2. 05 
> PTR2 POINTER OCCURS 256. . . . SET ADDRESS OF CB2 TO PTR1(4) MOVE 
> CB2(1: 8) TO WS-BJOBNAMN SET ADDRESS OF CB2
>
>
> Something like this
>
>
>
> Code Extract:
>
>
>
> LINKAGE SECTION.
>
>
>
> 01 CB1.
>
>05 PTR1 POINTER OCCURS 512.
>
> 01 CVT.
>
>05 CVT1 POINTER OCCURS 512.
>
> 01 CB2.
>
>05 PTR2 POINTER OCCURS 256.
>
> .
>
> .
>
> .
>
> SET ADDRESS OF CB2  TO PTR1(4)
>
> MOVE CB2(1:8)TO WS-BJOBNAMN
>
> SET ADDRESS OF CB2  TO PTR1(46)
>
> MOVE CB2(361:8)  TO WS-BPGM
>
> SET ADDRESS OF CB2  TO PTR2(80)
>
> MOVE CB2(13:8) TO  BJOBNR
>
> SET ADDRESS OF CB1  TO NULL
>
> SET ADDRESS OF CB1  TO PTR1(138)
>
> SET ADDRESS OF CB2  TO PTR1(28)
>
> MOVE CB2(193:8) TO WS-BUSER
>
>
>
>
>
>
>
> -Ursprungligt meddelande-
>
> Från: IBM Mainframe Discussion List 
> mailto:IBM-MAIN@LISTSERV.UA.EDU>> För 
> Cameron Conacher
>
> Skickat: den 29 januari 2024 14:37
>
> Till: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>
>
> Ämne: How can I determine the User Name associated with the current Batch JOB 
> RACF ID?
>
>
>
> [Du f?r inte e-post ofta fr?n 
> 03cfc59146bb-dmarc-requ...@listserv.ua.edu<mailto:03cfc59146bb
> -dmarc-requ...@listserv.ua.edu>. L?s om varf?r det h?r ?r viktigt p? 
> https://aka.ms/LearnAboutSenderIdentification<https://isolate.menlosec
> urity.com/1/3735928037/https:/aka.ms/LearnAboutSenderIdentification> ]
>
>
>
> Good Morning,
>
> I know I can do this in CICS, but I am digging around to see if this can be 
> done in a batch COBOL program.
>
> Basically, I just want to include Fred's Name in a report I generate, where 
> Fred is the RACF ID associate with the currently executing Batch JOB. (a 
> COBOL program).
>
> I could write something to call out to CICS (EXCI maybe) to get a name.
>
> But I wanted to know if there is anyway to do this by calling some routines 
> from my Batch COBOL program.
>
>
>
> I am assuming right now, it is not possible since I have come up empty so far.
>
>
>
> Thanks
>
>
>
>
>
> Cameron Conacher
>
> Senior Engineer
>
>
>
> American Express Canada Inc.
>
> GCICS
>
> 2225 Sheppard Avenue East, Toronto, ON  M2J 5C2
>
>
>
> cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com><mailto:Cam
> eron.conac...@aexp.com<mailto:cameron.conac...@aexp.com>>
>
> Office: 1-437-836-5265
>
> Mobile: 1-416-409-5147
>
>
>
> https://amex.webex.com/join/cameron.conacher
>
>
>
>
>
>
>
> 
>
> American Express made the following annotations 
>  This e-mail was sent to you by a 
> representative of Amex Bank of Canada, P.O. Box 3204, Station "F", Toronto, 
> ON, M1W 3W7, 
> http://www.americanexpress.ca/<https://isolate.menlosecurity.com/1/3735928037/http:/www.americanexpress.ca>.
>  If you no longer wish to receive these e-mails, please notify the sender by 
> reply e-mail.
>
>
>
> This e-mail is solely for the intended recipient and may contain confidential 
> or privileged information. If you are not the intended recipient, any 
> disclosure, copying, use, or distribution of the information included in this 
> e-mail is prohibited. If you have received this e-mail in error, please 
> notify the sender by reply e-mail and immediately and permanently delete this 
> e-mail and any attachments. Thank you.
>
>
>
> Amer

Re: How can I determine the User Name associated with the current Batch JOB RACF ID?

[David Spiegel]

Hi Cameron,
Can you please send me the source of your working program?
My email address is da...@ddstar.com

Thanks and regards,
David

On 2024-01-29 16:49, Cameron Conacher wrote:

Thanks everyone,
This is just what I needed.

Appreciate the help.


Thanks

…….Cameron

From: IBM Mainframe Discussion List  On Behalf Of 
Lars Höglund
Sent: Monday, January 29, 2024 11:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Sv: How can I determine the User Name associated with the current 
Batch JOB RACF ID?

Something like this Code Extract: LINKAGE SECTION. 01 CB1. 05 PTR1 POINTER 
OCCURS 512. 01 CVT. 05 CVT1 POINTER OCCURS 512. 01 CB2. 05 PTR2 POINTER OCCURS 
256. . . . SET ADDRESS OF CB2 TO PTR1(4) MOVE CB2(1: 8) TO WS-BJOBNAMN SET 
ADDRESS OF CB2


Something like this



Code Extract:



LINKAGE SECTION.



01 CB1.

   05 PTR1 POINTER OCCURS 512.

01 CVT.

   05 CVT1 POINTER OCCURS 512.

01 CB2.

   05 PTR2 POINTER OCCURS 256.

.

.

.

SET ADDRESS OF CB2  TO PTR1(4)

MOVE CB2(1:8)TO WS-BJOBNAMN

SET ADDRESS OF CB2  TO PTR1(46)

MOVE CB2(361:8)  TO WS-BPGM

SET ADDRESS OF CB2  TO PTR2(80)

MOVE CB2(13:8) TO  BJOBNR

SET ADDRESS OF CB1  TO NULL

SET ADDRESS OF CB1  TO PTR1(138)

SET ADDRESS OF CB2  TO PTR1(28)

MOVE CB2(193:8) TO WS-BUSER







-Ursprungligt meddelande-

Från: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> För Cameron Conacher

Skickat: den 29 januari 2024 14:37

Till: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>

Ämne: How can I determine the User Name associated with the current Batch JOB 
RACF ID?



[Du f?r inte e-post ofta fr?n 
03cfc59146bb-dmarc-requ...@listserv.ua.edu<mailto:03cfc59146bb-dmarc-requ...@listserv.ua.edu>.
 L?s om varf?r det h?r ?r viktigt p? 
https://aka.ms/LearnAboutSenderIdentification<https://isolate.menlosecurity.com/1/3735928037/https:/aka.ms/LearnAboutSenderIdentification>
 ]



Good Morning,

I know I can do this in CICS, but I am digging around to see if this can be 
done in a batch COBOL program.

Basically, I just want to include Fred's Name in a report I generate, where 
Fred is the RACF ID associate with the currently executing Batch JOB. (a COBOL 
program).

I could write something to call out to CICS (EXCI maybe) to get a name.

But I wanted to know if there is anyway to do this by calling some routines 
from my Batch COBOL program.



I am assuming right now, it is not possible since I have come up empty so far.



Thanks





Cameron Conacher

Senior Engineer



American Express Canada Inc.

GCICS

2225 Sheppard Avenue East, Toronto, ON  M2J 5C2



cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com><mailto:cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com>>

Office: 1-437-836-5265

Mobile: 1-416-409-5147



https://amex.webex.com/join/cameron.conacher









American Express made the following annotations  This e-mail 
was sent to you by a representative of Amex Bank of Canada, P.O. Box 3204, Station 
"F", Toronto, ON, M1W 3W7, 
http://www.americanexpress.ca/<https://isolate.menlosecurity.com/1/3735928037/http:/www.americanexpress.ca>.
 If you no longer wish to receive these e-mails, please notify the sender by reply e-mail.



This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.



American Express a fait les remarques suivantes Ce courriel vous a ?t? envoy? par un 
repr?sentant de la Banque Amex du Canada, C.P. 3204, succursale F, Toronto (Ontario) 
M1W 3W7, 
http://www.americanexpress.ca/<https://isolate.menlosecurity.com/1/3735928037/http:/www.americanexpress.ca>.
 Si, par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les exp?diteurs par courriel.



Ce courriel est r?serv? au seul destinataire indiqu? et peut renfermer des 
renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire 
pr?vu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez re?u ce courriel par erreur, veuillez en aviser 
l'exp?diteur par courriel et d?truire imm?diatement le courriel et toute pi?ce 
jointe. Merci.



--

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



-

Re: How can I determine the User Name associated with the current Batch JOB RACF ID?

[Cameron Conacher]

Thanks very much.
I struggled at first, but finally got through.
This is perfect.!!

On Mon, Jan 29, 2024 at 9:31 AM Binyamin Dissen 
wrote:

> On Mon, 29 Jan 2024 13:36:51 + Cameron Conacher
> <03cfc59146bb-dmarc-requ...@listserv.ua.edu> wrote:
>
> :>Good Morning,
> :>I know I can do this in CICS, but I am digging around to see if this can
> be done in a batch COBOL program.
> :>Basically, I just want to include Fred's Name in a report I generate,
> where Fred is the RACF ID associate with the currently executing Batch JOB.
> (a COBOL program).
> :>I could write something to call out to CICS (EXCI maybe) to get a name.
> :>But I wanted to know if there is anyway to do this by calling some
> routines from my Batch COBOL program.
>
> :>I am assuming right now, it is not possible since I have come up empty
> so far.
>
> You can get it from ACEEUNAM.
>
> https://www.microfocus.co.jp/manuals/ED23/html/HCOMCMCBLKS005.html shows
> how
> to locate MVS control blocks from COBOL.
>
> --
> 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
>

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

Re: How can I determine the User Name associated with the current Batch JOB RACF ID?

[Cameron Conacher]

Thanks everyone,
This is just what I needed.

Appreciate the help.


Thanks

…….Cameron

From: IBM Mainframe Discussion List  On Behalf Of 
Lars Höglund
Sent: Monday, January 29, 2024 11:10 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Sv: How can I determine the User Name associated with the current 
Batch JOB RACF ID?

Something like this Code Extract: LINKAGE SECTION. 01 CB1. 05 PTR1 POINTER 
OCCURS 512. 01 CVT. 05 CVT1 POINTER OCCURS 512. 01 CB2. 05 PTR2 POINTER OCCURS 
256. . . . SET ADDRESS OF CB2 TO PTR1(4) MOVE CB2(1: 8) TO WS-BJOBNAMN SET 
ADDRESS OF CB2


Something like this



Code Extract:



LINKAGE SECTION.



01 CB1.

  05 PTR1 POINTER OCCURS 512.

01 CVT.

  05 CVT1 POINTER OCCURS 512.

01 CB2.

  05 PTR2 POINTER OCCURS 256.

.

.

.

SET ADDRESS OF CB2  TO PTR1(4)

MOVE CB2(1:8)TO WS-BJOBNAMN

SET ADDRESS OF CB2  TO PTR1(46)

MOVE CB2(361:8)  TO WS-BPGM

SET ADDRESS OF CB2  TO PTR2(80)

MOVE CB2(13:8) TO  BJOBNR

SET ADDRESS OF CB1  TO NULL

SET ADDRESS OF CB1  TO PTR1(138)

SET ADDRESS OF CB2  TO PTR1(28)

MOVE CB2(193:8) TO WS-BUSER







-Ursprungligt meddelande-

Från: IBM Mainframe Discussion List 
mailto:IBM-MAIN@LISTSERV.UA.EDU>> För Cameron Conacher

Skickat: den 29 januari 2024 14:37

Till: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU>

Ämne: How can I determine the User Name associated with the current Batch JOB 
RACF ID?



[Du f?r inte e-post ofta fr?n 
03cfc59146bb-dmarc-requ...@listserv.ua.edu<mailto:03cfc59146bb-dmarc-requ...@listserv.ua.edu>.
 L?s om varf?r det h?r ?r viktigt p? 
https://aka.ms/LearnAboutSenderIdentification<https://isolate.menlosecurity.com/1/3735928037/https:/aka.ms/LearnAboutSenderIdentification>
 ]



Good Morning,

I know I can do this in CICS, but I am digging around to see if this can be 
done in a batch COBOL program.

Basically, I just want to include Fred's Name in a report I generate, where 
Fred is the RACF ID associate with the currently executing Batch JOB. (a COBOL 
program).

I could write something to call out to CICS (EXCI maybe) to get a name.

But I wanted to know if there is anyway to do this by calling some routines 
from my Batch COBOL program.



I am assuming right now, it is not possible since I have come up empty so far.



Thanks





Cameron Conacher

Senior Engineer



American Express Canada Inc.

GCICS

2225 Sheppard Avenue East, Toronto, ON  M2J 5C2



cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com><mailto:cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com>>

Office: 1-437-836-5265

Mobile: 1-416-409-5147



https://amex.webex.com/join/cameron.conacher









American Express made the following annotations 
 This e-mail was sent to you by a 
representative of Amex Bank of Canada, P.O. Box 3204, Station "F", Toronto, ON, 
M1W 3W7, 
www.americanexpress.ca<https://isolate.menlosecurity.com/1/3735928037/http:/www.americanexpress.ca>.
 If you no longer wish to receive these e-mails, please notify the sender by 
reply e-mail.



This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.



American Express a fait les remarques suivantes Ce courriel vous a ?t? envoy? 
par un repr?sentant de la Banque Amex du Canada, C.P. 3204, succursale F, 
Toronto (Ontario) M1W 3W7, 
www.americanexpress.ca<https://isolate.menlosecurity.com/1/3735928037/http:/www.americanexpress.ca>.
 Si, par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en 
aviser les exp?diteurs par courriel.



Ce courriel est r?serv? au seul destinataire indiqu? et peut renfermer des 
renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire 
pr?vu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez re?u ce courriel par erreur, veuillez en aviser 
l'exp?diteur par courriel et d?truire imm?diatement le courriel et toute pi?ce 
jointe. Merci.



--

For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
lists...@listserv.ua.edu<mailto: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<mailto:lists...@listserv.ua.edu> with 
the message: INFO

Sv: How can I determine the User Name associated with the current Batch JOB RACF ID?

[Lars Höglund]

Something like this

Code Extract:

LINKAGE SECTION. 
 
01 CB1.  
  05 PTR1 POINTER OCCURS 512.
01 CVT.  
  05 CVT1 POINTER OCCURS 512.   
01 CB2.  
  05 PTR2 POINTER OCCURS 256.
.
.
.
SET ADDRESS OF CB2  TO PTR1(4)  
MOVE CB2(1:8)TO WS-BJOBNAMN
SET ADDRESS OF CB2  TO PTR1(46) 
MOVE CB2(361:8)  TO WS-BPGM
SET ADDRESS OF CB2  TO PTR2(80) 
MOVE CB2(13:8) TO  BJOBNR   
SET ADDRESS OF CB1  TO NULL 
SET ADDRESS OF CB1  TO PTR1(138)
SET ADDRESS OF CB2  TO PTR1(28) 
MOVE CB2(193:8) TO WS-BUSER 

 

-Ursprungligt meddelande-
Från: IBM Mainframe Discussion List  För Cameron 
Conacher
Skickat: den 29 januari 2024 14:37
Till: IBM-MAIN@LISTSERV.UA.EDU
Ämne: How can I determine the User Name associated with the current Batch JOB 
RACF ID?

[Du f?r inte e-post ofta fr?n 03cfc59146bb-dmarc-requ...@listserv.ua.edu. 
L?s om varf?r det h?r ?r viktigt p? 
https://aka.ms/LearnAboutSenderIdentification ]

Good Morning,
I know I can do this in CICS, but I am digging around to see if this can be 
done in a batch COBOL program.
Basically, I just want to include Fred's Name in a report I generate, where 
Fred is the RACF ID associate with the currently executing Batch JOB. (a COBOL 
program).
I could write something to call out to CICS (EXCI maybe) to get a name.
But I wanted to know if there is anyway to do this by calling some routines 
from my Batch COBOL program.

I am assuming right now, it is not possible since I have come up empty so far.

Thanks


Cameron Conacher
Senior Engineer

American Express Canada Inc.
GCICS
2225 Sheppard Avenue East, Toronto, ON  M2J 5C2

cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com>
Office: 1-437-836-5265
Mobile: 1-416-409-5147

https://amex.webex.com/join/cameron.conacher




American Express made the following annotations 
 This e-mail was sent to you by a 
representative of Amex Bank of Canada, P.O. Box 3204, Station "F", Toronto, ON, 
M1W 3W7, www.americanexpress.ca. If you no longer wish to receive these 
e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes Ce courriel vous a ?t? envoy? 
par un repr?sentant de la Banque Amex du Canada, C.P. 3204, succursale F, 
Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, par la suite, vous ne 
souhaitez plus recevoir ces courriels, veuillez en aviser les exp?diteurs par 
courriel.

Ce courriel est r?serv? au seul destinataire indiqu? et peut renfermer des 
renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire 
pr?vu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez re?u ce courriel par erreur, veuillez en aviser 
l'exp?diteur par courriel et d?truire imm?diatement le courriel et toute pi?ce 
jointe. Merci.

--
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: How can I determine the User Name associated with the current Batch JOB RACF ID?

[Binyamin Dissen]

On Mon, 29 Jan 2024 13:36:51 + Cameron Conacher
<03cfc59146bb-dmarc-requ...@listserv.ua.edu> wrote:

:>Good Morning,
:>I know I can do this in CICS, but I am digging around to see if this can be 
done in a batch COBOL program.
:>Basically, I just want to include Fred's Name in a report I generate, where 
Fred is the RACF ID associate with the currently executing Batch JOB. (a COBOL 
program).
:>I could write something to call out to CICS (EXCI maybe) to get a name.
:>But I wanted to know if there is anyway to do this by calling some routines 
from my Batch COBOL program.

:>I am assuming right now, it is not possible since I have come up empty so far.

You can get it from ACEEUNAM.

https://www.microfocus.co.jp/manuals/ED23/html/HCOMCMCBLKS005.html shows how
to locate MVS control blocks from COBOL.

--
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

How can I determine the User Name associated with the current Batch JOB RACF ID?

[Cameron Conacher]

Good Morning,
I know I can do this in CICS, but I am digging around to see if this can be 
done in a batch COBOL program.
Basically, I just want to include Fred's Name in a report I generate, where 
Fred is the RACF ID associate with the currently executing Batch JOB. (a COBOL 
program).
I could write something to call out to CICS (EXCI maybe) to get a name.
But I wanted to know if there is anyway to do this by calling some routines 
from my Batch COBOL program.

I am assuming right now, it is not possible since I have come up empty so far.

Thanks


Cameron Conacher
Senior Engineer

American Express Canada Inc.
GCICS
2225 Sheppard Avenue East, Toronto, ON  M2J 5C2

cameron.conac...@aexp.com<mailto:cameron.conac...@aexp.com>
Office: 1-437-836-5265
Mobile: 1-416-409-5147

https://amex.webex.com/join/cameron.conacher




American Express made the following annotations

This e-mail was sent to you by a representative of Amex Bank of Canada, P.O. 
Box 3204, Station "F", Toronto, ON, M1W 3W7, www.americanexpress.ca. If you no 
longer wish to receive these e-mails, please notify the sender by reply e-mail.

This e-mail is solely for the intended recipient and may contain confidential 
or privileged information. If you are not the intended recipient, any 
disclosure, copying, use, or distribution of the information included in this 
e-mail is prohibited. If you have received this e-mail in error, please notify 
the sender by reply e-mail and immediately and permanently delete this e-mail 
and any attachments. Thank you.

American Express a fait les remarques suivantes
Ce courriel vous a ?t? envoy? par un repr?sentant de la Banque Amex du Canada, 
C.P. 3204, succursale F, Toronto (Ontario) M1W 3W7, www.americanexpress.ca. Si, 
par la suite, vous ne souhaitez plus recevoir ces courriels, veuillez en aviser 
les exp?diteurs par courriel.

Ce courriel est r?serv? au seul destinataire indiqu? et peut renfermer des 
renseignements confidentiels et privil?gi?s. Si vous n'?tes pas le destinataire 
pr?vu, toute divulgation, duplication, utilisation ou distribution du courriel 
est interdite. Si vous avez re?u ce courriel par erreur, veuillez en aviser 
l'exp?diteur par courriel et d?truire imm?diatement le courriel et toute pi?ce 
jointe. Merci.

--
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

Macro to retrieve RACF CSDATA

[John Blythe Reid]

Hello,

I would like to retrieve the CSDATA stored in my RACF user profile. This is 
what I have:

USER=TSGJR
  
CSDATA INFORMATION
--
FULLNAME John Blythe Reid 
DATAFLD2 : ABCDEF

I'm looking at the macro RACROUTE REQUEST=EXTRACT,TYPE=EXTRACT to obtain the 
data in CSDATA DATAFLD2 for my user but I can't see how to do it.

Could anyone give me a hand with this please ?

Regards,
John.

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

RACF Automation (Cross Posted)

[Steve Beaver]

I have a customer that would like to AUTOMATE RACF.  Personally I think this
heresy but.

 

I am aware of Sail Point, and it will automate changing passwords.

 

Are there any tools/Program Products that can be used to Provision ID's, and


Update profiles without having the auditors looking for someone's scalp?

 

 

Regards,

 

 

Steve 

 


--
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

Racf Userid

[Chalk, Shelia]

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

Re: RACF and Encryption (Cross Posted

[Colin Paice]

I wrote One minute MVS – Using individual data set encryption on z/OS
<https://colinpaice.blog/2023/11/13/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

RACF and Encryption (Cross Posted

[Steve Beaver]

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

Re: Rexx to clone users in RACF

[Peter]

Thank you all

I have a panel based solution where I can just mention only one user and
one model user for cloning.

So I was thinking to improve the solution by running in a batch by pointing
to a PS file where I can populate all the panel details like USER NAME,
NAME and MODEL USER and create any number of users by running in a batch

Anyways let me do some research and come back to you

Peter.


On Fri, Nov 24, 2023, 7:14 PM Walt Farrell  wrote:

> On Tue, 21 Nov 2023 12:23:24 +0400, Peter  wrote:
>
> >Cloning  and creating one user is easy but
> >
> >I want to clone and create 10 userid at once .
> >
> >Is it possible to achieve it through DBSNC.?
>
> DBSYNC can give you the commands to create 1 user based on another one.
>
> Copy/Paste of those commands followed by a Find/Replace can give you a set
> of commands to create a second user.
>
> Repeat as needed.
>
> --
> Walt
>
> --
> 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: Rexx to clone users in RACF

[Walt Farrell]

On Tue, 21 Nov 2023 12:23:24 +0400, Peter  wrote:

>Cloning  and creating one user is easy but
>
>I want to clone and create 10 userid at once .
>
>Is it possible to achieve it through DBSNC.?

DBSYNC can give you the commands to create 1 user based on another one.

Copy/Paste of those commands followed by a Find/Replace can give you a set of 
commands to create a second user.

Repeat as needed.

-- 
Walt

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