|
Here's where we are coming from: http://www.dekko.com/GroupDekko.nsf/Companies Each of these companies have their own data library, program library and query library. For example: CLIDIVF, CLIDIVO, CLIDIVQ DETDIVF, DETDIVO, DETDIVQ MCIDIVF, MCIDIVO, MCIDIVQ and so on.. Each library has their own authorization list. Some employees actually do work for more than one company. Need further explanation? I don't want to flood you with information when that might be enough to explain it. We actually have so many files that it is impossible for SSA to own all of them. There is a limit to how many objects one user may own. Actually that was the straw that got us securing each companies data file library better. Rob Berendt -- Group Dekko Services, LLC Dept 01.073 PO Box 2000 Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com CWilt@xxxxxxxxxxxx Sent by: security400-bounces@xxxxxxxxxxxx 05/27/2004 12:54 PM Please respond to Security Administration on the AS400 / iSeries <security400@xxxxxxxxxxxx> To security400@xxxxxxxxxxxx cc Subject RE: [Security400] Documenting / Managing iSeries security Rob, Don't quite understand where you are coming from. Does every application have it's own library? Do you have one library for AP, one for AR, ect? What do Betty, Sam, Peter, and Julie do? As I understand it, the idea is a group profiles groups users of similar needs. So my users doing receiving are all in one group, my accounting people are all in another group. I even stick users by themselves into a group. Why? Simple really, if I ever need to add a user, or the user is replaced then it's just a matter of copying a profile. Since the authority to the objects are given to the group via the authorization list, I don't need to update the authorization lists for the new user. An example from my own setup: I have the following group profiles: GRPACEMPLY Accounting Dept--full access GRPACINTRN Accounting Dept--limited access for interns GRPPUEMPLY Purchasing Dept--full access And here are the authorization lists: ACLIMIT Accounting Limited Access GRPACEMPLY *USE GRPACINTRN *USE *PUBLIC *EXCLUDE ACRESTRICT Accounting Restricted Access GRPACEMPLY *USE *PUBLIC *EXCLUDE VENDMAINT Vendor Maintenance Access GRPACEMPLY *USE GRPPUEMPLY *USE *PUBLIC *EXCLUDE Charles > -----Original Message----- > From: rob@xxxxxxxxx [mailto:rob@xxxxxxxxx] > Sent: Thursday, May 27, 2004 1:24 PM > To: Security Administration on the AS400 / iSeries > Subject: RE: [Security400] Documenting / Managing iSeries security > > > On issue 1. I agree that owner profiles shouldn't be any > part of a group > profile. Instead authorization lists should be used. We're > moving in > that direction. > > On issue 2. We had a team of IBMers dialed in to resolve the > length of > the SAVSYS. Soon as we started blasting the supplemental groups it > started behaving again. The supplemental groups were increasing the > private authorities. PRTPVTAUT was used. > > I fail to see how you would like group profiles and still > feel that an > owner shouldn't be a group profile. > > How would group profiles help in the following case: > Betty should have access to libraries X and Z. > Sam should have access to libraries Y and Z. > Peter should have access to only library X. > Julie should have access to libraries X and Y. > > In our case each library has their own owner and their own > authorization > list. We put Betty in authorization lists X and Y, Sam in Y > and Z, Peter > in X and Julie in X and Y. We use authorization lists instead of the > object itself so that the objects within that library can be > secured with > that same authorization list. Makes it easier to add/ delete > new users > and/or objects within the library. > > > Rob Berendt > -- > Group Dekko Services, LLC > Dept 01.073 > PO Box 2000 > Dock 108 > 6928N 400E > Kendallville, IN 46755 > http://www.dekko.com > > > > _______________________________________________ This is the Security Administration on the AS400 / iSeries (Security400) mailing list To post a message email: Security400@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/security400 or email: Security400-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/security400.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.