Re: Odd security issue with adopted authority

On 14-Sep-2015 10:41 -0600, Jim Franz wrote:

This has worked for several years, and no recent program change,
PTFs, or profile change that we can detect. It worked up to Friday
morning...

Looking at an issue where a program that adopts authority
(User profile . . . . . . . . : *OWNER)
and owner has *ALLOBJ and *SECADM is executing a CRTUSRPRF and
not authorized to the Group Profile of the user to be created.
This is a client job (C#) calling my program

Job: QZRCSRVS User: QUSER Number: 008237
Message ID . : CPF9802 Severity . . . . . . . : 40
Message type : Escape
Date sent . : 09/14/15 Time sent . . . . . . : 11:4
Message . . . . : Not authorized to object GR_NONXYZ in QSYS.
Cause . . . . . : You do not have the correct authority for object
GR_NONXYZ in library QSYS type *USRPRF.
Recovery . . . : Contact your security officer or the object owner
to obtain the correct authority and try your request again.

So does the current-user for that job have *OBJMGT authority to the user profile (*USRPRF) object named GR_NONXYZ, as obtained from something *other than* adopted authority? Probably not. And if not, then the error is correct. The /required/ authority, according to the *Restrictions* from the command documentation, is:
[http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/cl/crtusrprf.htm]
" • Change (*CHANGE) and object management (*OBJMGT) authorities to the group profile and supplemental group profiles (if specified)."

But then additionally, specifically for the Group Profile (GRPPRF) and Supplemental Groups (SUPGRPPRF) parameters, there is the additional note [seen in the same\above doc link]:
"The current user of this command must have object management (*OBJMGT) and change (*CHANGE) authority to the profile specified for [this] parameter. The required *OBJMGT authority cannot be given by a program adopt operation."

Why that additional *restriction* that the authority for the group profiles can not be _adopted_, is not included [*also*] in that above bullet, I have no idea. Although the TechNote document is helpful [as that document therefore can be found, by searching on the error message identifier and failing command name], the actual documentation could be made clear(er) IMO. Anyone who cares, e.g. the OP, might desire to suggest [by submitting an electronic comment to the docs] that the information about the specific restriction with regard to the use of adopted authority for the *OBJMGT right, like already is described in both the TechNote document N1013328 [www.ibm.com/support/docview.wss?uid=nas8N1013328] and [but] buried in the documentation of the xxxGRPPRF parameters, should be included *also* under the general *Restrictions* for the Create User Profile (CRTUSRPRF) [and Change User Profile (CHGUSRPRF)] command documentation.

This still works in out test partition but not in production.

Probably "This" is not identical, despite the implication; the request or requester is different, and\or there are differences between the LPARs. The difference may be [and probably is] object authorities, rather than the attributes of the profiles. Possibly QUSER on the test LPAR was incorrectly modified to have more than SPCAUT(*NONE), or the QUSER on the test LPAR explicitly has the necessary authority to the group profile.

We allow a select group of users, outside of IT, to manage outside
users. V7R1.
Owner has *ALLOBJ *AUDIT *IOSYSCFG *JOBCTL *SAVSYS
*SECADM *SERVICE *SPLCTL

As already described above: That the owner of the program [from which the authority is adopted to issue CRTUSRPRF] has SPCAUT(*ALL), is moot, for accessing the [supplemental] group profile(s) being referenced on the Create User Profile (CRTUSRPRF) request; i.e. the [*current*] user running the program needs to have explicitly granted [or have via *GROUP authorities], the *OBJMGT authority to the [supplemental] group profile(s). That is because the OS explicitly prohibits the /adopted/ authority [from the owner of the program] for the Test Authority (TSTAU) that is issued against those objects, specifically when processing the CRTUSRPRF command or the CHGUSRPRF] command.