|
G'Day,
Take a look at the scenario of a bound entity
changing their own userPassword and including a passwordPolicyRequest control in
the LDAPMessage. (Where a passwordPolicy is in place for the userPassword
attribute).
By following the steps described in 6.2, if
the operation succeeds, the user will simply get an LDAPMessage back with a
LDAPResult of `success' and no passwordPolicyResponse control.
At this point in time the entity would have
no idea as to whether a password policy is being applied to their
userPassword.
Receiving
the successful response without a passwordPolicyResponse control could
mean:
* The DSA knows nothing
about the Password Policy control, and since it was not marked as being
critical, has just ignored it,
* The DSA does support
Password Policy controls, but no password policy was applied to this
`userPassword' attribute,
* The DSA does support the
Password Policy control, and a policy does apply to the userPassword
attribute.
If the
intention of the Password Policy Specification is to
suppress returning controls on successful operations, then I think we need
some way to indicate to the client that a password policy is being applied
to their password.
I think an ideal time to do this is when the
entity is using their password to authenticate themselves in a bind or compare
operation. By returning the password policy control, even on a successful
compare or bind, it makes the entity aware that their password has a policy
applied to it and that subsequent operations performed on this password
attribute will result in the policy being enforced.
Regards,
Andrew Sciberras
|