[Date Prev][Date Next]
Re: Overlay supporting password syntax checking
- To: Howard Chu <firstname.lastname@example.org>
- Subject: Re: Overlay supporting password syntax checking
- From: Mathieu <email@example.com>
- Date: Tue, 29 Mar 2011 23:53:00 +0200
- Cc: OpenLDAPfirstname.lastname@example.org
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=30IkP001/Pbe7TowOSKCWgJT2HFD+IDZFAAmbnL0y+0=; b=rixGQFzVjqHKfVPmDZgXTWAPv+9qPsOAJAizrVxuHy3DW8B9sTJeeSO9oBUuczW1I+ 1l3RSPAlefUsJ4h9jg1qe/VpD/h+Ft7KM+Zo23Oln7dDcHYiCEr9coUmmsMucQTKqjRy FTcuAkUAtLMKyd9w8qw7aKJas6SLEK+fVveZo=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZoohHW+kJlw51ZNWXK4XkaaC9hzQQJEL+FVImpLMlLp//HzlALIzOw5NPJqwfoarel wKW7N552djuoh7dZ0svdLjTDR8pWyjlijjUjwhhELjaU26O8SgvxaOjAiEWMwnf1j1r2 MHMwhu7k1kCL1Ds+F7bfovRZFCt4dHoQWFcm8=
- In-reply-to: <4D8226C7.email@example.com>
- References: <AANLkTi=ZwWU=-tTu5bhhvJC9sxaJD46Gvu9mdR+jvEby@mail.gmail.com> <4D8226C7.firstname.lastname@example.org>
On Thu, Mar 17, 2011 at 4:20 PM, Howard Chu <email@example.com> wrote:
> Yes, but we would not release this change until OpenLDAP 2.5.
Perfect, that will leave some time to define exactly how to change it
without breaking any existing implementation.
> Maybe; please give more details on how you propose to specify the nature of
> each check.
I've filled an ITS with the pwdconstraint overlay which implements
such checks, it could be used as an example to enhance ppolicy.
Basically it relies on LDAP attributes associated with Posix-style
'pwdConstraintAlpha' is associated with the class [:alpha:],
'pwdConstraintDigit' is associated with the class [:digit:],
and so on for all needed character classes. Of course these attributes
would have to be adapted to fit in pwdPolicy.
Now there are two ways of specifying the checks:
- either the attributes contain a Boolean, in which case a value of
'TRUE' means the password MUST contain at least one character
belonging to the associated class, and a value of 'FALSE' forbid such
a character in the password.
- or the attributes contain an integer, in which case a value n > 0
means the password MUST contain at least n character(s) belonging to
the associated class, and a value n <= 0 forbid such a character in
Then another attribute is needed, 'pwdConstraintQuality'.
This attribute contains the minimal number of syntactic constraints a
password must respect in order to be accepted.
Finally the password is checked against all defined constraints:
- If the password contains a forbidden character, it is always rejected.
- If the password respects all (or at least n) constraints, it is accepted.
The second method is implemented in the overlay (using the regcomp
function), however the first method is probably the most common
use-case for everyone.