Hi Skip,
If you define &RACLNDE and add the name of a node to it, JES will 'trust' and accept any job coming from that node and propagate the submitter's ID and group as is. Adding a node to &RACLNDE is the equivalent of creating NODES profiles of node.USERJ.* UACC(UPDATE), node.GROUPJ.* UACC(READ), and node.SECLJ.* UACC(READ). Note that NODES profiles are ignored for nodes listed in &RACLNDE, so you can't do any submitting user or group translations using NODES profiles. &RACLNDE is very powerful, and nodes should only be defined to it that are under your control.
If a job is received from an &RACLNDE trusted node, and on the receiving system (a) the submitting user isn't defined, (b) the submitter's group isn't defined, or (c) the submitting user isn't connected to the group, the submitter is treated as an undefined user and the job may fail. This is why, as Walt indicated, you should only define nodes to &RACLNDE whose RACF databases are aligned for users, groups, and connects. For systems that aren't so aligned, don't include their nodes in &RACLNDE and use NODES profiles instead.
I recommend you define &RACLNDE in each of your RACF databases and in each such profile include only the nodes for the systems sharing that particular database. Do so even on standalone systems or Multi-Access Spool configurations. This will facilitate spool reloads.
Regards, Bob
Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc. *** Celebrating our 25th Year ***
617-969-8211
www.linkedin.com/in/roberthansel
https://twitter.com/RSH_RACF
www.rshconsulting.com
--------------------------------------------------------------------------------
Upcoming RSH RACF Training - WebEx
- RACF Audit & Compliance Roadmap - SEPT 10-14, 2018
- RACF Level I Administration - APR 10-13, 2018 ** Date Change **
- RACF Level II Administration - JUN 4-8, 2018
- RACF Level III Admin, Audit, & Compliance - OCT 1-5, 2018
- RACF - Securing z/OS UNIX - APR 23-27, 2018
--------------------------------------------------------------------------------
-----Original Message-----
Date: Wed, 28 Feb 2018 19:38:33 +0000
From: Jesse 1 Robinson <***@SCE.COM>
Subject: Health Check JES_NJE_SECURITY
APAR OA49171 introduces a new health check called
Date: Thu, 1 Mar 2018 03:14:36 +0000
From: Jesse 1 Robinson <***@SCE.COM>
Subject: Re: Health Check JES_NJE_SECURITY
Ouch. I never saw Walt's proviso mentioned in the doc. Yes, these nodes are all totally under our control. However each node (sysplex) constitutes a different business environment supported by a different RACF data base. A person may have the same userid on sandbox and on production, but they do not necessarily have the same authority on both. Both represent the same person but not necessarily the same role.
We need to reassess our goal here.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
***@sce.com
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Walt Farrell
Sent: Wednesday, February 28, 2018 5:21 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: Health Check JES_NJE_SECURITY
Post by Jesse 1 RobinsonRDEFINE RACFVARS &RACLNDE UACC(NONE) OWNER(<sysprog group>) RALTER
RACFVARS &RACLNDE ADDMEM(<your JES node>) (add one for each
node)
SETROPTS CLASSACT(RACFVARS) RACLIST(RACFVARS)
You should be careful with that, Tom. &RACLNDE should only contain the names of nodes whose RACF databases are identical to each other, at least with respect to the users, groups, and user-group connections that are defined. Having a node listed in &RACLNDE will have a strong effect on security processing (mainly the propagation of submitter identity) for jobs submitted from that node to other nodes in your JES2 network.
--
Walt
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN