Conference utrop1::linkworks_v3_2

114.0. "system/OU-Defined AccRts/obj-spec ACLs" by FRAIS::SPALT () Tue Feb 11 1997 19:11

    assuming one starts with 5 new accessrights and wants to use/assign
    them in 10 OUs. first thing is that it would be nice a have an extra
    adm-tool in AM which allows to select one AR and chose from a list
    of available OUs and to select a few and thereby assign the AR to the
    selected OUs. (easier than going into 10 OU and assinging the ARs every
    time). second: i assume this gives me still 5 AR in the system.
    
    Now i wanna modify 2 of the 5 ARs in every OU *THE SAME WAY* (adding an
    extra OU by name - which is not possible in CM). Again i need to go
    in each of the OUs (10 times) doing the exact same ACL-Edit 20 times
    (modifying 2 ARs per OU). the other way around it would be 2
    Modifications with the ACL editor and 2 assignments of 10 selected OUs.
    now what: do i have 7 ARs in the system (5 from CM, 2 from AM)
    or 25 ? (5 from CM, 10 version (one per OU) of AR1, 10 vers of AR2) ?
    
    even if there are 25, will this cause problems (performace-wise)
    dont hope so as we are still in the definition phase of AR, we havent
    actually used them and these are not assigned to any objects yet.
    
    basically the question is (assuming we'll have 10 AR and 100 OUs,
    each OU modifying the 10 OUs, ending up with 1000 ARs..)
    - is the definition a point of concern 
    - or is the system-performance more affected by actually using these
    defined AR (as long as the OU-specific-AR are not further modified and
    becoming "obj-Specific" it should matter that much. instead of having
    object using/pointing to 10 system-defined ARs, objects can point to
    a larger number of OU-defined ARs (1000). are the OU-specific ARs
    stored in AMDB ? (therefor no way to extract/export to another system)
    - really matters if one is modifiying them further (adding people by
    name/role and thereby making the AR "object speficic") cause as far as
    i can guess then the ACL is stored with the/*EVERY* object - compared with
    a system/OU-defined AR which multiple objects just points to and is stored
    in AM/CM (just once in the system).
    
    am i right..  paule
    

Hi paul and to all,

I think you are right. The similar problem is also discussed in note 102.
We need admin/config Function they are easily to use.

Thanks

Toni

This is changed becasue of the feedback we got from the introduction
event here in Utrecht  a while ago.
Access rights are now inhereted in the OU structure, so if you assign
a new access right to an OU, all lower OU's will have that AR automatically.

Hope that helps,
Jos

    ok -fair enough - this helps if you have ONLY system ARs.
    if one needs to do the same modifications to N OUs, it would be
    easier to have an AR-icon in ADM to modify an AR and then assign it
    to various OUs (and maybe also have an MCC-Table for it)
    
    Main issue: are OU-specific ARs referenced by a pointer with/at the
    object or does the object carry an ACL (is OU-specific AR instanciated
    already (in the OU) and therefor also for the object ??)  thx paule

Paule,

Only object specific ACL's are stored with the 'carried around' with the object.
If you define a new Access Right and use it in just one OU, it is still a
system wide access right and the object only carries a pointer to this defined right.

Jos

    thx jos - that was my understanding, too
    still leaves the comfort on the table to modify hundreds of ARs..

who knows what happens next...

    why are user-defined roles not available in CM when editing access
    rights.. would really help - use 1 AR for all OUs instead of
    modifying this AR for all OUs (thereby adding always the same role).
    if this is not possible, then how about this:
    maybe one could have some more (std-) roles with the std-product
    that would allow this (one could only adapt the description).
    paule

   What you ask for is in fact a Change Request (IPMT).
   Please issue one describing this needed change.
   Many persons are involved and trying to achive this via Notes
   would not work out well. The 322 release will not have this
   requested functionality.

   regards,

   joop visser