Howard,
My appologies, I was looking at the man pages online and hadn't realised they may not be the same as 2.3.30.
After reading the documentation regarding the subordinate directive I have updated my configuration file as follows, this is pretty much as it was when I encountered the first problem except for the explicit glue overlay reference added to the second, superior, database (ldap backend). My configuration file is now as follows:
database bdb suffix "ou=Extranet, ou=XYZ, dc=xyz, dc=com" subordinate rootdn "cn=Manager, ou=Extranet, ou=XYZ, dc=xyz, dc=com" rootpw secret directory /usr/local/var/openldap-data index objectClass eq
database ldap suffix "ou=XYZ, dc=xyz, dc=com" uri "ldap://dc1"
acl-bind bindmethod=simple binddn="cn=Andrew Kay, ou=Users, ou=XYZ, dc=xyz, dc=com" credentials="secret"
idassert-bind bindmethod=simple binddn="cn=Andrew Kay, ou=Users, ou=XYZ, dc=xyz, dc=com" credentials="secret" mode=none authzId="dn:cn=Andrew Kay, ou=Users, ou=XYZ, dc=xyz, dc=com"
idassert-authzFrom "dn.children:ou=XYZ, dc=xyz, dc=com"
overlay rwm rwm-map objectclass inetOrgPerson user rwm-map objectclass groupOfNames group rwm-map attribute uid sAMAccountname rwm-map attribute cn name rwm-map attribute sn sn rwm-map attribute mail mail rwm-map attribute member member rwm-map attribute *
overlay glue
As previously, the two databases are glued together correctly, and entries from both are retrieved when the base is set to "ou=XYZ, dc=xyz, dc=com" however it appears that entries from the "ou=Extranet, ou=XYZ, dc=xyz, dc=com" portion of the directory (bdb database) are being rewritten. I had hoped that the explicit reference to the glue overlay would mean that the rewriting would only occur to entries retrieved from the remote LDAP directory, in this case a Microsoft Active Directory server.
Is the problem that the rewrite rule is associated with the superior database meaning that it also applies to subordinate databases, in this case I only want it to apply to the superior database not the unified directory as a result of the glueing?
Thanks for your help so far, appologies for not reading the correct documentation.
Andrew
Here's an example query that shows how an entry from the "ou=Extranet, ou=XYZ, dc=xyz, dc=com" subordinate database is getting rewritten:
extranet:/var/log# ldapsearch -x -D "cn=Manager, ou=Extranet, ou=XYZ, dc=xyz, dc=com" -W -b "ou=XYZ, dc=xyz, dc=com" "(cn=Andrew Kay)" Enter LDAP Password: # extended LDIF # # LDAPv3 # base <ou=XYZ, dc=xyz, dc=com> with scope subtree # filter: (cn=Andrew Kay) # requesting: ALL #
# Andrew Kay, Users, XYZ, xyz.com dn: cn=Andrew Kay,ou=Users,ou=XYZ,dc=xyz,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson sn: Kay cn: Andrew Kay uid: Andrew mail: andrew.kay@xyz.com
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1 extranet:/var/log# ldapsearch -x -D "cn=Manager, ou=Extranet, ou=XYZ, dc=xyz, dc=com" -W -b "ou=XYZ, dc=xyz, dc=com" "(cn=John Smith)" Enter LDAP Password: # extended LDIF # # LDAPv3 # base <ou=XYZ, dc=xyz, dc=com> with scope subtree # filter: (cn=John Smith) # requesting: ALL #
# John Smith, Users, Extranet, XYZ, xyz.com dn: cn=John Smith,ou=Users,ou=Extranet,ou=XYZ,dc=xyz,dc=com objectClass: inetOrgPerson sn: Smith
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1 extranet:/var/log#
In the above case the cn and uid attributes of the inetOrgPerson within "ou=Extranet..." are being removed by the mapping.