Adding a supplemental group

50 pts.
Tags:
CHGUSRPRF
iSeries V6R1
Is there a way to add a supplemental group?  I know how to use CHGUSRPRF and set SUPGRPPRF.  However, all I need to do is add a single supplemental group at the end.  

This would be similar to adding a library to the end of a library list (example;  ADDLIBLE LIB(JACKIE) POSITION(*LAST) .

We do not have ADDSUPGRP and RMVSUPGRP from TAATOOLS.



Software/Hardware used:
iSeries v6r1

Answer Wiki

Thanks. We'll let you know when a new response is added.

Bill,

Thanks for the feedback. In order to use chgusrprf and update supplemental groups, *OBJMGT and *SECADM are required and adopted authority cannot be used. My task was to provide “regular users” the ability to grant and revoke supplemental groups. I had coded a similar solution several days ago, but found in testing that a “regular user” could not run the program.

I advised my manager of this caviot before starting the project and just completed 4 days of coding/testing various alternative and wasn’t able to permit “regular users” to control supplemental groups in an interactive environment.

I tried adopted authority and submitting a batch job running under an ADMIN profile. Nothing made it past executing the CHGUSRPRF command. The batch job failed stating the user didn’t have authority to the ADMIN profile.

Today I recommended the interactive process create a datafeed via data queue or database. Then a program with appropriate authority could receive the information and grant the appropriate access.

The managment response is to have support grant the supplemental groups when creating profiles.

I know this won’t be the end of it….so I’m still look for a viable solution.

If anyone know of an interactive method to manipulate supplemental groups that doesn’t require special authority, please drop me a line.

Thanks,
jackie45005

Discuss This Question: 8  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • wpoulin
    Jackie, I do not see an ADDUSRPRF command option. Also, when specifying supplemental groups on the CHGUSRPRF command it replaces whatever was previously defined. What you could do is create a CL Program that first retrieves the supplemental group info from the user profile into a variable and then thru concatenation add the additional supplemental group(s) to that variable, then use CHGUSRPRF to update the User Profile. Hope this helps, Bill Poulin
    2,480 pointsBadges:
    report
  • TomLiotta
    ...adopted authority cannot be used. Why not? That is, adopted authority can definitely work for this if the adopted profile indeed has sufficient authority; so, the answer should be "Because management won't allow me to use adopted authority." Regardless, are you saying that basic users ought to be able to add a supplemental group profile whenever they want to? What should limit their choices of which profiles ought to be acceptable as group profiles? (How would you want to stop someone from adding QSECOFR?) Tom
    125,585 pointsBadges:
    report
  • jackie45005
    Yes, the request is that basic users add/remove a specific supplemental group profile whenever they want to. From inception the issues I raised are: 1) Each basic user must have *SECADM authority to execute the CHGUSRPRF command. 2) Updating supplemental groups requires *OBJMGT, *OBJOPR, *READ, *ADD, *UPD, and *DLT authority to each group profile. 3) *OBJMGT cannot come from adopted authority. On Wednesday the client agreed to have IT Support maintain the supplemental groups. However, the client still wants a method for basic users to add/remove supplemental groups in an interactive enviroment WITHOUT giving the users the required authority. Based on the current information, my recommendation stands as: A datafeed via data queue or database where a program with appropriate authority adds/removes the supplemental group.
    50 pointsBadges:
    report
  • TomLiotta
    3) *OBJMGT cannot come from adopted authority. [ GRTOBJAUT OBJTYPE(*USRPRF) AUT(*OBJMGT) ] can run under adopted authority. So, even if CHGUSRPRF may check to see if *OBJMGT exists when attempting to alter group profiles and refuse to make the change if the authority isn't available, the same program that runs CHGUSRPRF can run GRTOBJAUT first. Then when CHGUSRPRF is encountered, the appropriate authority is already there. Make sense? Tom
    125,585 pointsBadges:
    report
  • jackie45005
    Tom, Your suggestion makes perfect sense. I will give it a try tomorrow. Thanks for all your help. Regards,
    50 pointsBadges:
    report
  • TomLiotta
    ...the same program that runs CHGUSRPRF can run GRTOBJAUT first. For completeness for anyone else, the program needs to be USRPRF(*OWNER) and must be owned by a profile that has sufficiently high authority to do both actions. Naturally, authority to use the program probably needs to be controlled. Perhaps that could be done by creating an *AUTL to control access to the program and adding users to the *AUTL. If general group profiles are already in use, then those group profiles would be good candidates as users on the *AUTL. That way any new users could get authority simply because they became members of a general group. Management of the program's access authority should thereby be minimal. Tom
    125,585 pointsBadges:
    report
  • jackie45005
    Tom, It worked beautifully when I used GRTOBJAUT OBJTYPE(*USRPRF) AUT(*OBJMGT) for the user profile and the group profile. Immediately after updating the user profile I used the RVKOBJAUT OBJTYPE(*USRPRF) AUT(*OBJMGT). I can't thank you enough. Regards, Jackie
    50 pointsBadges:
    report
  • TomLiotta
    Immediately after updating the user profile I used the RVKOBJAUT OBJTYPE(*USRPRF) AUT(*OBJMGT). Usually, that shouldn't be necessary. It might not even be advisable depending on exactly what the group authority is intended to supply. Note that removing a group profile from a user should automatically remove *OBJMGT from the group or supplemental profile at the same time. Tom
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following