resolving attributes from a different OU- best approach?

[Martin Haase]

Hi Sean,

Am 09.02.2015 um 18:26 schrieb Flannery, Sean:
> but I'm now wondering if I can just chain together DataConnectors and
> handle this via the Dependencies support, where one Ldap Data
> Connector loads the full profile of the person, including the officeID
> attribute (which is a DN to an office object) and another Ldap Data
> Connector loads the office from the officeID attribute and gets its
> description field and releases the value as a generated attribute on
> the person, i.e. the person has an attribute value for office as "East
> Cairo" rather than "ou=a80cb6744,ou=offices"
we did this in a number of projects. As Scott said, you can chain
DataConnectors via their dependencies. However, as far as I know you
cannot, query for the (base-)DN directly, so you'd need to split your
attribute's value (RegexSplit) and then put those variables in the
filter, like:

      <resolver:Dependency ref="splitOfficesAttribute" />
        <dc:FilterTemplate>
            <![CDATA[
               
(&(objectClass=OfficeObject)(ou:dn:=$splitOfficesAttribute.get(0))(ou:dn:=offices))
            ]]>
        </dc:FilterTemplate>
        <dc:ReturnAttributes>description</dc:ReturnAttributes>

This does work with OpenLDAP, I'm not sure if other LDAP implementations
support the "ou:dn:=value" syntax.

Regards
Martin
>
> Does this question make sense?  How do most people handle loading data
> from a different OU?  (I'm guessing the answer is- most people have
> that data in a readable format on the person object, but unfortunately
> that's not an option for the schema / data structure we have).

-- 
Dr. Martin Haase, Solutions Engineer

DAASI International GmbH        
Europaplatz 3                   
D-72072 Tübingen                
Germany                    

phone: +49 7071 407109-6
fax:   +49 7071 407109-9  
email: martin.haase at daasi.de
web:   www.daasi.de

Sitz der Gesellschaft: Tübingen
Registergericht: Amtsgericht Stuttgart, HRB 382175
Geschäftsleitung: Peter Gietz


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2227 bytes
Desc: S/MIME Cryptographic Signature
Url : http://shibboleth.net/pipermail/users/attachments/20150210/35a81513/attachment-0001.bin