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
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:
" • 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
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
We allow a select group of users, outside of IT, to manage outside
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.