perl-ldap-dev

Re: start_tls

[Chris R. <chr...@me...>]

Graham Barr <gb...@po...> wrote:
> On Fri, Jul 06, 2001 at 01:35:47PM +0100, Chris Ridd wrote:
>> Graham Barr <gb...@po...> wrote:
>> > On Fri, Jul 06, 2001 at 01:03:16PM +0100, Chris Ridd wrote:
>> >> The setting of capth/cafile to '' instead of undef is required by
>> >> 0.78. Hm, we could make our code check the IO::Socket::SSL version
>> >> and set the defaults appropriately...
>> > 
>> > Hm, I have o.78 here and it works fine with undef or ''
>> > 
>> > Graham.
>> 
>> You have to actually try verifying a server's cert using capath to see
>> this problem.
> 
> Ah, that would explain it.
> 
> Graham.

Would this patch be appropriate?

Cheers,

Chris

Re: start_tls

[Graham B. <gb...@po...>]

On Fri, Jul 06, 2001 at 01:35:47PM +0100, Chris Ridd wrote:
> Graham Barr <gb...@po...> wrote:
> > On Fri, Jul 06, 2001 at 01:03:16PM +0100, Chris Ridd wrote:
> >> The setting of capth/cafile to '' instead of undef is required by 0.78.
> >> Hm, we could make our code check the IO::Socket::SSL version and set the
> >> defaults appropriately...
> > 
> > Hm, I have o.78 here and it works fine with undef or ''
> > 
> > Graham.
> 
> You have to actually try verifying a server's cert using capath to see this
> problem.

Ah, that would explain it.

Graham.

Re: start_tls

[Chris R. <chr...@me...>]

Graham Barr <gb...@po...> wrote:
> On Fri, Jul 06, 2001 at 01:03:16PM +0100, Chris Ridd wrote:
>> The setting of capth/cafile to '' instead of undef is required by 0.78.
>> Hm, we could make our code check the IO::Socket::SSL version and set the
>> defaults appropriately...
> 
> Hm, I have o.78 here and it works fine with undef or ''
> 
> Graham.

You have to actually try verifying a server's cert using capath to see this
problem.

With verify => require, capath => "/tmp/certs" and cafile defaulting to
undef the socket creation fails silently (new returns undef and there's
nothing in $@), and strace reveals something attempting to open
"certs/my-ca.pem", which is one of IO::Socket::SSL.pm's defaults.

With cafile defaulting to '' and everything else the same, the socket gets
created OK. (I had my CA cert in /tmp/certs of course.)

So I'm fairly sure that undef does not work in 0.78.

Cheers,

Chris

Re: preparing for release

[Clif H. <cl...@di...>]

> 
> On Fri, Jul 06, 2001 at 01:15:16PM +0100, Chris Ridd wrote:
> > Graham Barr <gb...@po...> wrote:
> > > Does anyone know of any outstanding problems with 0.23 that have
> > > not been fixed in CVS ?
> > 
> > Minor addition to LDAP.pod attached.
> 
> Thanks
> 
> Graham.
> 
> 


Everything I have been working on has been checked in.

Regards,

Clif 

Re: preparing for release

[Graham B. <gb...@po...>]

On Fri, Jul 06, 2001 at 01:15:16PM +0100, Chris Ridd wrote:
> Graham Barr <gb...@po...> wrote:
> > Does anyone know of any outstanding problems with 0.23 that have
> > not been fixed in CVS ?
> 
> Minor addition to LDAP.pod attached.

Thanks

Graham.

Re: preparing for release

[Chris R. <chr...@me...>]

Graham Barr <gb...@po...> wrote:
> Does anyone know of any outstanding problems with 0.23 that have
> not been fixed in CVS ?

Minor addition to LDAP.pod attached.

Cheers,

Chris

Re: start_tls

[Graham B. <gb...@po...>]

On Fri, Jul 06, 2001 at 01:03:16PM +0100, Chris Ridd wrote:
> The setting of capth/cafile to '' instead of undef is required by 0.78. Hm,
> we could make our code check the IO::Socket::SSL version and set the
> defaults appropriately...

Hm, I have o.78 here and it works fine with undef or ''

Graham.

Re: start_tls

[Chris R. <chr...@me...>]

