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 thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2022 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.