Re: RACF, external password management
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
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
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
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
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
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
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
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
Storage questions - mod9, mod27, mod54
Hi, I hope you won't mind a storage question. We're running zOS 2.4 and have a smattering of volume sizes - mod9, mod27, mod54. I'd like to have all mod54's for Db2 and be prepared before going to the storage folks. 1. Is storage virtual nowadays? 2. Can virtual mod9s and mod27s be reconfigured to mod54s? 3. Does the reconfiguration require an IPL? 4. Does the reconfiguration new addressing in IODF? 5. Is the storage vendor (IBM, EMC, etc.) relevant? Does the hardware determine or be a factor in merging the mod9s/mod27s, into mod54s? 6. Is it a given that the volumes must be cleared/emptied before the reconfiguration happens? 7. How long does reconfiguration take? Is there anything else I should consider before taking this request to the storage group? Any information or advice is appreciated. Thank you. Linda Hagedorn -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
WebSeal & CIS benchmarks for auditing
Hi. We will be auditing WebSeal in-house and are looking for the appropriate CIS benchmarks. Does anyone know the CIS benchmarks for WebSeal? Our searches have been unproductive. The CIS site is here: https://www.cisecurity.org/cis-benchmarks/ We searched for: . Webseal . Tivoli Access Manager . ISAM Reverse Proxy If I should be on a different forum, a referral or any information 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
Looking for a referral - unix, scripts, production, passwords
Hi, I need a referral about remediating AIX scripting that was written with passwords in clear text. These are maintenance scripts, batch jobs, etc. I have a inherited an AIX platform with scripts with passwords in clear text. They are now hashed, but that is insufficient and they need to be encrypted. My background is mainframe DB2, not AIX security protocols, so am asking IBM-main for assistance. In AIX, there are groups and users, and/or AD groups and users. How do I cause the scripts to read an encrypted password file instead of using the password in clear text or hashed? Are there special flags on AIX or AD groups to make id's non-logon, like RACF with no TSO profile? I'm investing in doing it right going forward. References and best practice advice is sincerely 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: Need referral - Websphere script w/o passwords
Thank you. I'll read up. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Need referral - Websphere script w/o passwords
This is regarding Websphere. I've inherited a WAS platform with scripts containing passwords in clear text. I have to remediate this, and came to ibm-main for advice. This is on AIX. I normally manage DB2 on Z, and just accepted the WAS area. Can anyone refer me to a manual, Redbook, or best practice for options? Encrypted pw file? System parm for NOPASSWORD? Any information or referral 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
OnDemand on DB2
Hi. I'm looking for help and ideas with OnDemand on DB2 on z/OS. Background: A large effort was undertaken to move the OnDemand application from DB2 on z/OS (DB2) to DB2 LUW on AIX (LUW). OnDemand is up for a week at a time, coming down only for IPL. The DB2 accounting record is written at that time. The team identified all the sources of OnDemand activity and changed them to point to the new LUW platform. According to the team, all DB2 activity should now be Select only. Problem: The weekly DB2 accounting record for OnDemand show Insert, Update, and Delete activity. The accounting record should have zeros in the fields. Instead, there are 198 inserts, and 396 updates. This means that something on the mainframe is still writing into OnDemand on DB2. The OnDemand system log has been checked, and it doesn't identify who is doing the inserts/updates (as far as I can tell). Since the Accounting record is once a week only, its not useful to find out when the activity occurred, which would lead to logs, undo/redo, etc. Options to find the stragglers: 1. Start the DB2 tables READ ONLY. Downside: will cause abends. 2. Scan all the DB2 logs for the week. Downside: CPU usage to scan a week's worth of logs. 3. Ask IBM-Main for ideas. Any ideas are appreciated. Thanks very much. Linda -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Windsor, Ontario, Canada mainframers
Remember IBM's Master The Mainframe Contest students. In addition to making a z platform case, there's a fresh group of trained kids available every year. Sent from my iPhone On Apr 16, 2015, at 5:03 PM, Graham Hobbs gho...@cdpwise.net wrote: Points taken Tim. Hadn't seen that link before. Thanks kindly. On 2015-04-16 4:38 PM, Tim Hare wrote: I don't think you want to sell this as 'mainframe'. I think you want to sell this as 'Enterprise class, cost-saving, Linux virtualization box'... the server folk have already attached negative connotations to the 'mainframe' word in management's mind. Presenting the cost savings (especially if you run Oracle licenses on the farm) from consolidating onto one big box is something IBM is doing all over the place and they should be glad to help. You probably have it, but here's a link to a box that is built to do z/VM with virtual Linux http://www-03.ibm.com/systems/z/os/linux/els.html -- 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: MIPS, CEC, LPARs, PRISM, WLM
The bad SQL is usually tablespace scans, and/or Cartesian product. They are relatively easy to identify and cancel. MVS reports the stress in prod, the high CPU use on the dev lpar, and I find the misbehaving thread and cancel it. Mvs reports things then return to normal. The perplexing part is the bad SQL running on LPARA is affecting its own lpar and the major lpar on the CEC. It's own lpar I can understand, but the other one too? The prefetches - dynamic, list, and sequential are ziip eligible in DB2 V10, so the comment about the bad SQL taking the ziips from prod is possible. I'm adding that to my list as something to check. The I/o comment is interesting. I'll add it to my list to watch for also. I'm hitting the books tonight. Thanks for all the ideas and references. Sent from my iPad On Dec 17, 2014, at 9:48 PM, Clark Morris cfmpub...@ns.sympatico.ca wrote: On 17 Dec 2014 14:13:46 -0800, in bit.listserv.ibm-main you wrote: In pretty good with DB2, and Craig is wonderful. It's the intricacies of MVS performance I need to bring in focus. I have a lot of reading and research to do so I can collect appropriate doc the next time one of these hits. After reading most of this thread, two things hit this retired systems programmer. The first is that with all DASD shared, runaway bad SQL may be doing a number on your disk performance due to contention and I would look at I-O on both production and test. DB2 and other experts who are more familiar with current DASD technology and contention can give more help. The other is the role played on both LPARs by the use of zAAP and zIIP processors which run hecat full speed and reduced cost for selected work loads. The bad SQL may be eligible to run on those processors and taking away the availability from production. This is just a guess based on a dangerous (inadequate) amount of knowledge. Clark Morris Linda Sent from my iPhone On Dec 17, 2014, at 2:34 PM, Ed Finnell 000248cce9f3-dmarc-requ...@listserv.ua.edu wrote: Craig Mullin's DB/2 books are really educational in scope and insight(and heavy). Fundamental understanding of the interoperation is key to identifying and tuning problems. He was with Platinum when he first began the series and moved on after the acquisition by CA.(He and other vendors were presenting at our ADUG conference on 9/11/01. Haven't seen him since but still get the updates.) The CA tools are really good at pinpointing problems. Detector and Log Analyzer are key. For SQL there's the SQL analyzer(priced) component. Sometimes if it's third party software there may be a known issues with certain transactions or areas of interactions. For continual knowledge _www.share.org_ (http://www.share.org) is a good source. Developers and installations give current and timely advice on fitting metrics to machines. The proceedings for the last three Events are kept online without signup. The new RMF stuff for EC12 and Flash drives is pretty awesome. In a message dated 12/17/2014 11:00:20 A.M. Central Standard Time, linda.haged...@gmail.com writes: I lurk on IBM-Main, and I'm always awed by the knowledge here. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