Graham Barr <gb...@po...> wrote:
> On Fri, Jul 06, 2001 at 12:12:13PM +0100, Chris Ridd wrote:
>> Graham Barr <gb...@po...> wrote:
>> > On Fri, Jul 06, 2001 at 10:23:44AM +0100, Chris Ridd wrote:
>> >> I've committed additional changes to LDAPS.pm, LDAP.pm and LDAP.pod. I
>> >> just copied the documentation across because I thought it was still
>> >> useful to see directly on the LDAPS page.
>> > 
>> > I see you have overridded start_tls in LDAPS with a croak.
>> > 
>> > I want to avoid croaks if we can. We could just return a sucess
>> > as afterall we are already using SSL.
>> > 
>> > This check really needs to go into Net::LDAP, as what should happen
>> > if start_tls is called twice ?
>> > 
>> > I suggest we add a check in start_tls for $sock->isa('IO::Socket::SSL')
>> > 
>> > Graham.
>> > 
>> 
>> That makes more sense. Does the attached patch look any better?
> 
> Actually I have made it return an error. I checked what openldap did if
> you called start_tls twice, it returned an error (which was expected)
> 
> Note start_tls returns a message object, from the extension call.
> 
>> It also changes the default values for cafile and capath to '', which is
>> required for versions of IO::Socket::SSL since 0.78. I've tested using
>> both cafile and capath options, and without this change using capath
>> fails.
> 
> OK, I will change those.
> 
>> (We should incidentally require at least this version of IO::Socket::SSL
>> in Makefile.PL.)
> 
> We should check, but I am not sure about require.

> Graham.
> 

The setting of capth/cafile to '' instead of undef is required by 0.78. Hm,
we could make our code check the IO::Socket::SSL version and set the
defaults appropriately...

Cheers,

Chris

Re: start_tls

[Graham B. <gb...@po...>]

On Fri, Jul 06, 2001 at 12:12:13PM +0100, Chris Ridd wrote:
> Graham Barr <gb...@po...> wrote:
> > On Fri, Jul 06, 2001 at 10:23:44AM +0100, Chris Ridd wrote:
> >> I've committed additional changes to LDAPS.pm, LDAP.pm and LDAP.pod. I
> >> just copied the documentation across because I thought it was still
> >> useful to see directly on the LDAPS page.
> > 
> > I see you have overridded start_tls in LDAPS with a croak.
> > 
> > I want to avoid croaks if we can. We could just return a sucess
> > as afterall we are already using SSL.
> > 
> > This check really needs to go into Net::LDAP, as what should happen
> > if start_tls is called twice ?
> > 
> > I suggest we add a check in start_tls for $sock->isa('IO::Socket::SSL')
> > 
> > Graham.
> > 
> 
> That makes more sense. Does the attached patch look any better?

Actually I have made it return an error. I checked what openldap did if
you called start_tls twice, it returned an error (which was expected)

Note start_tls returns a message object, from the extension call.

> It also changes the default values for cafile and capath to '', which is
> required for versions of IO::Socket::SSL since 0.78. I've tested using both
> cafile and capath options, and without this change using capath fails.

OK, I will change those.

> (We should incidentally require at least this version of IO::Socket::SSL in
> Makefile.PL.)

We should check, but I am not sure about require.

Graham.

preparing for release

[Graham B. <gb...@po...>]

Does anyone know of any outstanding problems with 0.23 that have
not been fixed in CVS ?

The RELEASE_NOTES so far for 0.24 are


perl-ldap 0.24
============================

* Added support for startTLS
* Better error checking in Net::LDAP methods
* VLV control now works
* Can now use oid or name for the matchingRule in filter extensible matches
* Major overhaul of LDIF.pm
* $schema->name2oid is now context sensetive
* test suite now works with openldap2

Re: start_tls

[Chris R. <chr...@me...>]

Graham Barr <gb...@po...> wrote:
> On Fri, Jul 06, 2001 at 10:23:44AM +0100, Chris Ridd wrote:
>> I've committed additional changes to LDAPS.pm, LDAP.pm and LDAP.pod. I
>> just copied the documentation across because I thought it was still
>> useful to see directly on the LDAPS page.
> 
> I see you have overridded start_tls in LDAPS with a croak.
> 
> I want to avoid croaks if we can. We could just return a sucess
> as afterall we are already using SSL.
> 
> This check really needs to go into Net::LDAP, as what should happen
> if start_tls is called twice ?
> 
> I suggest we add a check in start_tls for $sock->isa('IO::Socket::SSL')
> 
> Graham.
> 

