|
Wanda, Chuck is right on with this. I have run into this same situation with a few clients, and it can be difficult to correct, so typically, it doesn't get corrected. What happens is that ALLOBJ was handed out in the beginning by someone who didn't want to worry about authority problems, then as abuses occurred or for some other reason, selected commands are revoked from selected users or groups. This causes problems where people are unable to do something they need (or think they need) to do, then passwords are shared or workarounds found, and a maintenance nightmare is created for the security administrator. I don't like to have to tweak authority on specific objects, including commands. AS/400 security is so good, but I rarely see a good implementation of it. To do it right requires some foresight and planning. You need to determine what you really want to do. Use group profiles always. No one should be doing their day to day work with a profile that has ALLOBJ, including the security admin. Save your QSECOFR profile for security changes only. It's fairly common for programmers to belong to either QPGMR, or a very similar group profile of another name. What you use depends on you, but make sure you think it through. Simply assigning programmers to a new group may suddenly prevent them from replacing objects. Changing your users may suddenly stop them from being able to run jobs, or programs may run, only to crash on such commands as ADDPFM. You may want to read up on security. You can find books on the topic at both the News 400 site and Midrange Computing sites. Wayne Evans has written volumes on the subject, I haven't read any of it, but I have sat in on sessions he's given, and discussed security with him, and he is VERY knowledgeable on the subject. The problem, of course, is that learning how it works doesn't necessarily translate into good practice. I would be interested in hearing about the approach you decide to take. Does anyone out there have any security design 'best practices'? Kathleen Kostuck ___________________ pager (414) 402-0820 fax (414) 495-4986 kkostuck@execpc.com AS400 Solutions ___________________ ---------- > From: Chuck Lewis <CLEWIS@IQUEST.NET> > To: MIDRANGE-L@midrange.com > Subject: Re: Set up a profile Question > Date: Wednesday, August 19, 1998 9:19 AM > > Ugggg... > > There is NO WAY that Programmers and ESPECIALLY Operators should have *ALLOBJ !! > > The problem with undoing this is they may or may not be able to do certain things > now. Programs could bomb, commands not work, etc. > > It will be hard to undo, but REALLY something that should be done ! > > It SOUNDS like the IBM command authority MIGHT have been changed because > Operators had *ALLOBJ and could execute anything... > > Not the best way to handle something like this, but might have been done at a > time when someone was new to the system and not fully aware of the best way to do > these things (hindsight is ALWAYS better than foresight... <BG>). > > Chuck > > > Torres, Wanda wrote: > > > > We are going to be audited and I am assigned to clean up. Our > > > operators and programmers user profiles have special authority *ALLOBJ. > > > I noticed that IBM commands in QSYS authority have been changed. > > > > > > 1) Is it common for shops to changed IBM command authority? I > > > noticed why operators can't run some commands because of this. > > > > > > 2) When setting up a operator or programmer profile does anyone use > > > QSYSOPR as a group profile for Operators or QPGMR as a group profile for > > > > > > Programmers? > > > > > > When I listed all command authority QSYSOPR & QPGMR user profiles have > > > private authority to some IBM commands. > > > > > > > > > > > > Thanks, > > > Wanda > > > > > +--- > > | This is the Midrange System Mailing List! > > | To submit a new message, send your mail to MIDRANGE-L@midrange.com. > > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. > > | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. > > | Questions should be directed to the list owner/operator: david@midrange.com > > +--- > > > > +--- > | This is the Midrange System Mailing List! > | To submit a new message, send your mail to MIDRANGE-L@midrange.com. > | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. > | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. > | Questions should be directed to the list owner/operator: david@midrange.com > +--- +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.