[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [ldapext] Password Policy OIDs
I viewed my posts as describing possible mechanisms for extending password
policy beyond the "basic" password policy defined in this draft, one using
attributes and auxiliary classes in a schema defined by the extension, this
latter providing a predefined attribute for the purpose. I then drew from
other posts to form examples of how these extension mechanisms might be
used, not intending that those particular policy extensions - included
characters, excluded characters - be incorporated into the password policy
document.
In that context, debate over whether regex's should be used vs lists of
characters and whether a dictionary should be in LDAP is largely academic;
it debate over the design of hypothetical future extensions. If people are
proposing that these be added to the password policy draft, then it is a
very relevant discussion.
As to manageability of features from LDAP... I guess that depends on where
you want to draw the line. I agree that it is nice if you don't have to
use one set of tools to manage part of the policy and another to manage the
rest. On the other hand, other tools/storage mechanism may be much better
suited to managing these than LDAP. I don't think is necessary to store
the dictionary in LDAP to be able to effectively manage a password policy
that uses a dictionary. One may want to share an existing dictionary used
by other applications. Similarly, if one wanted to use scripts, I don't
think the scripts need to be stored in LDAP. A file name is quite
adequate. Alternately, the password policy parameters could contain URLs
referencing an LDAP entry containing a dictionary or perl script.
If I were designing policies dealing with dictionaries or scripts, I would
consider designing the policy rule description to allow either to be used.
The dictionary parameter would be a URL, either a file URL or a LDAP URL.
Script extensions could be handled similarly.
So, are we talking about adding specific new policy rules to this document?
Or are we talking about how password policy could be extended?
John McMeeking
Howard Chu <hyc@highlandsun.com> wrote on 11/12/2004 05:23:43 PM:
> Neal-Joslin, Robert (HP-UX Lab R&D) wrote:
> > Hi John,
> >
> > Yes, that is roughly it. See in-line.
>
> >>Its looks more to me like what Bob really was after was a
> >>policy attribute
> >>that could be used to describe any rule -- assuming the
> >>server understood
> >>it.
> >>
> >>In that light, maybe my suggestion was a bit off the mark -
> >>or at least a
> >>quite different approach to the problem. I think it would be quite
> >>reasonable to define a multi-valued attribute, say pwdPolicyRule, that
> >>consisted of three parts:
> >>- name for this rule instance
> >>- OID for the rule it describes (server must implement this rule &
> >>advertise it?)
> >>- parameters for the rule, perhaps in some XML format - or
> >>maybe the whole
> >>attribute in XML.
>
> In general I dislike adding any feature in LDAP that is not itself also
> manageable by LDAP. But it appears that there may be no other choice
> here. For the Password Policy prototype that Neil Dunbar @ HP wrote, he
> added an attribute specifying the name of an external executable program
> to be used to validate the password. That punts the problem, but you can
> no longer view your entire policy with just an LDAP search, you need
> external knowledge.
>
> With respect to external dictionaries, I'd say just use LDAP search URLs
> and require the dictionary to exist as an LDAP entry.
>
> > XML would be fine, especially for readability. And XML format
> probably should be recommended. But I like the option of leaving
> the encoding up to the implementer. We're assuming that XML would
> suit everyone's needs. More importantly, the I would argue that we
> can't come up with a single DTD.
>
> XML is ok for representing data. But when you are talking about a
> collection of rules and behaviors, what you're talking about is really a
> program, and what would be best here would be a scripting language. perl
> would be well suited to the task, and I'm sure there are others.
>
> >>The attribute would use something like a "policy rule name"
> >>matching rule -
> >>i.e. each pwdPolicyRule value must have a unique name. This
> >>would allow
> >>multiple instances of a given rule OID.
> >>
> >>A combination of required chars and excluded character
> >>policies might look
> >>like (pardon my XML):
> >>
> >># requires 2 special characters, 1 from each of these sets:
> >>pwdPolicyRule: rule1 requiredchars-oid <rule count="1" chars="!@#$" />
> >>pwdPolicyRule: rule2 requiredchars-oid <rule count="1" chars="%^&" />
> >># vowels not allowed
> >>pwdPolicyRule: rule3 excludedchars-oid <rule chars="aeiouAEIOU" />
> >>
> >>I suppose a better version might be:
> >>pwdPolicyRule: <excludedCharsRule name="rule3" chars="aeiouAEIOU" />
> >>
> >
> > As I hinted in my last message, we may need an optional "Required
> Rule" field. For example, let's suppose I want to encode the
> following policy...
> >
> > "Password must have at least 4 characters and not be in a
> dictionary. It must also contain 3 of the following: 1 upper case
> character, 1 lower case character, 1 character of '!@#$%^&*()_+=[]-'
> or 1 numeric digit.
> >
> > To encode this, I would need a way to specify that "min 4" and
> "not in dictionary" are required. And in addition, I would need a
> rule that says at least 3 of the "non-required" rules must pass.
> >
> > Yes, this is getting ugly. And I don't want to hinder the
> progress of the pwd-policy draft.
>
> --
> -- Howard Chu
> Chief Architect, Symas Corp. Director, Highland Sun
> http://www.symas.com http://highlandsun.com/hyc
> Symas: Premier OpenSource Development and Support
>
> _______________________________________________
> 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