That makes more sense. Does the attached patch look any better?

It also changes the default values for cafile and capath to '', which is
required for versions of IO::Socket::SSL since 0.78. I've tested using both
cafile and capath options, and without this change using capath fails.

(We should incidentally require at least this version of IO::Socket::SSL in
Makefile.PL.)

Cheers,

Chris

Re: start_tls

[Graham B. <gb...@po...>]

On Fri, Jul 06, 2001 at 10:30:23AM +0100, Chris Ridd wrote:
> Graham Barr <gb...@po...> wrote:
> > I would rather stick to the same name convention as the rest of the module
> > and have start_tls
> 
> I don't really have strong views here, but since TLS is the name of a
> protocol, it should be IMHO capitalized in the method name.

TLS is normally capitalized because it is an acronym, so if we renamed it
startTLS we should also rename root_dse to be rootDSE. But I would rather
keep consistency across method names.

> 
> Or should we rename Net::LDAP to Net::ldap ? ;-)

Package names have different rules to method names.

Graham.

Re: start_tls

[Graham B. <gb...@po...>]

On Fri, Jul 06, 2001 at 10:23:44AM +0100, Chris Ridd wrote:
> I've committed additional changes to LDAPS.pm, LDAP.pm and LDAP.pod. I just
> copied the documentation across because I thought it was still useful to
> see directly on the LDAPS page.

I see you have overridded start_tls in LDAPS with a croak.

I want to avoid croaks if we can. We could just return a sucess
as afterall we are already using SSL.

This check really needs to go into Net::LDAP, as what should happen
if start_tls is called twice ?

I suggest we add a check in start_tls for $sock->isa('IO::Socket::SSL')

Graham.

Re: start_tls

[Graham B. <gb...@po...>]

On Fri, Jul 06, 2001 at 10:23:44AM +0100, Chris Ridd wrote:
> Graham Barr <gb...@po...> wrote:
> > On Thu, Jul 05, 2001 at 12:12:04PM +0100, Graham Barr wrote:
> >> > *However* that returns an I/O error when you next try to call
> >> > _sendmesg on the socket, even though the socket looks OK:
> >> > 
> >> >   DB<1> x $ldap->socket
> >> > 0  IO::Socket::SSL=GLOB(0x866b998)
> >> >    -> *Symbol::GEN0
> >> >          FileHandle({*Symbol::GEN0}) => fileno(3)
> >> > 
> >> > ... same fd as before the socketToSSL, which is good.
> > 
> > I have solve it. socketToSSL does not tie the socket to the
> > IO::Socket::SSL package. Adding that then it works.
> 
> Confirmed here. Hurray! Are you going to send that bug fix back to Marko?

Yes.

> > I will commit what I have to CVS
> > 
> > Graham.
> 
> I've committed additional changes to LDAPS.pm, LDAP.pm and LDAP.pod. I just
> copied the documentation across because I thought it was still useful to
> see directly on the LDAPS page.

OK, great.

Graham.

Re: start_tls

[Chris R. <chr...@me...>]

Graham Barr <gb...@po...> wrote:
> I would rather stick to the same name convention as the rest of the module
> and have start_tls

I don't really have strong views here, but since TLS is the name of a
protocol, it should be IMHO capitalized in the method name.

Or should we rename Net::LDAP to Net::ldap ? ;-)

Cheers,

Chris

Re: start_tls

[Chris R. <chr...@me...>]

Graham Barr <gb...@po...> wrote:
> On Thu, Jul 05, 2001 at 12:12:04PM +0100, Graham Barr wrote:
>> > *However* that returns an I/O error when you next try to call
>> > _sendmesg on the socket, even though the socket looks OK:
>> > 
>> >   DB<1> x $ldap->socket
>> > 0  IO::Socket::SSL=GLOB(0x866b998)
>> >    -> *Symbol::GEN0
>> >          FileHandle({*Symbol::GEN0}) => fileno(3)
>> > 
>> > ... same fd as before the socketToSSL, which is good.
> 
> I have solve it. socketToSSL does not tie the socket to the
> IO::Socket::SSL package. Adding that then it works.

Confirmed here. Hurray! Are you going to send that bug fix back to Marko?

> I will commit what I have to CVS
> 
> Graham.

