RE: Allowing Someone to Create User Profiles...

Chuck:

I'd generally recommend creating a profile that cannot signon -- 
PASSWORD(*NONE) INLPGM(*NONE) INLMNU(*SIGNOFF). You might not even have a 
reason for it to be *ENABLED. There's no mandatory reason to think of this as a 
"user"; it's simply another object on your system that provides granularity for 
your use. A similar example -- I create *JOBD objects that are never used as 
"job descriptions" per se; I might use them to store library lists because 
they're good at doing that in minimal space and overhead, and there are APIs 
and other functions to support it.

Unfortunately, no one can ever tell _you_ the "right" way to set such things up 
without learning your environment first. OTOH, these lists do provide the 
discussions that help everybody build their own background info to apply as 
appropriate. (Though sometimes attempted discussions get taken a bit off 
course.)

Tom Liotta

"Chuck Lewis" <clewis> wrote:

>Tom,
>
>Thanks for all the good, thought provoking information !
>
>I could even create this profile and not allow it to signon for added
>"strength" ?
>
>Chuck
>
>
>-----Original Message-----
>
>Chuck:
>
>As long as you grant the "regular user" authority to the program, there
>should be no problem. The rule-of-thumb to keep in mind is something like
>"You can't grant an authority that you do not have." If the program is owned
>by QSECOFR and is compiled to run under the owner's authority, then that
>program can do just about anything as long as you have authority to program
>it. And anyone who's authorized to that program can do whatever that program
>allows.
>
>I'd guess that it's very rare that a *SECOFR class profile needs to be
>created by any user while you're away. So perhaps you wouldn't put that
>capability in. It seems reasonable that the vast majority will be general
>*USER class profiles who will be granted authority to various applications,
>and perhaps you have reason to include a special authority such as *JOBCTL.
>
>Under that scenario, then you might create a profile that has *SECADM and
>*JOBCTL special authorities plus whatever application authorities are
>reasonable. This will be the owner of your program. Then, no matter what
>else happens -- unintended command lines for example -- the authority won't
>be enough to do many surprising things.
>
>Taking this a step further, perhaps the only authority you really want for
>the *OWNER profile is the *SECADM special authority. The owner's authority
>is cumulative with the user. Most likely the reason your users can't create
>new profiles is because they don't have *SECADM; they might have all the
>necessary object authorities for your applications. That setup would mean
>that a user who was authorized to your program could only create another
>user with the same or lesser authority. (I believe *SECADM cannot be granted
>unless *ALLOBJ is also available.)
>
>By granting program authority to a few application administrators, each
>application group could create new profiles as needed -- and only within
>their areas. (This normally would include authority to relevant group
>profiles, but you'll need to verify your own circumstances.)
>
>You might also want to turn on object auditing for the program, or perhaps
>have the program turn on auditing for the calling user and turn it back off
>when it exits. These require *AUDIT special authority and should also be off
>in a separate program called by your main program.
>
>Perhaps the trickiest part will be getting any needed private authorities
>set. That may depend on how you're currently set up. Do your users have
>authority to all needed libraries and objects? Or do they instead have
>authority only to call application programs that also use adopted authority
>to get their work done? Do you have multiple groups of users with sets of
>private authorities? Are groups of users authorized by way of group
>profiles? authorization lists? In short, can you reasonably create a program
>that covers all the ground you need to cover?
>
>Since you probably have been doing it manually for a while, I imagine you
>know the patterns for your shop. Just wanted to mention things for
>discussion and archives.
>
>Grant the minimum authority needed for a task and it's much harder to go
>wrong, especially if anyone ever questions (audits) the results later.
>
>Tom Liotta
>
>
>"Chuck Lewis" <clewis> wrote:
>
>>Cool. I've done that before with other stuff but I was thinking
>>(incorrectly) that a regular user could not do this.
>>
>>Thanks !
>>
>>Chuck
>>
>>
>>-----Original Message-----
>>
>>      The easy way is to write a program or a number of programs and make
>>the owner QSECOFR and when you create the programs take F4 and use 'USRPRF
>>*OWNER', the default is *USER.  Change the owner of the programs QSECOFR.
>>Make sure that the user cannot get to a command line while using the menu
>>options, since they will still have QSECOFR authority if they can.
>>      Hope this helps.
>>                                       
>> Julio Domingo                         

-- 
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
Fax    253-872-7904
http://www.powertechgroup.com


__________________________________________________________________
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=393397

Get AOL Instant Messenger 5.1 free of charge.  Download Now!
http://aim.aol.com/aimnew/Aim/register.adp?promo=380455