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

Re: Netscape to slapd with SSL anonymous OK, login fails



Julio, are you of the view that this is more likely to be a Netscape
problem?


----- Original Message -----
From: "Julio Sanchez" <j_sanchez@stl.es>
To: <openldap-software@OpenLDAP.org>
Sent: Sunday, October 15, 2000 7:16 PM
Subject: Re: Netscape to slapd with SSL anonymous OK, login fails


"Jim Hud" <jdhz@btinternet.com> writes:

> ldapsearch -Z appears to work OK in all four modes (Anon/Login SSL/No SSL)
> Netscape 4.75 on NT works as follows
>
> Anonymous    No SSL        OK
> Anonymous    SSL              OK
> Login             No SSL        OK
> Login             SSL               Netscape reports "Failed to search
error
> Referral Hop Limit (0x61)"

This never worked. When I analyzed this I saw that the server allowed
that bind OK, but that the client decided it had rejected it.
Funnily, 0x61 is the tag for Bind Response, so I guessed the data
streams got out of sync somehow so that either slapd is encoding
incorectly the answer or Netscape misparses it.  However, that is only
a guess and has never been proved.

Never knew which.  Would someone who knows the protocol well have a
look at this?  IIRC, it happens when Netscape binds first to do the
search for the mail attribute, not in the later bind (that never
happens):

> ber_scanf fmt ({iat) ber:
> ber_dump: buf=0x00db6b50 ptr=0x00db6b53 end=0x00db6b5c len=9
>   0000:  60 07 02 01 02 04 00 80  00                        `........
> ber_scanf fmt (o}) ber:
> ber_dump: buf=0x00db6b50 ptr=0x00db6b5a end=0x00db6b5c len=2
>   0000:  80 00                                              ..
> do_bind: version=2 dn="" method=128
> bind OK
> do_bind: v2 anonymous bind
> send_ldap_result err:0
> send_ldap_result: conn=0 op=0 p=2
> send_ldap_result: 0::
> send_ldap_response: msgid=1 tag=97 err=0
> ber_flush: 14 bytes to sd 468
>   0000:  30 0c 02 01 01 61 07 0a  01 00 04 00 04 00         0....a........

That is a sequence made of an integer valued 1 (the messageID),
followed by a BindResponse (starting at tag 0x61).  That begins with
an enumerated of value 0 (success), followed by two empty strings
(matchedDN and errorMessage).  That seems alright.

However, after that, the client closes the connection (or some such, I
don't quite understand this part):

> tls_write: want=45, written=45
>   0000:  17 03 00 00 28 92 fc 81  ee 22 dc 1a 88 13 49 9c
....(.ü.."....I.
>   0010:  9a 96 75 73 61 11 63 de  8a dd c1 4e 3e b2 92 16
..usa.c....N>...
>   0020:  5c 48 98 e7 1e 19 07 8b  ce 10 e2 7f dd            \H...........
> sockbuf_write: want=14, written=14
>   0000:  30 0c 02 01 01 61 07 0a  01 00 04 00 04 00         0....a........
> daemon: select: listen=92 active_threads=1 tvp=NULL
> daemon: select: listen=52 active_threads=1 tvp=NULL
> daemon: activity on 1 descriptors
> daemon: select: listen=92 active_threads=1 tvp=NULL
> daemon: select: listen=52 active_threads=1 tvp=NULL
> slap_sig_shutdown: signal 2
> daemon: shutdown requested and initiated.
> daemon: closing 92
> slapd shutdown: waiting for 0 threads to terminate
> slapd shutdown: initiated
> ldbm backend syncing
> ldbm backend done syncing
> ====> cache_release_all
> slapd shutdown: freeing system resources.
> slapd stopped.
> tls_write: want=29, written=29
>   0000:  15 03 00 00 18 ea c9 ee  58 48 a9 d5 4a c4 09 b4
........XH..J...
>   0010:  30 86 0e 7b 17 5e 87 3b  5a 66 14 b0 6f            0..{.^.;Zf..o
> TLS trace: SSL3 alert write:warning:close notify

Regards,

Julio