I've committed additional changes to LDAPS.pm, LDAP.pm and LDAP.pod. I just
copied the documentation across because I thought it was still useful to
see directly on the LDAPS page.

Cheers,

Chris

New additions to the perl-ldap web page.

[Clif H. <ch...@po...>]

All,

I have updated the FAQ, minor spelling corrections.  Putting
the updated FAQ online corrected the pod2html mess up on
on the jpeg and referral sections.

Now for the big news, Graham and I have had discussions about
putting a Faq-o-matic system online for perl-ldap.  

For the last few weeks I have been working on this project and 
as of tonight it is online and ready for your review and 
suggestions.  

There is a new link just below the FAQ section that will take 
you to the perl-ldap Faq-o-matic.  Currently the faq-o-matic 
is not much more than an extension of the online FAQ.

This faq-o-matic is hosted off of sourceforge, sometimes there
are lags in response.  This I believe this is due to loading
on the sourceforge systems and their networks.
 
Regards,

Clif Harden          ch...@po...

Connecting to a secondary ldap server (slave) if the primary (master) is down

[Eric P. <li...@gl...>]

Hello,

    I'd like to know if it's possible to use more than one LDAP
server, in other words, to connect to the slave ldap server if the
master is down.

And if so, how would I implement such a thing?  Just test the
connection to the first (maybe set a timeout value that's not too
high), and if it fails to connect, try the 2nd?
Or is there an easier way to do it?  All the other methods I've used
of connecting to an LDAP server allowed me to just specify multiple
ldap servers, seperated by a space...

Thanks in advance,

Eric Parusel
Systems Administrator
Global Relay Communications

Re: [Fwd] Perl-LDAP compare

[Viktor L. <le...@lu...>]

Well, what it does is set the result code of the operation, you should compare them with the 
constants LDAP_COMPARE_TRUE and LDAP_COMPARE_FALSE, something like this works for me:
if ( $result->code == LDAP_COMPARE_TRUE ) {
  print "'$value' matched\n";
} else {
  print "'$value' did not match, or something went wrong.\";
}

> ----- Forwarded message from mic...@ko... -----
> 
> Date: Thu, 5 Jul 2001 17:23:43 -0400
> To: gb...@po...
> From: mic...@ko...
> Subject: Perl-LDAP compare
> 
> 
> 
> From: Mike J Kozakiewicz
> 
> Graham, I am trying to determine if I can use "compare" to do a simple
> authentication against a password field in my LDAP compliant directory.  I
> cannot figure out what "compare" returns.  My search of the documentation did
> not help.  Can you suggest where I can find this information?
> 
> 
> 
> ----- End forwarded message -----
> 
> 
> 


-- 
Viktor Leijon (le...@lu...) 

[Fwd] Perl-LDAP compare

[Graham B. <gb...@po...>]

----- Forwarded message from mic...@ko... -----

Date: Thu, 5 Jul 2001 17:23:43 -0400
To: gb...@po...
From: mic...@ko...
Subject: Perl-LDAP compare



From: Mike J Kozakiewicz

Graham, I am trying to determine if I can use "compare" to do a simple
authentication against a password field in my LDAP compliant directory.  I
cannot figure out what "compare" returns.  My search of the documentation did
not help.  Can you suggest where I can find this information?



----- End forwarded message -----

Re: start_tls

[Graham B. <gb...@po...>]

On Thu, Jul 05, 2001 at 12:12:04PM +0100, Graham Barr wrote:
> > *However* that returns an I/O error when you next try to call _sendmesg on
> > the socket, even though the socket looks OK:
> > 
> >   DB<1> x $ldap->socket
> > 0  IO::Socket::SSL=GLOB(0x866b998)
> >    -> *Symbol::GEN0
> >          FileHandle({*Symbol::GEN0}) => fileno(3)
> > 
> > ... same fd as before the socketToSSL, which is good.

I have solve it. socketToSSL does not tie the socket to the IO::Socket::SSL package.
Adding that then it works.

I will commit what I have to CVS

Graham.

Re: userpassword

[Chris R. <chr...@me...>]

