Symantec Access Management

  • 1.  Defining class of service

    Posted Jun 04, 2018 04:01 PM

    I am converting our current directory (not CA Dir) to CA Dir.  We make extensive use of class of service and am working on converting the definitions over.  The question I have, which doesn't seem clear to me from the doc, can I set up the class of service to be only valid for a particular branch of the directory?  Or is the definition across the entire DIT and either fires or doesn't depending on the attr/value combo on the look up of the entry?

     

    Thanks in advance



  • 2.  Re: Defining class of service
    Best Answer

    Posted Jun 06, 2018 05:28 PM

    The class of service is defined for the DSA and fires or not based on the attrib/value combo of the entry. So that's the basic understanding, but that's where the fun just begins.

    CA Directory is very powerful and allows you to get as complex as you want to. If you wanted to apply a class of service only to a specific branch of the directory, you could set up a distributed DSA so that the base DIT is served by one DSA but another branch is served by another DSA with the class of service entry for it. 

    There are a number of benefits to a distributed DSA, but it also takes careful planning. Typically class of service isn't a reason people do it, but if you are on the fence and you need a class of service active for only one part of the DIT, then it could tip the scales.



  • 3.  Re: Defining class of service

    Posted Jun 07, 2018 11:20 AM

    Thanks for the advice Jason.  I don't see how that will work for us as we have approx 258 classes of service defined in our current Oracle DSEE instance.  Let me give a little more info as maybe that will trigger something in your mind that might work.  Our DIT is for a state.  So for example the main branch is "ou=government,o=state name" and under that are all the state agencies and counties.  So we have "ou=state agency 1,ou=government,o=state name", "ou=state agency 2,ou=government,o=state name", ..., "ou=some county,ou=government,o=state name" which is around 258 branches under the ou=government.  Any account in those sub-branches have the ou of that sub-branch.  We then created classes of service that is specific to each sub-branch that defines 2 virtual attributes that each account needs but the values are specific to that branch.  The issue with replicating that functionality on CA Directory is that it requires the cos-attr to be single valued which ou is not.

     

    Without a fairly easy replacement for our DSEE class of service, we're looking at just going without and actually placing the "real" attribute on every account.

     

    Thanks

    Sam



  • 4.  Re: Defining class of service

    Posted Jul 31, 2018 04:14 PM

    Hi, it might be a long shot, but have you looked at the "Views" concept in CA Directory?

     

    Ways to Use Views - CA Directory - 14.0 - CA Technologies Documentation 

     

    Here's an excerpt that is pretty similar to what you're looking for:

     

    Using Views for Data Normalization (Class of Service)

    Views can be useful if your directory contains highly repetitive information. For example, each user entry contains office location and contact details which are identical for many users. This uses a lot of space for caching and backups and is complex to update.

    To solve this, use views in the following way:

    1. Create a separate subtree to hold office information including a unique office identifier in each entry.
    2. Replace the repetitive office information with the related office identifier in each user entry.
    3. Create a view so that an entry being returned will also perform a lookup of the office details and include them in the user entry.

     

    HTH.

    Welington Strutz.



  • 5.  Re: Defining class of service

    Posted Aug 01, 2018 10:20 AM

    Thanks Welington.  I did look at views before but I appreciate you chiming in on this thread.  The issue with views is that you need to use the dn of the view in the search base.  In a real ODSEE class of service, just by the act of looking at a users' account, the directory can return other attributes/values that don't physically reside on the account.  We're thinking that we will need to change all our class of services in ODSEE to have physical attribute/value pairs placed on all the accounts.


    Sam