Wednesday, August 05, 2009

 

VDE Shadow Object LDIF

If you are using the OVD Shadow Joiner feature then you will need to add the vdeShadowObject object class to the directory hosting the shadow objects. Here is a little LDIF file for just such a need...

# Description: contains vdeshadowobject vdeprimaryref for use with shadow joiners
#
dn: cn=subschemasubentry
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.17119.1.0.1 NAME 'vdeprimaryref' DESC 'This attribute contains an MD5 hash of a primary adapter' EQUALITY 'caseIgnoreMatch' SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' X-ORIGIN 'user defined' )
-

dn: cn=catalogs
changetype: modify
add: orclindexedattribute
orclindexedattribute: vdeprimaryref
-

# ObjectClass Definitions
dn: cn=subschemasubentry
changetype: modify
add: objectclasses
objectclasses: ( 1.3.6.1.4.1.17119.1.1.1 NAME 'vdeShadowObject' DESC 'This object is used by VDE Shadow Joiner to store a shadow object to a primary entry in another directory. This objectclass normally used in conjunction with the extensibleObject object class to hold local attributes. vdeprimaryref is a hash of a DN that points to a primary object in an alternate adapter.' SUP top AUXILIARY MUST ( vdeprimaryref ) MAY ( description ) )
-

Labels: ,


Comments:
Has anyone actuall got the shadow join working?
The docs are not that precise about how one gets to see the shadow entries.
 
yes, i absolutely have had the shadow joiner working. It really works quite well. The shadow entries are merged on OVD and available through the shadow adapter configured to perform the join. the shadow object does not need to exist to return an entry. The shadow entry will be created on the fly if values are saved to the attributes hosted by the shadow part of the join adapter.
 
Post a Comment

Links to this post:

Create a Link



<< Home

This page is powered by Blogger. Isn't yours?