|
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 "John Earl" <john.earl@xxxxxxxxxxxxx> Sent by: security400-bounces@xxxxxxxxxxxx 05/26/2004 07:50 PM Please respond to Security Administration on the AS400 / iSeries <security400@xxxxxxxxxxxx> To "Security Administration on the AS400 / iSeries" <security400@xxxxxxxxxxxx> cc Subject RE: [Security400] Documenting / Managing iSeries security OK, I've been chewing on this one for about a week now, and I just have to get my .02 in on it... > I abhor supplemental groups. Had a couple of problems > with that: > > 1) Someone started assigning a 'owner' profile as a > supplemental group > profile. This 'owner' profile had the special authority > of *ALLOBJ. Thus > all the users with this supplemental group had *ALLOBJ. > Cardinal rule #1-'Owner' profiles should not have any > special authorities. [jte] I agree whole heartedly that Owner profiles should not have any special authority - but this example demonstrates a problem with Owner profiles being _any kind_ of group profile, not a specific problem with supplemental group profiles. (IMHO) > 2) Supplemental groups significantly increase the length > of your SAVSYS. > Increased ours from 4 minutes to 44 minutes. [jte] This is sort of surprising to me. I can see where a large number of private authorities could significantly increase the SAVSYS time - private authorities are stored in the User profile object, and so SAVSYS could have a lot more work to do - but again this would be a problem related to assigning private authorities to objects, and not specifically a problem of Group Profiles. If it is the case that Supplemental Group Profiles increase SAVSYS time, than this is new news to me. > 3) There is a limit to how many supplemental groups one > user may be > assigned to. We were actually hitting this. [jte] Yes the limit is 15. And there is some evidence to suggest that as the number of Supplemental Group profiles attached to a user profile grows, the overall system performance _could_ degrade because of the increased number of security checks that are required (ex, Does GROPU have authority? No, then does SupGroup1 have authority? No.... all the way through the groups until you get to *PUBLIC. :( ), so this is a "performance" reason not to over use Supplemental Group profiles. > Better to use authorization lists wisely. [jte] This is the part that that really baffled me. Group profiles (including supplemental groups) and authorization lists are not an either/or proposition - the proper use of both tools will give you better security than total reliance on one or the other. Group Profiles are used to bunch users with similar job functions together. Authorization lists are used to bunch objects with similar usage rules together. I don't really get how I could use Autl's effectively without using groups (and supplemental's). jte -- John Earl | Chief Technology Officer The PowerTech Group 19426 68th Ave. S Seattle, WA 98032 (253) 872-7788 ext. 302 john.earl@xxxxxxxxxxxxx www.powertech.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-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.