Graham Barr <gb...@po...> wrote:
> On Wed, Jul 04, 2001 at 10:35:11AM +0100, Graham Barr wrote:
>> On Wed, Jul 04, 2001 at 10:26:50AM +0100, Chris Ridd wrote:
>> > Graham Barr <gb...@po...> wrote:
>> > > On Wed, Jul 04, 2001 at 09:58:37AM +0100, Chris Ridd wrote:
>> > >> Graham Barr <gb...@po...> wrote:
>> > >> > On Wed, Jul 04, 2001 at 09:12:01AM +0100, Chris Ridd wrote:
>> > >> IIRC, IO::Socket::SSL needs to support send() and recv(), which I
>> > >> imagined would mean it (and by extension Net::SSLeay) needed
>> > >> rewriting to use openssl's non-blocking I/O.
>> > > 
>> > > Is this because Net::LDAP currently uses send() and recv() ?
>> > 
>> > Yes. I thought it was doing that in case we wanted to support CLDAP (a
>> > version of LDAP over UDP) at some point.
>> 
>> There are always other ways to solve that. And right now I would
>> rather support LDAPS than CLDAP
>> 
>> > > Is the Net::LDAPS in CVS upto date ?
>> > 
>> > Yes.
>> 
>> OK, I will make the changes.
> 
> OK, I have commited the changes to CVS, please check that I have not
> broken Net::LDAPS

Minor damage: you need to create an IO::Socket::SSL instead of an
IO::Socket::INET in the new _connect method in LDAPS.pm :-)

> It seems to ne we can add this to Net::LDAP
> 
> sub start_tls {
>   my $ldap = shift;
> 
>   require IO::Socket::SSL;
>   IO::Socket::SSL::startTLS($ldap->socket);
> }
> 
> yes ?
> 
> 
> Graham.

Not quite. You need to issue an extended LDAP operation to indicate you're
going to start the TLS handshake, so it needs to be something like this:

sub startTLS {
    my $ldap = shift;
    my $args = &_options;
    if ($ldap->version < 3) {
	require Carp;
	Carp::croak("StartTLS not supported before LDAPv3");
    }
    require Net::LDAP::Extension;
    my $mesg = Net::LDAP::Extension->new($ldap);
    $mesg->encode(
                  extendedReq => {
                      requestName => "1.3.6.1.4.1.1466.20037",
                  }
                 );
    $ldap->_sendmesg($mesg);
    $mesg->sync();
    if ($mesg->code) {
	require Carp;
	Carp::croak("LDAP_OPERATIONS_ERROR $@");
    }
    require IO::Socket::SSL;
    IO::Socket::SSL::context_init($args);
    IO::Socket::SSL::socketToSSL($ldap->socket);
}

*However* that returns an I/O error when you next try to call _sendmesg on
the socket, even though the socket looks OK:

  DB<1> x $ldap->socket
0  IO::Socket::SSL=GLOB(0x866b998)
   -> *Symbol::GEN0
         FileHandle({*Symbol::GEN0}) => fileno(3)

... same fd as before the socketToSSL, which is good.

The mechanism to select the ciphers and verify mode etc need some
improvement too - perhaps the logic in Net::LDAPS to set this stuff should
go into LDAP.pm

I'm not sure calling context_init() is the right thing to do here either;
it looks awfully 'global' in scope.

We should also override startTLS in LDAPS to prevent someone from calling
it on an LDAPS socket :-)

Cheers,

Chris

start_tls

[Graham B. <gb...@po...>]

On Thu, Jul 05, 2001 at 12:00:12PM +0100, Chris Ridd wrote:
> > OK, I have commited the changes to CVS, please check that I have not
> > broken Net::LDAPS
> 
> Minor damage: you need to create an IO::Socket::SSL instead of an
> IO::Socket::INET in the new _connect method in LDAPS.pm :-)

Whoops :)

> Not quite. You need to issue an extended LDAP operation to indicate you're
> going to start the TLS handshake, so it needs to be something like this:
> 
> sub startTLS {

I would rather stick to the same name convention as the rest of the module
and have start_tls

>     my $ldap = shift;
>     my $args = &_options;
>     if ($ldap->version < 3) {
> 	require Carp;
> 	Carp::croak("StartTLS not supported before LDAPv3");
>     }
>     require Net::LDAP::Extension;
>     my $mesg = Net::LDAP::Extension->new($ldap);
>     $mesg->encode(
>                   extendedReq => {
>                       requestName => "1.3.6.1.4.1.1466.20037",
>                   }
>                  );
>     $ldap->_sendmesg($mesg);
>     $mesg->sync();
>     if ($mesg->code) {
> 	require Carp;
> 	Carp::croak("LDAP_OPERATIONS_ERROR $@");
>     }
>     require IO::Socket::SSL;
>     IO::Socket::SSL::context_init($args);
>     IO::Socket::SSL::socketToSSL($ldap->socket);
> }
> 
> *However* that returns an I/O error when you next try to call _sendmesg on
> the socket, even though the socket looks OK:
> 
>   DB<1> x $ldap->socket
> 0  IO::Socket::SSL=GLOB(0x866b998)
>    -> *Symbol::GEN0
>          FileHandle({*Symbol::GEN0}) => fileno(3)
> 
> ... same fd as before the socketToSSL, which is good.

