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.