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(a)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.

Howard, Thanks for your response, as a result of checked out the head tag within CVS, compiled and tested with the same configuration as before. The glue overlay and rewrite rule now appear to be functioning correctly when entries retrieved from the directories are rewritten, the inetOrgPerson entries within the OpenLDAP portion of the unified directory remain inetOrgPerson entries with all their attributes (previously attributes referenced by the rewrite overlay were being removed) and all user entries within the Active Directory portion are rewritten correctly as inetOrgPerson entries. There does appear to be a problem with searching the directory using an attribute that is being rewritten. I have to directories being glued together, ou=XYZ, dc=xyz, dc=com Microsoft Active Directory (ldap backend) ou=Extranet, ou=XYZ, dc=xyz, dc=com OpenLDAP bdb (subordinate) If I retrieve an entry from each directory using the cn attribute and the base set to "ou=XYZ, dc=xyz, dc=com", I get the two directory entries correctly rewritten (in the Active Directory case) and correctly left alone (in the OpenLDAP case): extranet:~# 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(a)xyz.com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 extranet:~# 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 cn: John Smith sn: Smith uid: john.smith userPassword:: am9obi5zbWl0aA== # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 In practice I want to use the uid attribute to retrieve the directory entry: extranet:~# ldapsearch -x -D "cn=Manager, ou=Extranet, ou=XYZ, dc=xyz, dc=com" -W -b "ou=XYZ, dc=xyz, dc=com" "(uid=Andrew)" Enter LDAP Password: # extended LDIF # # LDAPv3 # base <ou=XYZ, dc=xyz, dc=com> with scope subtree # filter: (uid=Andrew) # 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(a)xyz.com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 extranet:~# ldapsearch -x -D "cn=Manager, ou=Extranet, ou=XYZ, dc=xyz, dc=com" -W -b "ou=XYZ, dc=xyz, dc=com" "(uid=john.smith)" Enter LDAP Password: # extended LDIF # # LDAPv3 # base <ou=XYZ, dc=xyz, dc=com> with scope subtree # filter: (uid=john.smith) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 The query works perfectly against the Active Directory portion of the unified directory, but doesn't return the user from the OpenLDAP portion of the directory. If a rerun the last query but set the base explicitly to the OpenLDAP portion of the directory: extranet:~# ldapsearch -x -D "cn=Manager, ou=Extranet, ou=XYZ, dc=xyz, dc=com" -W -b "ou=Extranet, ou=XYZ, dc=xyz, dc=com" "(uid=john.smith)" Enter LDAP Password: # extended LDIF # # LDAPv3 # base <ou=Extranet, ou=XYZ, dc=xyz, dc=com> with scope subtree # filter: (uid=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 cn: John Smith sn: Smith uid: john.smith userPassword:: am9obi5zbWl0aA== # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 I get the user, but unfortunately can't get the user if the base is set to the unified directory base. It seems to work correctly if I am dealing with: - an attribute that is the same in both directories (cn for example) - an attribute that is rewritten (uid works against the Active Directory portion, although it must be rewritten as SAMAccountName when performing the underlying query) - when I explicitly set the base to the OpenLDAP directory portion and then perform a query referring to an entry within it I hope I have explained the problem I'm having in sufficient depth, I can send you the results of running slapd in "trace, args, filter, parse" debug mode if you wish. Thanks again for your help so far. Andrew

Howard Chu wrote: I'm not going to fix it in the very short term; however I will, at some point (could be right after Xmas or so). If you really need to implement exactly that, you could, at the expense of an extra layer, using back-meta instead of glue. In that case, rwm capabilities are still hard-wired in back-meta. Beware that back-meta in 2.3 may suffer from some limitations I'm fixing right now in HEAD (not committed yet, though). As soon as that's over, I'll port everything to 2.3 (it's safe, we already do in custom code derived from 2.3); it's going to be a matter of days (it __HAS__ to be ;). Cheers, p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

Howard Chu wrote: One way to test this would be to rework test039 and test047 to use separate instances of slapo-rwm for each database, instead of a global one. Those tests share some data with test035 and test036, dedicated to back-meta. If not present yet, all tests could be modified to include relevant schema mapping. Right now, for sure they make extensive use of DN rewriting. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

Andrew Kay wrote: You checked out the entire tree, or just a few specific files? That's only part of the fix; you also need an updated overlays/rwm.c file (1.78). No, you're not jumping the gun. The current HEAD code works for me in all of the existing test scenarios as well as some similar to what you described. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/