Re: Client passing "NTLM" as DN

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

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