Re: Odd security issue with adopted authority

Chuck,
Appreciate the details.

Gary - we ran the suggested test with same results CPF9802 (as you
expected).

Can I trust the user profile in a joblog of QZRCSRVS : did a F1 help on the
CPF9802 and F9 for Display message details - in this example we know COKEK
was not the user who made the request (she is the 1st user when this
particular QZRCSRVS job started) and am thinking the Win side is connecting
to an existing connection for another user.


Message ID . . . . . . : CPF9802 Severity . . . . . . . : 40
Message type . . . . . : Escape
Date sent . . . . . . : 09/14/15 Time sent . . . . . . : 13:5

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.

Message ID . . . . . . : CPF9802 Severity
Date sent . . . . . . : 09/14/15 Time sent
Message type . . . . . : Escape

From . . . . . . . . . : COKEK CCSID .

From program . . . . . . . . . : QSYUP

From library . . . . . . . . : QSYS
Instruction . . . . . . . . : 3F1D

To program . . . . . . . . . . : K002C
To library . . . . . . . . . : KMD
To module . . . . . . . . . : K002C
To procedure . . . . . . . . : K002C
To statement . . . . . . . . : 2080

Time sent . . . . . . . . . . : 13:53:17.924614

I'm not entirely clear how the OS decides which connection is to which
QZRCSRVS job or if that is more of a client socket decision. The C#
developers gone for today to ask.

Any suggestions on how to determine which QZRCSRVS job handles a particular
request would help. I've changed the jobd to log 4 00 *seclvl and logclpgm
= *yes to see more detail .


Jim

On Mon, Sep 14, 2015 at 4:52 PM, CRPence <crpbottle@xxxxxxxxx> wrote:

On 14-Sep-2015 14:45 -0600, CRPence wrote:

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.

My above references to "QUSER on the test LPAR" were intended to have
been changed to "current user on the test LPAR"; forgot to effect that
redaction before sending.


--
Regards, Chuck

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.