[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.