2.3.43 included with CentOS. I'll try the latest package. Thanks!
Ah. Actually, I only tried an undefined objectClass, which works. In fact, in the case you're considering, (objectClass=user) contains an invalid value of a valid attribute, while (sAMAccountName=user01) contains an invalid attribute, so the two cases are different. Right now, with HEAD's back-meta for "(&(objectClass=user)(sAMAccountName=user01))" I get "(&(?objectClass=user)(!(objectClass=*)))". Let me check a bit more.
I have provided another round of fixes. One of them affects back-meta (map.c, ITS#6818); another affects filter handling (ava.c); finally, another affects slapo-rwm when used in conjunction with back-ldap (rwmmap.c). Now the issue should be definitely fixed. Please test.
p.
Thanks p.!
I've compiled and tested with the latest from HEAD. Both back-ldap and back-meta work in a transparent proxy configuration as expected, without the need for extra AD schema definitions.
/Chris
On Mon, Jan 31, 2011 at 3:55 PM, masarati@aero.polimi.it wrote:
2.3.43 included with CentOS. I'll try the latest package. Thanks!
Ah. Actually, I only tried an undefined objectClass, which works. In fact, in the case you're considering, (objectClass=user) contains an invalid value of a valid attribute, while (sAMAccountName=user01)
contains
an invalid attribute, so the two cases are different. Right now, with HEAD's back-meta for "(&(objectClass=user)(sAMAccountName=user01))" I get "(&(?objectClass=user)(!(objectClass=*)))". Let me check a bit more.
I have provided another round of fixes. One of them affects back-meta (map.c, ITS#6818); another affects filter handling (ava.c); finally, another affects slapo-rwm when used in conjunction with back-ldap (rwmmap.c). Now the issue should be definitely fixed. Please test.
p.
openldap-technical@openldap.org
-
Christopher Cprek -
masarati＠aero.polimi.it