Pierangelo Masarati wrote:
I'll note that unless you defined it yourself, "dn" is
not a valid
attribute name. I suspect your back-sql meta-data generates an entry
that doesn't pass schema checking, otherwise I don't see a chance for
that error to be reported.
Pierangelo,
the objects are inetOrgPerson objects, the full object looks like this
# robb(a)example.org,
sql.example.org
dn: uid=robb(a)example.org,dc=sql,dc=example,dc=org
objectClass: inetOrgPerson
cn: Robert Brooks
uid: robb(a)example.org
mail: robb(a)example.org
I believe the only required attribute for such an object is cn. A
similar search against a non back-sql part for the tree (see below) does
not show an error
ldapsearch -x -b "ou=people,dc=example,dc=org" "cn=Robert Brooks" dn
cn
objectclass
# robb, people,
example.org
dn: uid=robb,ou=people,dc=example,dc=org
cn: Robert Brooks
objectClass: account
objectClass: posixAccount
objectClass: shadowAccount
Unfortunately seems some software doesn't understand it doesn't need to
request dn explicitly hence I noticed this.
In any case, since the behavior you report is very data and
meta-data
dependent, you don't provide enough info for debugging, and at a very
first glance this is not indicative of a software bug.
Let me know what you'd like, I thought this one may well reproduce on
any back-sql, so didn't spray the ITS with extraneous information.
Regards,
Rob
--
Robert Brooks, Network Manager, Cable & Wireless UK
<robb(a)wtg.cw.com>
http://wtg.cw.com/
Tel: +44 (0)20 7339 8600 Fax: +44 (0)20 7339 8601
- "What was your username again?" - BOFH -