Create Account registrar

330 pts.
Tags:
iSeries
iSeries Access
What authorities and special parameter should I create in order to have a user profile that could create, modify and delete user profile without using QSECOFR profile. Also this profile should be able to add user authorities to objects on iSeries

Answer Wiki

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

The easiest way is to sign on as QSECOFR and then use the copy function in the WRKUSRPRF screen to create a new profile that has all the authorities required.

=================================================================

Here’s a simple example program for you to experiment with:<pre>
pgm

dcl &UsrPrf *char 12 value( ‘NEW’ )

Qsys/crtusrprf ??usrprf( &USRPRF ) +
??pwdexp( *YES ) +
??usrcls( *USER ) +
??text( ‘New text’ ) +
??spcaut( *USRCLS )

return

endpgm</pre>
As you see, it doesn’t actually do anything except run the CRTUSRPRF command for some profile named “NEW”. By itself, that’s not very useful. And if the program is run by someone who doesn’t have enough authority to create profiles, then the program is going to crash severely when CRTUSRPRF is attempted.

To avoid a crash, compile the program something like this:<pre>
CRTBNDCL PGM( mylib/CRTPRF )
SRCFILE( mylib/QCLTSRC )
SRCMBR( CRTPRF )
<b>USRPRF( *OWNER )</b></pre>
The USRPRF(*OWNER) is going to cause the program to be created so that the profile that <b>owns</b> the program can lend authority when it’s needed. The user who runs the program doesn’t need authority to the actions done by the program.

For that to be useful, you’ll want to use CHGOBJOWN to set the new owner to be some powerful profile. It could be QSECOFR, but something less is probably advisable. For example, you might not want an owner who has *AUDIT special authority.

Also, the program should be authorized with *PUBLIC *EXCLUDE. You will want to grant *USE authority only to trusted profiles who will be authorized to create other profiles with authorities that they don’t have. Best would probably be to create a special profile that you can use as a group profile and give *USE authority to only it. Then you can add that as a group or supplemental profile to the individuals you choose.

Note that the example parameters are preceded with “??”. Since those are the only parameters listed, they will be the only ones visible when the program runs. More detail on how those work can be found under the <a href=”http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rbam6/rbam6delimeters.htm”>CL command delimiters</a> topic.

You can prompt command parameters directly as in the example above, or you can display a simple display file format to allow entry of values. Take the values and substitute them into the command like shown for &UsrPrf. Doing it that way lets you avoid prompting the command itself, but you need to code some tests over the values to see if they’re appropriate.

In short, you don’t actually need to create a “Create Account registrar”. You can instead create a small set of utilities like the example. Each one would perform a very restricted function. You would simply authorize individuals to the functions you want them to have.

Tom

Discuss This Question: 3  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
  • Jedlasquite
    Hi JohnN thank you for your prompt response, I was thinking of creating a user profile that will only perform user profile modification, creation and deletion. I user user class SECADM and set Special authorities as *USRCLS. Our QSECURITY is 30, I wasn't able to see user profile while issuing WRKUSRPRF USERPROFILE. Error message is: Additional Message Information Message ID . . . . . . : CPF2228 Severity . . . . . . . : 40 Message type . . . . . : Diagnostic Date sent . . . . . . : 04/14/10 Time sent . . . . . . : 23:31:44 Message . . . . : Not authorized to change user profile. Cause . . . . . : Object management (*OBJMGT) and use (*USE) authority are required for each user profile being changed. Recovery . . . : Have the security officer give you the required authority to change the user profile.
    330 pointsBadges:
    report
  • Jedlasquite
    Hi Tom, Thank you for a very informative response, ,I'm learning alot. I'm still starting to learn RPG. I would like to ask is this like an adopted authority on a program to create user profile? How about Enabling a user profile? What I was planning is to create a user profile with SECADM authority that could ONLY create, modify (enable, change parameter, etc) and Delete user profile. Also this profile can add authorities to objects. I created an account with User class SECADM and default Special authority *USRCLS. Problem is I cannot create nor see any profile while invoking wrkusrprf <userprofile>. I tried modifying the Special Authority and adding *allobj, I now can see userprofiles, modify, create and delete. Problem is I don't know what limitation it has as compared to QSECOFR.
    330 pointsBadges:
    report
  • TomLiotta
    I would like to ask is this like an adopted authority on a program to create user profile? How about Enabling a user profile? If you compile the example CL with USRPRF(*OWNER) and have it owned by a powerful profile, then "adopted authority" is exactly what happens when a low-authority user is authorized to run the program. The user "adopts" the authority of the program owner. That is essentially the definition of adopted authority. You can create a set of such tiny programs where each program does one very limited function, or you could create a single more complex program that uses logic to restrict what it will do for different users. You choose how to do it. If you create a set of tiny programs, you can use external authorities to change who can use different programs at different times. If you code a more complex program, you might only need a single program, but the chance increases that you'll need to modify and recompile the program for future changes. You could create a clone of the example program that does nothing but set a given user profile to *ENABLED. What I was planning is to create a user profile with SECADM authority that could ONLY create, modify (enable, change parameter, etc) and Delete user profile. Also this profile can add authorities to objects. There is a little more that needs to be understood before that becomes feasible. I created an account with User class SECADM and default Special authority *USRCLS. Problem is I cannot create nor see any profile while invoking wrkusrprf <userprofile>. I tried modifying the Special Authority and adding *allobj, I now can see userprofiles, modify, create and delete. Problem is I don’t know what limitation it has as compared to QSECOFR. *SECADM enables the capability to execute those kinds of functions. However, in order to run such functions against profiles that already exist, you also need to grant at least *CHANGE authority for those profiles to your *SECADM profile. Without giving object authority to your *SECADM profile, that profile would only be able to modify new profiles that it created. The "*SECADM" value is one of the 'special' authorities that the system allows. For now, you should think of it as granting an ability to do an action. Beyond that ability, there must also be authority to perform the action on particular objects. The object authority comes automatically when it creates a new profile because it is the owner of the new profile. But it doesn't own profiles that already exist. Those belong to someone else. (Whoever created them previously.) So, object authority must be granted. You could have two *SECADM profiles for example. Both could create new profiles; but neither could affect profiles owned by the other until they granted each other object authority for each of their owned profiles. One might be in control of Warehouse profiles. The other might be in control of Executive profiles. There are numerous 'special' authorities. QSECOFR has all of them and the system will not allow you ever to remove a special authority from QSECOFR. One additional special authority that QSECOFR has is *ALLOBJ. If you granted *ALLOBJ along with *SECADM, then your *SECADM would automatically have object authority to every other profile in the system. And the *SECADM special authority would mean that the profile could also perform various actions against the other profiles. Some things would still be restricted though. For example, you cannot create a new profile and give it a special authority that you don't have for yourself. So your *SECADM profile can create a new profile but is unable to give *IOSYSCFG to anybody else. An adopted authority program can supply such missing elements without giving the capability directly. Adopted authority can be very handy. Note that the use of such a program should be audited. You might include a SNDMSG command, for example, in the program so that it logged a message about what it did whenever anyone called it. You should possibly start by creating at least one profile that has all of the special authorities. If one doesn't already exist, you'll have to sign on as QSECOFR to do it. Once that powerful profile exists, it should be used instead of QSECOFR for future security work. (As far as possible, don't use QSECOFR except out of IBM instructions.) You might eventually create a couple additional semi-all-powerful profiles. For example, there is rarely a need to grant *AUDIT special authority to anyone. A semi-all-powerful profile wouldn't that special authority. The 2nd-tier less powerful profiles would probably become owners of most of your adopted-authority programs for this kind of work in the future. 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