Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Date: Wed, 14 Nov 2007 11:46:18 -0500
From: "Mark H. Wood" <mwood@IUPUI.Edu>
To: users@httpd.apache.org
Message-ID: <20071114164618.GD30722@IUPUI.Edu>
References: <20071112212305.GA26771@IUPUI.Edu>
 <1404e5910711121526hf9acb1fqea0f1ec5fd114d8a@mail.gmail.com>
 <20071113142431.GA22037@IUPUI.Edu>
 <1404e5910711130638j7bc4465cm27cecda0ba792402@mail.gmail.com>
 <20071113151002.GB22037@IUPUI.Edu>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="XvKFcGCOAo53UbWW"
Content-Disposition: inline
In-Reply-To: <20071113151002.GB22037@IUPUI.Edu>
User-Agent: Mutt/1.5.16 (2007-06-09)
Sender: "Mark H. Wood,UL 0115A,+1 317 274 0749," <mwood@mhw.ulib.iupui.edu>
Subject: Re: [users@httpd] 2.2.6 mod_authnz_ldap connect/disconnect
	repeatedly without doing LDAP

--XvKFcGCOAo53UbWW
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Another observation:  I changed the AuthLDAPURL to '"ldap:..." STARTTLS',
gathering from the wording in the manual that mod_authnz_ldap might
only do LDAPS through the Netscape SDK while I'm using OpenLDAP:

     Support for LDAP over SSL (requires the Netscape SDK) or TLS
     (requires the OpenLDAP 2.x SDK or Novell LDAP SDK).

Now the LDAP layer actually speaks.  httpd sends a START_TLS extended
request, and ADS responds positively.  Then, without any attempt to
bind, let alone query, httpd sends an LDAP unbind and begins tearing
down the TCP connection.

No.     Time        Source                Destination           Protocol In=
fo
      1 0.000000    134.68.190.58         134.68.220.153        TCP      45=
637 > ldap [SYN] Seq=3D0 Len=3D0 MSS=3D1460 TSV=3D96846395 TSER=3D0 WS=3D7
      2 0.000268    134.68.220.153        134.68.190.58         TCP      ld=
ap > 45637 [SYN, ACK] Seq=3D0 Ack=3D1 Win=3D16384 Len=3D0 MSS=3D1460 WS=3D0=
 TSV=3D0 TSER=3D0
      3 0.000331    134.68.190.58         134.68.220.153        TCP      45=
637 > ldap [ACK] Seq=3D1 Ack=3D1 Win=3D5888 Len=3D0 TSV=3D96846395 TSER=3D0
      4 0.001346    134.68.190.58         134.68.220.153        LDAP    =20
      5 0.001961    134.68.220.153        134.68.190.58         LDAP     ex=
tendedResp(1)=20
      6 0.002016    134.68.190.58         134.68.220.153        TCP      45=
637 > ldap [ACK] Seq=3D32 Ack=3D47 Win=3D5888 Len=3D0 TSV=3D96846395 TSER=
=3D484044
      7 0.003463    134.68.190.58         134.68.220.153        LDAP     un=
bindRequest(2)=20
      8 0.003552    134.68.190.58         134.68.220.153        TCP      45=
637 > ldap [FIN, ACK] Seq=3D39 Ack=3D47 Win=3D5888 Len=3D0 TSV=3D96846396 T=
SER=3D484044
      9 0.003784    134.68.220.153        134.68.190.58         TCP      ld=
ap > 45637 [ACK] Seq=3D47 Ack=3D40 Win=3D65497 Len=3D0 TSV=3D484044 TSER=3D=
96846396
     10 0.003962    134.68.220.153        134.68.190.58         TCP      ld=
ap > 45637 [FIN, ACK] Seq=3D47 Ack=3D40 Win=3D65497 Len=3D0 TSV=3D484044 TS=
ER=3D96846396
     11 0.004009    134.68.190.58         134.68.220.153        TCP      45=
637 > ldap [ACK] Seq=3D40 Ack=3D48 Win=3D5888 Len=3D0 TSV=3D96846396 TSER=
=3D484044

It's as though the LDAP auth code gets all set to bind, then discovers
some error which goes totally unreported, and drops the connection as faile=
d.

--=20
Mark H. Wood, Lead System Programmer   mwood@IUPUI.Edu
Typically when a software vendor says that a product is "intuitive" he
means the exact opposite.


--XvKFcGCOAo53UbWW
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHOyZas/NR4JuTKG8RAt/yAJ9SOvRwT5hsfy1sva2x/eYutKft7wCgolAx
NV0/a6aMSIdajsLAMJ+JkAI=
=QO/0
-----END PGP SIGNATURE-----

--XvKFcGCOAo53UbWW--