[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: [ldapext] Returning the Password Policy Control
I've never thought of the password policy control response as being a
mechanism for informing the client that a password policy applied to any
given request. Rather, I view the purpose of the control to be to carry
additional error / warning information so that a password policy aware
client could react to it.
I don't think the typical application is concerned with whether a password
policy is in effect, any more than I would expect logon to a system to tell
me that. I just want to know that I have logged in successfully, or
changed my password successfully, and if there is an error (or my password
is about to expire), then I want to know that it is because passwords
expire every 186 days (for example).
I do think that an administrator or auditor has an interest in knowing that
password policy applies to a given entry and / or password attribute. I
don't think that returning a password policy response control is the best
way to satisfy such a requirement. One way to accomplish this is to define
an operational attribute, say passwordPolicySubentry, that names the
password policy subentry(ies?) that governs the entry. The administrator /
auditor should have authority to read the password policy entry.
If there is a subtreespecification associated with the password policy
[sub]entry, it could be challenging determining whether a given policy
applies to a specific entry. For example, an entry could fall within a
governed subtree, but not match the filter or other component of the
subtree specification. The question of whether a subtree specification
applies to an entry is a general problem. It might be appropriate to have
password policy define the passwordPolicySubentry attribute, and have
something like the subentry draft define an extended operation to determine
if a given subentry applies to a given entry.
John McMeeking
"Andrew
Sciberras" To: "'Jim Sermersheim'" <jimse@novell.com>
<andrews@adacel.c cc: "Ldapext \(E-mail\)" <ldapext@ietf.org>
om.au> Subject: RE: [ldapext] Returning the Password Policy Control
Sent by:
ldapext-admin@iet
f.org
09/03/2003 07:15
PM
Please respond to
andrews
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
-----Original Message-----
From: Jim Sermersheim [mailto:jimse@novell.com]
Sent: Thursday, 4 September 2003 7:52
To: andrews@adacel.com.au; ldapext@ietf.org
Subject: Re: [ldapext] Returning the Password Policy Control
You're right, it needs to be clarified.
The original intent was that the control is only returned when needed (as
specified), and not needed when operations suceed (and no extra information
needs to be returned).
We need to consider your reasons for returning the control for every bind
and compare.
Jim
>>> "Andrew Sciberras" <andrews@adacel.com.au> 9/1/03 6:44:59 PM >>>
Hi,
<snip>
I think that it is important to include the passwordPolicyResponse control
in every bind and compare response (when the request control is supplied)
to
provide a strong indication to the client that the server is enforcing the
password policy.
</snip>
Thanks.
Andrew Sciberras
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www1.ietf.org/mailman/listinfo/ldapext