Sorry for the out-of-sequence reply. I'll test and let you know what I find.
Cheers, -Matt On Feb 7, 2009, at 8:53 AM, [email protected] wrote: > On Feb 7, 2009, at 3:24 AM, Pierangelo Masarati wrote: > >> [email protected] 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: [email protected] >> ----------------------------------- >> > >
