aux class attributes in LDAP driver (eDir to OID)?


eDir to OID via LDAP.

We have extended schema/aux class attributes, as does OID

I believe, because they're aux class attributes, we don't (or can't) put
them into the schema mapping policy?

And:

How to do a matching policy based upon the aux class attribute?


--
kjhurni
------------------------------------------------------------------------
kjhurni's Profile: https://forums.netiq.com/member.php?userid=322
View this thread: https://forums.netiq.com/showthread.php?t=48533

  • Put aux class associated attributes directly under the effective class of
    the object type. For example, put your attribute under the User class.

    Aux classes themselves do not go into the filter because there is nothing
    for which the IDM engnine can register since those are not real objects in
    eDirectory. Their attributes, however, can be listed in the filter under
    whatever effective class.

    Good luck.

  • ab;233290 Wrote:
    > Put aux class associated attributes directly under the effective class
    > of
    > the object type. For example, put your attribute under the User class.
    >
    > Aux classes themselves do not go into the filter because there is
    > nothing
    > for which the IDM engnine can register since those are not real objects
    > in
    > eDirectory. Their attributes, however, can be listed in the filter
    > under
    > whatever effective class.
    >
    > Good luck.


    Ah, okay, so I guess that makes sense.
    Does this, by any chance, screw up (for example) a Creation Policy.

    Example:

    We create a user in eDir, and have the Null/loopback driver plop in our
    aux class attribute.

    Then in my OID driver, I have it write directly to destination vs.
    letting the schema mapping handle it (because the object has to be in
    OID first, before you can add the aux class--just like eDir).

    ??

    Thanks!


    --
    kjhurni
    ------------------------------------------------------------------------
    kjhurni's Profile: https://forums.netiq.com/member.php?userid=322
    View this thread: https://forums.netiq.com/showthread.php?t=48533

  • On 09/03/2013 02:54 PM, kjhurni wrote:
    >
    > ab;233290 Wrote:
    >> Put aux class associated attributes directly under the effective class
    >> of
    >> the object type. For example, put your attribute under the User class.
    >>
    >> Aux classes themselves do not go into the filter because there is
    >> nothing
    >> for which the IDM engnine can register since those are not real objects
    >> in
    >> eDirectory. Their attributes, however, can be listed in the filter
    >> under
    >> whatever effective class.
    >>
    >> Good luck.

    >
    > Ah, okay, so I guess that makes sense.
    > Does this, by any chance, screw up (for example) a Creation Policy.
    >
    > Example:
    >
    > We create a user in eDir, and have the Null/loopback driver plop in our
    > aux class attribute.
    >
    > Then in my OID driver, I have it write directly to destination vs.
    > letting the schema mapping handle it (because the object has to be in
    > OID first, before you can add the aux class--just like eDir).


    That's not how eDir is; if you add the aux class's attribute during
    creation the aux class will be automatically added before sending the
    operation to eDirectory, and you can do this during a creation or modify.

    Regrading the validity of writing directly to the destination, I'm not
    sure the purpose of schema mapping is fully understood. I do not recall
    perfectly whether or not a write directly to the destination goes through
    schema mapping, but assuming the write takes place somewhere before the
    schema mapping policyset I do not know why it would not, whether written
    directly or as part of the current (or previous, or subsequent) operation.
    Either way, I think the right way to know what is happening is to
    (surprise surprise) see a trace. If OID does need to have a create happen
    without aux classes before the aux class's attributes can be added then
    we'll see that; if not (if it's like eDir) then this should all be pretty
    simple.

    Good luck.
  • On 03.09.2013 22:54:03, kjhurni Wrote:
    >
    > Does this, by any chance, screw up (for example) a Creation Policy.
    >
    > Example:
    >
    > We create a user in eDir, and have the Null/loopback driver plop in
    > our aux class attribute.
    >
    > Then in my OID driver, I have it write directly to destination vs.
    > letting the schema mapping handle it (because the object has to be in
    > OID first, before you can add the aux class--just like eDir).


    It seems odd that this is required, I thought we went through something
    like this recently in this forum and the result was that the real error
    was that the add event lacked an add Object Class attribute for the aux
    class in the destination system.

    AFAIK, IDM only auto-adds the aux class when the event passes through
    the the publisher sync filter (ie when writing to eDirectory).

    When sending events to the application (OID) you have to manually
    handle this in driver policy (I'd guess in sub-ctp)

    However, if this is really the case that aux class attributes can only
    be set on modify.

    Why not just have a command transform which strips any aux class
    modifies from the add and appends them after the add event?

    That will work fine as long as the add processes correctly.

    Any out of band operations (direct writes, queries etc) to the
    application will go through schema mapping unless they are initiated
    from the application namespace (ie input or output transforms)

    --
    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below...
  • Hello,

    Account sync process among IDM and backend LDAP do not work as expected. When IDM pushes and update onto a record making it active / in-active a custom attribute is getting populated. Need to know where and how that being handled in IDM. 

    userAPP / designer / iManager ???

    Inputs appreciated !

    Sri

  • Tagging onto an existing thread with a different question but vaguely related may not be super helpful in terms of getting responses.

    However, this is likely a driver issue.

    That you ask the question "userAPP / designer / iManager?" makes me think you are not super familiar with this.

    Take care in actions you take until you understand what you are doing. (Very easy to break things as an Admin...)

    Do you know how to find the engine trace?  Do you know how to read it?  Look for the trace file for the LDAP driver of interest, generate this test case, and search the trace to find the event.

    Open a new thread and post the trace into the message and we can try to help you.