Jon C Kidder wrote:
> I have a very rigid LDAP client and I need to present the entryUUID as both
> entryUUID and nsUniqueID in the user records. I have chosen to do this with
> the dynlist overlay rather than build a process to replicate the data. I've
> had the overlay deployed for quite some time and have several dynamically
> generated attributes. However, I'm finding that this doesn't work with
> entryUUID? Here's the relevant configuration:
>
> dn: olcOverlay={0}dynlist,olcDatabase={2}mdb,cn=config
> olcDlAttrSet: {4}aepAuxUser nsUniqueIDURL nsUniqueID nsUniqueID:entryUUID
>
> dn: uid=TestEmployee,ou=Employees,ou=Users,dc=global,dc=aep,dc=com
> nsUniqueIDURL: ldap:///uid=
> TestEmployee,ou=Employees,ou=Users,dc=global,dc=aep,dc=com?entryUUID?base?(objectClass=*)
>
> When I execute a search on the above user DN the nsUniqueID attribute doesn't
> appear but all of my other dynamic attributes do appear and have correct
> values. I have modified both of the above entries replacing entryUUID with
> any number of attributes and nsUniqueID will suddenly appear as expected and
> contain the value of the attribute chosen. I can't get this to work using
> entryUUID. I have not tried it with other operational attributes yet. Is
> this because the overlay doesn’t work with operational attributes? Is this a
> bug?
Looks like operational attributes are excluded. That has been the behavior
since the original code was
committed in 2005. I suppose you'd have to ask Pierangelo what the rationale
was.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
