Hi,
I was just reading the draft: Password Policy for LDAP Directories [1]. It
defines an auxiliary object class to define a set of password policy rules
in an entry.
What I was interested in is the administration of this policy object. A bulb
appeared above my head telling me that this is a nice fit for the
Administrative Model and I saw that the RFC also suggests the same thing.
However, that is the weakest part of the RFC. Let me quote it:
10. Administration of the Password Policy
{TODO: Need to define an administrativeRole (need OID). Need to
describe whether pwdPolicy admin areas can overlap}
A password policy is defined for a particular subtree of the DIT by
adding to an LDAP subentry whose immediate superior is the root of
the subtree, the pwdPolicy auxiliary object class. The scope of the
password policy is defined by the SubtreeSpecification attribute of
the LDAP subentry as specified in [RFC3672
<http://tools.ietf.org/html/rfc3672>].
It is possible to define password policies for different password
attributes within the same pwdPolicy entry, by specifying multiple
values of the pwdAttribute. But password policies could also be in
separate sub entries as long as they are contained under the same
LDAP subentry.
Modifying the password policy MUST NOT result in any change in users'
entries to which the policy applies.
It SHOULD be possible to overwrite the password policy for one user
by defining a new policy in a subentry of the user entry.
Each object that is controlled by password policy advertises the
subentry that is being used to control its policy in its
pwdPolicySubentry attribute. Clients wishing to examine or manage
password policy for an object may interrogate the pwdPolicySubentry
for that object in order to arrive at the proper pwdPolicy subentry.
The first thing I did not understand is the following sentence:
But password policies could also be in
separate sub entries as long as they are contained under the same
LDAP subentry.
What is a "sub entry" and what does it mean being "under the same LDAP
subentry. Subentries cannot have any subordinates according to X.500. RFC
3672 does not say anything about this but having subentry subordinates may
break the model. So do we need to allow something like this?
Another point that is interesting is the following sentence:
It SHOULD be possible to overwrite the password policy for one user
by defining a new policy in a subentry of the user entry.
Does that mean making each user entry an Administrative Point? This may make
sense in certain situations: If your password policy object cannot be
defined as a single attribute as the entryACI, then you need to store that
information with separate attributes distributed in an entry. This is OK for
subentries, but when you want to apply this policy to a single (user) entry,
you will cause a clutter in the that entry. So if you define a user entry as
a Password Policy Administrative Point and if you put a
passwordPolicySubentry (with policy attributes) subordinate to it with
subtreeSpecification:
{ maximum 1 }, then you will achieve the
effective-on-one-entry-and-still-multi-attribute scheme. Does this make
sense for you?
BTW, the sentence tells about "overwriting". For overwriting there is need
for a precedence facility. Otherwise both the global pwdPolicy and the
user-local pwdPolicy will apply to the entry. This is one of the problems I
see about the specification.
WDYT?
[1] http://tools.ietf.org/html/draft-behera-ldap-password-policy
--
Ersin Er
