Isn't this the reason for group definitions.
If done properly, just connect the "new" user to the same groups as the "old"
user and all should be ok.
If not done properly, this is still a big leg up over "starting from scratch".
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of
Jesse 1 Robinson
Sent: Friday, January 17, 2020 3:58 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Rexx or similar to clone a RACF user?
[CAUTION: This Email is from outside the Organization. Do not click links or
open attachments unless you trust the sender.]
Cloning a userid is a very tricky proposition. For one thing, what does 'clone'
mean to the requestor? If the userids have to be functionally
identical/interchangeable, a great many paths and a cross tracks have to be
explored. We don't have a program product to do this either, so it's a hit or
miss exercise that involves a lot of tweaking when divergences are discovered.
As Joel says, preference for groups over individual permissions is highly
desirable, but that may be like remodeling the barn after the horse has
escaped. Again.
.
.
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
robin...@sce.com
-----Original Message-----
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of
Joel C. Ewing
Sent: Friday, January 17, 2020 1:19 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: Rexx or similar to clone a RACF user?
Unless things have changed, the problem is that RACF permissions granted
directly to a user to a dataset profile or other resource profile are stored as
part of that resource profile, not as part of a user profile. While user
attributes and group connections to a user are easy to clone just by looking at
or parsing a display of the to-be-cloned user profile, unless your
installation only grants permissions via groups that are then connected to
users, in the worst case you are forced to examine ALL resource profiles to see
which ones had permissions for the to-be-cloned user profile and grant similar
permits to the new user profile.
While it could be done, It was judged impractical to examine all
resource-to-user permissions from the actual RACF database; so we used a
standard RACF utility to dump the RACF database in a format that could then be
uploaded into DB2 tables every night. The DB2 tables could be efficiently
queried to find what resource permits were granted to a specific user and
needed to be cloned, and we just cloned from userids that we knew hadn't been
changed since the last RACF DB2 table build. We did use REXX code to do the
cloning, but it used a combination of RACF commands and DB2 queries to
determine what needed to be done. Our Rexx code was not completely generic, but
was customized for our installation's RACF standards and conventions, which
meant that some classes of resource profiles were only granted to group
profiles and could be safely ignored when cloning a user as they would be
covered by replicating the group connects for the user.
Joel C Ewing
On 1/17/20 12:25 PM, Charles Mills wrote:
> X-posted RACF-L and IBM-MAIN.
>
>
>
> A Google search reveals that the question "how do I clone a user in RACF?"
> has been asked before and the answer is basically "buy Vanguard,
> Beta88 or zSecure." People also mentioned "you might write a Rexx script to
> do this."
>
>
>
> Not having one of those proprietary products I searched the CBT tape
> to see if such a Rexx script were to be found there, without success.
>
>
>
> So my question is: does anyone know of a CBT or similar tool to clone
> a RACF user, or does anyone have a Rexx script that they might be willing to
> share?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
::DISCLAIMER::
________________________________
The contents of this e-mail and any attachment(s) are confidential and intended
for the named recipient(s) only. E-mail transmission is not guaranteed to be
secure or error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or may contain viruses in transmission.
The e mail and its contents (with or without referred errors) shall therefore
not attach any liability on the originator or HCL or its affiliates. Views or
opinions, if any, presented in this email are solely those of the author and
may not necessarily reflect the views or opinions of HCL or its affiliates. Any
form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written
consent of authorized representative of HCL is strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. Before opening any email and/or attachments, please check them for
viruses and other defects.
________________________________
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
