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 ***
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 <jesse1.robin...@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 <jesse1.robin...@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

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Walt Farrell
Sent: Wednesday, February 28, 2018 5:21 PM
Subject: (External):Re: Health Check JES_NJE_SECURITY

On Wed, 28 Feb 2018 18:21:03 -0500, Tom Conley <pinnc...@rochester.rr.com> 

>I ran these on 1/5/18 to fix this check:
>RACFVARS &RACLNDE ADDMEM(<your JES node>)  (add one for each

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.


For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to