[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