[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Still unable to configure glue and rwm overlay correctly



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.