The problem with cloning an existing user's RACF setup is that permits
to a resource are only stored as part of the resource profile, so when a
permit is given directly to a user there is nothing that can be listed
from the user's profile that indicates the resource permission was
given. If you know such permits have been directly granted to some
users (and there are cases where it may be unavoidable), the only way
guaranteed to discover all such permits in real time is to somehow list
and parse all the permits for all resources in all classes that have
treated that way and replicate all permits found granted to the old user
to the new user.
To do this directly from the RACF database would be grossly inefficient,
as you potentially have to list and parse the entire database.
Fortunately, a RACF user that would be used for such a cloning is
generally one that has been set up and been functional for some time, so
you do not really need to look at the real-time RACF database.
Information that is one or more days old is usually more than adequate.
There is a RACF utility that unloads the entire RACF database in a
format that can be used to reload the entire database into appropriately
defined DB2 tables. We used to rebuild those tables every night as part
of a RACF database backup procedure so they could be used for queries
that the RACF database was not designed to efficiently handle. If you
set up appropriate alternate indexes, those DB2 tables can be
efficiently queried to find all permits associated directly to a
specific user. After the information in the old user profile was used
to define the new user profile, a REXX exec used these DB2 tables to
create any necessary direct permits when cloning a user. Our
installation standards and conventions limited which RACF classes needed
to be considered.
To keep RACF maintenance more manageable, you do want to grant almost
all RACF resource permits to RACF groups, and use connection of a user
to various groups to grant permissions. Running with list-of-groups
checking (GRPLIST) enabled allows group connections to add to existing
authorities, rather than requiring an explicit login specifying that
group. That makes it easy to add new roles to a user or to change a
user's functional roles by adding or removing the user to or from RACF
groups associated with the role.
Group connections are easy to clone to a new user, because all group
connections are reflected by fields in both the user profiles and the
group profiles.
Our installation RACF standards were enforced by the procedures used by
our RACF administrators. This enabled us make some assumptions and
simplifications in what needed to be checked when cloning a RACF user.
Those assumptions might not be appropriate in other environments.
Having manually-maintained user-definition templates might work in some
environments, but there is always the risk they will drift out of sync
from the current RACF definitions as RACF changes are made.
Joel C Ewing
On 11/16/23 05:17, Radoslaw Skorupka wrote:
W dniu 16.11.2023 o 05:04, Peter pisze:
Hello
I am looking for a rexx logic which can multiple RACFID based on one
model
user ?
Does anyone have any sample rexx code or any logic that you can share
with
me?
Hint: use template.
Just create some member with all definitions needed to create a user.
Then CHANGE USER1 USER2.
If you really need it "automated" then use REXX/ISPF edit features.
BTW: Think about security model. Vast majority of RACF users should
have authorities coming from group membership. Such approach allows
very easy addition/deletion of users.
--
Joel C. Ewing
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
