John Du jjohndu@gmail.com writes:

Hi,

We have been running OpenLDAP 2.2.13 on RHEL4 for a few years without problems. We recently upgraded OpenLDAP to 2.4.11 to use the multi-master capability. After upgrade, we are having 2 problems with the new version.

1. We have an attribute c in the ou=People sub-tree. The value can

be either US or CA. Now if we search "c=US" or "c=CA", we do not get any matches. But if we do "c=U*", it finds all the c=US entries. Same thing happens to c=C*.

2. LAM 2.5.0 (LDAP Account Manager) cannot browse the schema on the

new server. It says "Unable to retrieve schema". LAM worked fine with OpenLDAP 2.2.13.

I would appreciate any information that would help us resolve the problem.

Please provide some more information, i.e. configuration of indexes and access rules to cn=subschema, as well as examples of search strings.

-Dieter

John Du writes:

1. We have an attribute c in the ou=People sub-tree. The value can be

either US or CA. Now if we search "c=US" or "c=CA", we do not get any matches. But if we do "c=U*", it finds all the c=US entries. Same thing happens to c=C*.

My guess: You added 'index c' to slapd.conf, but did not index your existing data. Stop slapd, run sbin/slapindex, restart slapd. Substring match of just one letter worked anyway because it does not use the index.

2. LAM 2.5.0 (LDAP Account Manager) cannot browse the schema on the

new server. It says "Unable to retrieve schema". LAM worked fine with OpenLDAP 2.2.13.

No idea. I'd check the slapd log from loglevel 256 or 768. That's the default syslog level, or you could run slapd -d256 or -d768 ... to log to stderr. Note what requests LAM sends, and check the corresponding error code/description (err=... text=...) against RFC 4511, Appendix A.

John Du wrote:

I fixed the two problems.

Problem one was fixed by adding an "access to dn.subtree="cn=SubSchema by * read".

This should be sufficient since the subschema subentry is a single entry:

access to dn.base="cn=Subschema" by * read

I thought the root DN is not subject any access control rules but that does not seem to be the case.

Indeed no ACLs are applied when effectively binding as rootdn. What makes you think that this is not the case.

I do not understand why I have to add the index for the new server but not for the old one.

The problem is if you added an index directive to slapd.conf but did not re-index slapd looks into the index database file and the old entries are not there yet. So the entry is not returned as search result. This might make you think that access control prevents the entry from being returned.

Also be sure that all the database files have the right ownership/permissions when manually re-indexing them.

Ciao, Michael.