Anonymous_User Absent Member.
Absent Member.
373 views

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

Labels (1)
0 Likes
6 Replies
Anonymous_User Absent Member.
Absent Member.

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

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.
0 Likes
Anonymous_User Absent Member.
Absent Member.

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


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

0 Likes
Anonymous_User Absent Member.
Absent Member.

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

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.
0 Likes
Anonymous_User Absent Member.
Absent Member.

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

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...
0 Likes
Valued Contributor.. sri4netiq Valued Contributor..
Valued Contributor..

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

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

0 Likes
Knowledge Partner
Knowledge Partner

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

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.

 

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.