At 01:37 PM 11/23/2006, AW W wrote:
ldap_read: want=75, got=75 0000: 3a 60 84 00 00 00 44 02 01 03 04 04 4e 54 4c 4d :`....D.....NTLM 0010: 8a 39 4e 54 4c 4d 53 53 50 00 01 00 00 00 07 b2 .9NTLMSSP....... 0020: 08 a2 09 00 09 00 30 00 00 00 08 00 08 00 28 00 ......0.......(. 0030: 00 00 05 02 ce 0e 00 00 00 0f 5a 54 43 46 56 30 ..........ZTCFV0 0040: 4e 32 41 4d 45 52 49 43 41 53 45 N2AMERICASE
dnPrettyNormal: <NTLM>
=> ldap_bv2dn(NTLM,0) ldap_err2string <= ldap_bv2dn(NTLM)=-4 Decoding error bind: invalid dn (NTLM)
Is slapd(8) responding properly to this ldap client request
IMO, yes. The "NTLM" doesn't conform to the LDAP DN string syntax.
(Note: RFC 4513 says the server is to ignore the bind name sent as part of a SASL bind. This requirement was only intended to preclude a server from making use of the bind name (in performing the authentication), it was not intended to preclude the server from parsing the PDU to determine what (abstract) value is.)
and is it possible to influence this behavior somehow?
Someone could, of course, hack the server to ignore invalid bind DN strings when using the SASL method... but, regardless, the client really should not be sending any bind name string, and certainly shouldn't be sending an invalid bind name string.
Can somewhat speculate as to what is going on here?
The client is broken. The bind DN may only be the tip of this iceberg. Even ignoring the bind DN field, the PDU appears to be malformed.
- Kurt