brett.maxfield@gmail.com wrote:

--0016e65206024a6d9d0462d5c0d0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

I have re-tested with recent RE24 and this still happens.

Assuming the config (database meta, and map instead of rwm-map shows similar problem) :

database ldap suffix "c=AU" uri "ldap://127.0.0.1:390/c=AU"

You messed things up a little bit: back-ldap does not allow the DN part of the URI.

overlay rwm

rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute givenName * rwm-map attribute *

rwm-map objectclass inetOrgPerson * rwm-map objectclass organisationalUnit *

s/organisationalUnit/organizationalUnit/: this raises a warning.

rwm-map objectclass organization * rwm-map objectclass country * rwm-map objectclass *

I have a standard LDAP with standard inetOrgPerson style schemas on ldap:// 127.0.0.1:390/c=AU with some dummy data, and when i query the source directory i get sensible results:

suse:/usr/local/etc/openldap # ldapsearch -H ldap://127.0.0.1:390 -x -b 'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' '*' # extended LDIF # # LDAPv3 # base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree # filter: (objectclass=*) # requesting: * #

# test00496, support, openldap, AU dn: cn=test00496,ou=support,o=openldap,c=AU objectClass: inetOrgPerson cn: test00496 givenName: test00496 uid: test00496 sn: test00496lname displayName: test00496 test00496lname userPassword:: bm92ZWxs

# search result search: 2 result: 0 Success

# numResponses: 2 # numEntries: 1

When i query the meta directory, i get no attributes (* or + or *,+, in the requested attributes all return no attributes as below) :

ldapsearch -H ldap://127.0.0.1:391 -x -b 'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' '*' # extended LDIF # # LDAPv3 # base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree # filter: (objectclass=*) # requesting: * #

# test00496, support, openldap, AU dn: cn=test00496,ou=support,o=openldap,c=AU

# search result search: 2 result: 0 Success

# numResponses: 2 # numEntries: 1

But if i query the meta directory explicitly for some attributes (no * +), it works, i get :

ldapsearch -H ldap://127.0.0.1:391 -x -b 'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' cn sn firstName # extended LDIF # # LDAPv3 # base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree # filter: (objectclass=*) # requesting: cn sn firstName #

# test00496, support, openldap, AU dn: cn=test00496,ou=support,o=openldap,c=AU cn: test00496 sn: test00496lname

# search result search: 2 result: 0 Success

# numResponses: 2 # numEntries: 1

So i conclude then that the default attribute lists of *, +, or *,+ are somehow being lost by backend meta or overlay rwm ?

Probably * and + (or *,+) should be expanded to the list of user or administrative attributes (respectively) by meta/rwm first, specifically those that are allowed by "map attribute" lines, before being handed to the real directory (helpful to performance if the backend directory has many attributes, that the meta directory is not interested in).

This is also why attributes don't appear in a GUI browser for me, if i am using a GUI browser, as they commonly use *,+ as their default.

Well, if you don't request any attribute, those that are mapped appear. I've modified slapo-rwm to pass thru special attribute names ("*", "+", "1.1") in order to defer their mapping when results are returned. This looks simpler than detecting whether non-mapped attrs are filtered and, in tat case, replace "*" by the mapped attributes, although the latter could be an optimization.

A fix is in HEAD (affecting back-meta and slapo-rwm independently). Please test. Unfortunately it seems to be too late for OpenLDAP 2.4.14.

p.

Ing. Pierangelo Masarati OpenLDAP Core Team

SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: ando@sys-net.it -----------------------------------