Description of problem:

When using GSSAPI, I get a "decoding error" trying to add new entries.


Version-Release number of selected component (if applicable):

fedora-ds-1.0.2-1.RHEL4
# cat /etc/redhat-release 
Red Hat Enterprise Linux AS release 4 (Nahant Update 4)
# uname -a
Linux bill.ee.washington.edu 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:27:17 EDT 2006
i686 i686 i386 GNU/Linux
# rpm -q cyrus-sasl-gssapi
cyrus-sasl-gssapi-2.1.19-5.EL4
# rpm -q krb5-libs
krb5-libs-1.3.4-33


How reproducible: Always


Steps to Reproduce:

export KRB5CCNAME=/usr/local/etc/keys/menu.tickets/ldap_$$
/usr/kerberos/bin/kinit -k -t /usr/local/etc/keys/menu.keytab \
  application/hostname.ee.washington.edu
ldapadd -Y GSSAPI <<EOF
dn: uid=trzy2,ou=people,dc=ee,dc=washington,dc=edu
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: sambaSamAccount
cn: Bart C Trzynadlowski
gecos: Bart C Trzynadlowski
givenName: Bart C
sn: Trzynadlowski
uid: trzy2
uidNumber: 26727
gidNumber: 530
homeDirectory: /homes/trzy2
loginShell: /bin/bash
employeeNumber: 0626969
description: student
mail: trzy2@ee.washington.edu
sambaSID: S-1-0-0-44454
sambaAcctFlags: [U          ]
sambaLMPassword: <an lm hash>
sambaNTPassword: <an nt hash>
userPassword: <a password hash>
EOF
  
Actual results:

Output:
SASL/GSSAPI authentication started
SASL SSF: 56
SASL installing layers
modifying entry "uid=trzy2,ou=people,dc=ee,dc=washington,dc=edu"
ldap_modify: Protocol error
        additional info: decoding error

ldif_record() = 2

Access log:

[25/Sep/2006:22:31:15 -0700] conn=44540 fd=2579 slot=2579 connection from
128.95.XX.XX to 128.95.XX.XX
[25/Sep/2006:22:31:15 -0700] conn=44540 op=0 BIND dn="" method=sasl version=3
mech=GSSAPI
[25/Sep/2006:22:31:15 -0700] conn=44540 op=0 RESULT err=14 tag=97 nentries=0
etime=0, SASL bind in progress
[25/Sep/2006:22:31:15 -0700] conn=44540 op=1 BIND dn="" method=sasl version=3
mech=GSSAPI
[25/Sep/2006:22:31:15 -0700] conn=44540 op=1 RESULT err=14 tag=97 nentries=0
etime=0, SASL bind in progress
[25/Sep/2006:22:31:15 -0700] conn=44540 op=2 BIND dn="" method=sasl version=3
mech=GSSAPI
[25/Sep/2006:22:31:15 -0700] conn=44540 op=2 RESULT err=0 tag=97 nentries=0
etime=0 dn="uid=application/hostname.ee.washington.edu,ou=special
users,dc=ee,dc=washington,dc=edu"
[25/Sep/2006:22:31:15 -0700] conn=44540 op=3 MOD
dn="uid=trzy2,ou=people,dc=ee,dc=washington,dc=edu", decoding error
[25/Sep/2006:22:31:15 -0700] conn=44540 op=3 RESULT err=2 tag=103 nentries=0 etime=0
[25/Sep/2006:22:31:15 -0700] conn=44540 op=4 UNBIND
[25/Sep/2006:22:31:15 -0700] conn=44540 op=4 fd=2579 closed - U1



Expected results:

The user should have been added.

Additional info:

If I do a simple bind as the application's DN, rather than using GSSAPI, the
same LDIF will import successfully.  GSSAPI is encrypting the payload, and I
suspect that Fedora Directory / cyrus-sasl / krb5-libs are not decrypting it
correctly on the server end.  I've reproduced the error using two different
client stacks:

# rpm -q openldap-clients cyrus-sasl krb5-libs
openldap-clients-2.0.27-22
cyrus-sasl-2.1.15-10
krb5-libs-1.2.7-52

$ rpm -q openldap-clients cyrus-sasl krb5-libs
openldap-clients-2.3.19-4
cyrus-sasl-2.1.21-10
krb5-libs-1.4.3-5.1

I would also note that if I remove the samba objectclass, and attributes, and
the userPassword attribute, it works using GSSAPI, so the bug may only trigger
on payloads larger than some byte value, which I haven't determined exactly.

If I add the LDIF as described in the preceding paragraph, and then use
ldapmodify (also with GSSAPI) to add the values that I stripped out, that works,
too, which lends credence to the idea that the bug is related to the size of the
payload, and not the values therein.