That's only one of the reasons for creating group definitions.
A group can "own" other groups as a way of documenting structural relationships even when resource permissions are not directly involved.
A group can "own" resource profiles as a way of granting non-SPECIAL users the ability to manage permissions for very specific resources (group-SPECIAL).
A group may be required In order to control/allow data sets with a that HLQ, when it does not make sense for that HLQ to be the name of a User profile.
There will always be some permission requirements that arise that are at least initially unique to one specific user, which makes it tempting to expend less effort and assign those permissions directly to the user rather than creating a new group for a new work role which hasn't yet been formalized -- especially when the requirement may have been described as "temporary".
With 20/20 hindsight one realizes that perhaps installation standards should always require creating a new group when needed to avoid direct permits to user profiles; but then you should also initiate a periodic review process for such groups to see if they have become obsolete, need to be merged with other groups, or need to be better-named to reflect a now-formalized work role.
Joel C Ewing On 1/20/20 8:21 AM, Allan Staller wrote:
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?
-- Joel C. Ewing ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
