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

Parents
  • 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.
Reply
  • 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.
Children
No Data