Yes, looking at the code they just re-bless the given socket.

> The mechanism to select the ciphers and verify mode etc need some
> improvement too - perhaps the logic in Net::LDAPS to set this stuff should
> go into LDAP.pm
> 
> I'm not sure calling context_init() is the right thing to do here either;
> it looks awfully 'global' in scope.
> 
> We should also override startTLS in LDAPS to prevent someone from calling
> it on an LDAPS socket :-)

Right.

Graham.

Re: userpassword

[Chris R. <chr...@me...>]

"Kurt D. Zeilenga" <Ku...@Op...> wrote:
> At 01:12 AM 7/4/2001, Chris Ridd wrote:
>> David Bussenschutt <d.b...@ma...> wrote:
>>> Of course, the easiest way to do a password compare without having to 
>>> worry about the encoding, or UTF, or any other directory specific stuff
>>> is  to try doing a bind as that user.
>>> If you can bind, then the password was OK. 
>>> Isn't that easier than the other options given?
>> 
>> Yes and no. When you send a bind to the server, internally it issues a
>> compare operation against the userPassword attribute etc,  so bind and
>> compare should basically both work and fail identically when given the
>> same input.
> 
> Bind need not use userPassword.  It can use authPassword (RFC 3112)
> or other attributes or information stored outside the directory.
> Bind can use access control and policy information. 

Good point.

>> Also of course, it might be possible to bind as the manager of the server
>> and then bind as user 'A', but not bind as user 'A' and then bind as user
>> 'B' due to access controls.
> 
> I would call that server broken.  A server should drop the

No, just configured with an unhelpful combination of access controls :-(

Cheers,

Chris

Re: userpassword

[Kurt D. Z. <Ku...@Op...>]

At 01:12 AM 7/4/2001, Chris Ridd wrote:
>David Bussenschutt <d.b...@ma...> wrote:
>> Of course, the easiest way to do a password compare without having to 
>> worry about the encoding, or UTF, or any other directory specific stuff
>> is  to try doing a bind as that user.
>> If you can bind, then the password was OK. 
>> Isn't that easier than the other options given?
>
>Yes and no. When you send a bind to the server, internally it issues a
>compare operation against the userPassword attribute etc,  so bind and
>compare should basically both work and fail identically when given the same
>input.

Bind need not use userPassword.  It can use authPassword (RFC 3112)
or other attributes or information stored outside the directory.
Bind can use access control and policy information. 

Compare is used to assert that a particular value is held by
as a value of a attribute in a particular entry.  This success of
this operation may or may not have any relationship to the
success of a bind operation.

>The reason you might want to use compare instead of bind is because some
>servers will close the TCP connection when you unbind,

Don't unbind if you intend to issue additional operations.
The purpose of unbind is to inform the server that the
session should now be disassociated.

I note that the purpose of bind (in LDAP) is not to bind the
protocol association, it's to authenticate.  (Yes, the 
historical names of the operations is confusing.)

>which is a pain if
>you're trying to have your authentication code embedded in a long lived
>process, eg mod_perl.
>
>Also of course, it might be possible to bind as the manager of the server
>and then bind as user 'A', but not bind as user 'A' and then bind as user
>'B' due to access controls.

I would call that server broken.  A server should drop the
authentication (not the protocol) association upon receipt
of the bind request such that all bind requests are processed
anonymously (and any failed bind leaves the session in an
anonymous state).

>For a short-lived CGI script you can get away with creating a connection
>and doing a bind over it, but for a long-lived embedded script you want to
>keep the connection open as long as possible and therefore should bind once
>as the manager (or something equivalent) and then issue compare operations
>on demand.

Again, the only way to authenticate to the directory is to use
the bind operation.  While you may use compare to verify a
password is known, knowing the password is only one part of an
authentication process.

Kurt