subject:"Re\: RACF, external password management"

Re: RACF, external password management

2024-04-09 Thread 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

2024-04-09 Thread 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

2024-04-09 Thread 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

2024-04-09 Thread 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, external password management

2024-03-04 Thread 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 +0000
> 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

2024-03-03 Thread 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

2024-03-03 Thread 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

2024-03-03 Thread 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

2024-03-01 Thread 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

2024-03-01 Thread 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

2024-03-01 Thread 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

2024-03-01 Thread 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

2024-03-01 Thread 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

2024-03-01 Thread 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