On Feb 7, 2009, at 3:24 AM, Pierangelo Masarati wrote:

mhardin@symas.com wrote:

...

Some additional information: Some objects being returned from AD have very large multi-valued attributes (for example, member). AD is returning them in the ";range" format, but they are not getting past back-meta. For example, a direct search for the object in AD will return stuff like this: member;range=0-1499: CN=Alice Bar,OU=My-Company-Accounts,OU=User Accounts,OU=Common,DC=my-company,DC=com but doing the same search through slapd/back-meta using the same credentials, the member attribute is not displayed at all. There are no attribute maps in place that would cause this.

If this is the cause, then back-meta should try to register the attribute name as a "proxied" attribute type, and slapd should be unable to correctly decode it because it contains a "=". Back-meta in the end should just ignore the whole attribute.

Thanks, Pierangelo. That led me to ITS#5472 and several other postings about the same issue. In particular:

[Petter Reinholdtsen said]

...

This notation is not handled by ldap_get_values(), and it return NULL, resulting in a group with zero members.

[Kurt Zielenga replied] This is proper and well-intended behavior. You asked for values of returned under the attribute description "member", not the (invalid) attribute description "member;range=0-1499". Two attribute descriptions which share the same attribute type do not necessarily refer to the same attribute.

This clearly explains the assertion pcache is reporting. Well-intended behavior or not, there is a problem here because pcache takes down the server whenever it encounters attribute values of this form. Given Kurt's later comments about the provenance and ancestry of this "standard", it seems to me the right thing for back-meta (and back- ldap, for that matter) to do might be to just make the attribute completely disappear. Appropriate messages output in debug mode or at a particular log level might announce the fact that the attribute is being disappeared. The pcache overlay, for its part, instead of asserting, might instead log a warning and refuse to cache the object.

Sound reasonable?

-Matt

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

---