[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: slamd templates making stange errors

matthew sporleder wrote:
On 5/1/06, matthew sporleder <msporleder@gmail.com> wrote: 
Is there was a repository of slamd tests/templates used to test slapd?
 (I've seen results posted, but never a discussion on how they were
reached)  I am having good luck with my search tests, but my
add/delete templated tests always give:

err=20 matched="" text="attribute 'objectClass' provided more than once"

which seems a little odd since objectClass will almost always be
repeated on an add.
I don't think this is an openldap issue since I can follow my template
with 'ldapmodify', but I was just wondering if anyone was publishing
this sort of thing.

Thanks,
_Matt


Well, it would appear that openldap might be throwing error=20 a
little too liberally:

No, SLAMD is generating an invalid ASN.1 encoding of the entry here. Note that X.500 defines an "entry" to be a SET of attributes; mathematically, in sets, elements are unique - can only appear once. This is explicitly stated in X.501 "All attributes in an entry shall be of distinct attribute types." The ASN.1 definition for the Add operation (RFC2251) says:

       AddRequest ::= [APPLICATION 8] SEQUENCE {
               entry           LDAPDN,
               attributes      AttributeList }

       AttributeList ::= SEQUENCE OF SEQUENCE {
               type    AttributeDescription,
               vals    SET OF AttributeValue }

The proper way to encode a single attribute with multiple values is to include the "type" once, followed by all of the multiple values. SLAMD is sending the type multiple times, with one value each time, which is clearly an invalid encoding.


Here's my tcpdump of ldap traffic:
slamd:
(hex deleted, ascii formatted)
....;uid=test.16@example.net,ou=foo,o=bar,dc=example,dc=net0...
0...objectClass1...top
0...objectClass1...person
0%..objectClass1...organizationalPerson
0...objectClass1...myLocalPerson
0...objectClass1...inetOrgPerson
0...l1...west
0...myLocald1...16
0...cn1...User.16
0...sn1...foo
0...uid1...test.16@example.net
0...userPassword1...password
0...givenName1...test.16@example.net
0;..postalAddress1*.(test.16@example.net.FOOBAR.LANE,.PHOENIX,.AZ
0...postalCode1...16666
0...parentlogin1...boofoomoo

ldapmodify:
(hex deleted, ascii formatted)
....@uid=test.matt.01@example.net,ou=foo,o=bar,dc=example,dc=net0
..T0O..objectclass1@..top..person..organizationalPerson..inetOrgPerson..myLocalPerson 

0...l1...east
0...myLocalid1...01
0...sn1...L
0...cn1...User 01
0...uid1...test.matt.01@example.net
0...userPassword1...password
0...givenName1...test.matt01@example.net
02..postalAddress1!..555 FOO LN,.MACON,.GA
0...postalCode1...16666
0...parentlogin1...boofoomoo

As you can see, ldapmodify puts all of the objectclass's into one
line, whereas the slamd client is putting them on multiple lines.  Why
does openldap treat this as an error?  I can't find any docs that say
objectclass's should be folded into one line.  (and I'm still not sure
exactly how to do an ldapmodify with a single-line, multi-value object
class.)

Any help is appreciated,
_Matt





--
 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/