A few weeks ago, I was developing a script to be run on UNIX
that would query a Microsoft Active Directory server via
LDAP.  I authenticated to the Windows 2000 Realm using
Kerberos V (for information on Kerberos interoperability see
http://www.microsoft.com/technet/prodtechnol/windows2000serv/howto/kerbstep.asp). 
I then used the OpenLDAP 2.0.23 ldapsearch tool (compiled
with GSSAPI support to allow Kerberos V authentication) to
return results from the Active Directory.

Everything worked fine for searches with small result sets. 
However, when I searched for large result sets, no results
were returned.  After some investigation, I determined that
I might need to perform a paged search (see
http://msdn.microsoft.com/library/en-us/netdir/ldap/paging_search_results.asp). 
Following the procedure in rfc2696
(http://www.ietf.org/rfc/rfc2696.txt), I added the following
lines of code to the ldapsearch tool (error checking has
been omitted):

---------------------------------------
LDAPControl c;
LDAPControl *ctrls[2];
ctrls[0] = &c;
ctrls[1] = NULL;

c.ldctl_oid = "1.2.840.113556.1.4.319";
c.ldctl_value.bv_val = NULL;
c.ldctl_value.bv_len = 0;
c.ldctl_iscritical = 0;

ldap_set_option(ld,LDAP_OPT_SERVER_CONTROLS,ctrls);
----------------------------------------

Basically, I was trying to create an LDAPv3 server control
to tell the Active Directory server to perform a paged
search.  In this case, I passed it a page length of 0 (I
did this as a test).  Unfortunately, this test caused Active
Directory to hang.

My guess is that Microsoft does not check for a zero value
when setting the page size.  Thus, in calculating the number
of records to return per page, they divide by zero, casing
the process to hang.

Note that if anonymous queries are DISABLED (which they are
on our server), this vulnerability can only be exploited by
an authenticated user.  I did not test this against a
directory with anonymous queries enabled (I didn't have
one), nor did I test it with simple (plain) authentication. 
I was always authenticated using Kerberos V + GSSAPI.  The
problem could very well be in the GSSAPI layer, not Active
Directory itself.

This bug was reported to Microsoft on 5-13-2002; no response
has been received.

Client Summary:
SunBlade 1000 running Solaris 8
MIT Kerberos V 1.2.5
Cyrus SASL 1.5.27
OpenLDAP 2.0.23
-All compiled as 32-bit binaries.  See
http://www.bayour.com/LDAPv3-HOWTO.html for instructions on
compiling OpenLDAP with Kerberos & GSSAPI support.