Re: userpassword

[Kurt D. Z. <Kurt@OpenLDAP.org>]

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