Andrew,
Here's the situation that was described to me:
A web application is configured to authenticate to LDAP. Somewhere under
the covers this translates into a bind request to the LDAP server. I
believe it is quite common for many "accounts" on LDAP servers to be used
in binds for only this purpose.
The administrator has enabled password policy on the LDAP server with the
"password must be changed after [re]set" feature and creates a new account
-- or resets the password of an existing account. At this point the
account is now in a state where the user must change the password.
The web application, not knowing about password policy, issues a bind
request and gets a "success" result. If this is the only way that a bind
is done to this account, the user can authenticate to the web application
over and over without changing their password. This seems to violate the
intent of the "password must be changed after reset" setting. If the
connection were used for some other operation other than bind - or changing
the client's password - the client would get failures.
Thus my suggestion that the bind request ought to fail. I don't believe
that authentication using a password that must be reset should succeed from
the perspective of the web application. If the web application was
password policy aware, I'd expect it to tell the user that his password
must be changed, provide an interface to change the password, and not allow
any other actions.
In an environment where password policy has been set up in this way some
set of tools would be provided to enable the user to change their password,
most likely through an application that does know about password policy
controls. Alternately, I suppose the server could send a failure response
to the client, but leave the connection in an authenticated state
sufficient to perform the change password request. That would require the
client to recognize the failure and allow password changes -- still a
change, but possibly one that is easier to handle than installing a new
client. And there's probably nothing inherently wrong with an anonymously
bound password change request, as long as it contains the old password and
is treated by server similar to a bind request and modify request (i.e.
audit attempts to change the password with wrong old password). These seem
like policy decisions that can be left to the implementation.
Certainly, if the applications used to change passwords cannot be changed
to deal with these accounts, you're in trouble. But you shouldn't be using
this password policy then.
John McMeeking