Re: Cyberark for zOS
As Dave mentions, we used a dedicated ssh server. I wrote a unix rexx (U1) which is called by Cyberark through SSH. Via the unix rexx U1 another REXX is called via the EXEC command (let's say T1). In T1 we interprete the parameters given by cyberark, being userid and password. Via zSecure's CKGRACF interface we implemented the password change. CKGRACF is chosen, because it's more flexible in scoping the userids which are allowed for password resets. The owner of the target users is a specific group and that group is scoped via CKGRACF (XFACILIT/FACILITY class profile CKG.SCP.ID.*.ownergroup.* We allowed the SSH server access to the CKGRACF commands: CKG.CMD.USER.REQ.PWNOHIST CKG.CMD.USER.REQ.PWSET.EXPIRED CKG.CMD.USER.REQ.PWSET.NONEXP CKG.CMD.USER.REQ.PWSET.NOPASSWORD CKG.CMD.USER.REQ.PWSET.NOPHRASE CKG.CMD.USER.REQ.PWSET.PASSWORD CKG.CMD.USER.REQ.PWSET.PHRASE CKG.CMD.USER.REQ.RESUME This way, the ssh server can manipulate all users passwords which have as owner "ownergroup" , but nothing else. If you don't have zSecure, you can also use the RACF ALU command, but that is much less flexible in scoping. regards, Luc -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMDS error DBNV016
How large is the exit routine? (number of csects and sizes in bytes) Michael At 01:42 PM 6/23/2024, José I. RÃos wrote: Hi, Yes, but it was compiled apperantly without no changes long time ago. We are searching the source code. There was no new maintenance only that we moved the LPAR to a new z16. Best Regards, Josian On Sun, Jun 23, 2024, 11:18 wrote: > Is that a user exit for ends? Do you have the source to see when the > message is issued? > > > Any maintenance installed? > > > Lizette > > > Sent from EarthLink Mobile mail > > > On 6/23/24, 07:34, José I. Ríos < > 067c0a7727ce-dmarc-requ...@listserv.ua.edu> wrote: > > > Hi, > > > We are having problems with RMDS (Report Management Distribution System), > > and we wonder if someone has stumbled in this situation. After an IPL, the > > users report in RMDS login screen the error: > > > DBNV016 SECURITY CHECK FAILED: DBNIXSEC > > > Our Security Team verified any errors with the users, but they did not find > > any security issues in their TSS reports. > > > The version of z/OS is 2.4, and RMDS is in version 2.3. > > > Thanks, > > Josian > > > -- > > 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: Cyberark for zOS
Although CyberArk supports multi-factor authentication (to/with CyberArk), if you configure RACF (or your other z/OS ESM) to trust CyberArk fully then there’s no multi-factor authentication to/with z/OS or any applications running on z/OS. And that means that if CyberArk is ever compromised it’s “game over.”(*) To their partial credit CyberArk emphasizes the importance of keeping the CyberArk server (which runs on Microsoft Windows) secure, but I think you have to assume the worst, that any/every single system could be compromised. Consequently if you have CyberArk managing RACF passwords/passphrases that’s probably fine provided you also still challenge the user to provide a second factor when authenticating with RACF — in their TSO/E sign-on, as one example. And that second factor provider might be the same second factor provider that you use when you authenticate with CyberArk, but it’s still a second factor outside of both CyberArk and RACF. “Quis custodiet ipsos custodes?” Unfortunately I’ve seen a lot of examples of mainframe shops effectively shutting off RACF. They configure RACF to delegate all or most authentication and authorization decisions to something else, some singleton (in security terms). And that’s bad, often really bad. It’s OK or even better than OK for your z/OS ESM to work *collaboratively* with other security providers to achieve more secure outcomes — and with more convenience and manageability, such as identity management/governance across an enterprise. But don’t effectively disable RACF! RACF (and other z/OS ESMs) have unique security domain expertise, and they need to be meaningfully “in the loop” if you’re ever going to achieve even reasonably secure outcomes. As a reminder, my views are my own. (*) Think about it this way. Imagine somebody walks into a bank branch and demands a $1 million withdrawal from a bank account. It’s an account that’s set up as a joint account, and the account requires two individuals to sign off. The bank teller asks, “Where’s the other account holder? We need her authorization, too.” And the person says, “She told me it’s OK. Take my word for it.” That’s what’s going on here if you misconfigure z/OS RACF with CyberArk. You might be authenticating with CyberArk using a second factor, and that’s great. But when you go to the bank (RACF) is it good enough to assert that your “buddy” said it’s OK? No, it really isn’t. RACF should be checking directly with your buddy, too. Now that you know, go fix this exposure if you have it. — 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: RMDS error DBNV016
What machine type was ii running on before? Lizette Sent from EarthLink Mobile mail On 6/23/24, 11:42, José I. Ríos wrote: Hi, Yes, but it was compiled apperantly without no changes long time ago. We are searching the source code. There was no new maintenance only that we moved the LPAR to a new z16. Best Regards, Josian On Sun, Jun 23, 2024, 11:18 mailto:stars...@mindspring.com)> wrote: > Is that a user exit for ends? Do you have the source to see when the message > is issued? > Any maintenance installed? > Lizette > Sent from EarthLink Mobile mail > On 6/23/24, 07:34, José I. Ríos > <067c0a7727ce-dmarc-requ...@listserv.ua.edu > (mailto:067c0a7727ce-dmarc-requ...@listserv.ua.edu)> wrote: > Hi, > We are having problems with RMDS (Report Management Distribution System), > and we wonder if someone has stumbled in this situation. After an IPL, the > users report in RMDS login screen the error: > DBNV016 SECURITY CHECK FAILED: DBNIXSEC > Our Security Team verified any errors with the users, but they did not find > any security issues in their TSS reports. > The version of z/OS is 2.4, and RMDS is in version 2.3. > Thanks, > Josian > -- > 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 with the message: INFO IBM-MAIN
Exits (was RMDS error DBNV016)
Although I gather z/OS now allows them to be in REXX. I'm a REXX enthusiast and HLASM is still in my future, but I have to wonder whether that's a good idea. I gotta believe exits get hit a lot; surely it would be a drag on the system? --- Bob Bridges, robhbrid...@gmail.com, cell 336 382-7313 /* Let the righteous smite me in kindness and reprove me. It is oil upon my head; do not let my head refuse it. -Psalms 141:5 */ -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Schwab Sent: Sunday, June 23, 2024 14:52 Most exits are assembler, right? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMDS error DBNV016
Most exits are assembler, right? Run a disassembler and save the generated source. Compare with sample and instructions of old version (last before required recomplie) and create comments, variable names. Review required changes and new facilities and update as needed. On Sun, Jun 23, 2024 at 1:43 PM José I. Ríos <067c0a7727ce-dmarc-requ...@listserv.ua.edu> wrote: > > Hi, > > Yes, but it was compiled apperantly without no changes long time ago. We > are searching the source code. There was no new maintenance only that we > moved the LPAR to a new z16. > > Best Regards, > Josian > > On Sun, Jun 23, 2024, 11:18 wrote: > > > Is that a user exit for ends? Do you have the source to see when the > > message is issued? > > > > > > Any maintenance installed? > > > > > > Lizette > > > > > > Sent from EarthLink Mobile mail > > > > > > On 6/23/24, 07:34, José I. Ríos < > > 067c0a7727ce-dmarc-requ...@listserv.ua.edu> wrote: > > > > > > Hi, > > > > > > We are having problems with RMDS (Report Management Distribution System), > > > > and we wonder if someone has stumbled in this situation. After an IPL, the > > > > users report in RMDS login screen the error: > > > > > > DBNV016 SECURITY CHECK FAILED: DBNIXSEC > > > > > > Our Security Team verified any errors with the users, but they did not find > > > > any security issues in their TSS reports. > > > > > > The version of z/OS is 2.4, and RMDS is in version 2.3. > > > > > > Thanks, > > > > Josian > > > > > > -- > > > > 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RMDS error DBNV016
Hi, Yes, but it was compiled apperantly without no changes long time ago. We are searching the source code. There was no new maintenance only that we moved the LPAR to a new z16. Best Regards, Josian On Sun, Jun 23, 2024, 11:18 wrote: > Is that a user exit for ends? Do you have the source to see when the > message is issued? > > > Any maintenance installed? > > > Lizette > > > Sent from EarthLink Mobile mail > > > On 6/23/24, 07:34, José I. Ríos < > 067c0a7727ce-dmarc-requ...@listserv.ua.edu> wrote: > > > Hi, > > > We are having problems with RMDS (Report Management Distribution System), > > and we wonder if someone has stumbled in this situation. After an IPL, the > > users report in RMDS login screen the error: > > > DBNV016 SECURITY CHECK FAILED: DBNIXSEC > > > Our Security Team verified any errors with the users, but they did not find > > any security issues in their TSS reports. > > > The version of z/OS is 2.4, and RMDS is in version 2.3. > > > Thanks, > > Josian > > > -- > > 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: Data Set Commander Monitor (DSCMON) Access Authority
We did UACC(WARN) and monitored to make sure somebody put RACF on it. We eventually went to NONE. On Sun, Jun 23, 2024 at 7:16 AM Radoslaw Skorupka <0471ebeac275-dmarc-requ...@listserv.ua.edu> wrote: > > W dniu 23.06.2024 o 10:51, Mike Cairns pisze: > > No Bob - I meant UACC(READ) or its equivalent. I just don't see what gate > > is being closed by insisting that LinkList or LPA libraries must have > > UACC(NONE), when, as you confirm, they cannot be fetch protected and > > therefore the content is available to anyone on the system anyway. > > I met the following justification: when you have UACC(NONE) for > linklisted library then you enforce use LNKLST instead of STEPLIB/JOBLIB. > While I understand the above, I don't agree with the goal as being worth > such configuration. > > And there is another approach: UACC above NONE should not be used at > all. Just because mama (auditor) said so. > > > -- > 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 -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
RMDS error DBNV016
Hi, We are having problems with RMDS (Report Management Distribution System), and we wonder if someone has stumbled in this situation. After an IPL, the users report in RMDS login screen the error: DBNV016SECURITY CHECK FAILED: DBNIXSEC Our Security Team verified any errors with the users, but they did not find any security issues in their TSS reports. The version of z/OS is 2.4, and RMDS is in version 2.3. Thanks, Josian -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Data Set Commander Monitor (DSCMON) Access Authority
W dniu 23.06.2024 o 10:51, Mike Cairns pisze: No Bob - I meant UACC(READ) or its equivalent. I just don't see what gate is being closed by insisting that LinkList or LPA libraries must have UACC(NONE), when, as you confirm, they cannot be fetch protected and therefore the content is available to anyone on the system anyway. I met the following justification: when you have UACC(NONE) for linklisted library then you enforce use LNKLST instead of STEPLIB/JOBLIB. While I understand the above, I don't agree with the goal as being worth such configuration. And there is another approach: UACC above NONE should not be used at all. Just because mama (auditor) said so. -- 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: Data Set Commander Monitor (DSCMON) Access Authority
No Bob - I meant UACC(READ) or its equivalent. I just don't see what gate is being closed by insisting that LinkList or LPA libraries must have UACC(NONE), when, as you confirm, they cannot be fetch protected and therefore the content is available to anyone on the system anyway. Cheers - Mike -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
