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 <sipp...@sg.ibm.com> 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
