Hi,
I am currently migrating a users database to an OpenLDAP solution. I have to deal with some constraints for this project, namely password policy and/or password syntax checking.
Fortunately the ppolicy overlay already implements the draft-behera-ldap-password-policy, and offers the possibility to use pwdCheckModule to check password via external modules.
Unfortunately, I did not find any module meeting all my requirements:
The check_password() function, as defined in ppolicy, provides to the underlying module two parameters: - The entry being modified - The new password. Now to support per user settings, which is one of these requirements, I have to either store extra attributes among each entry, or the module has to perform a ldapsearch against the db.
An option is to modify the check_password() function so it sends the ppolicy object itself: int check_password (char *pPasswd, char **ppErrStr, Entry *pEntry, Entry *ppolicyEntry); This way people using external modules would just need to store their settings attributes in it.
As I don't want to break existing modules implementation, I have developed a simple overlay which enforces password syntax checking on a per user or per database basis. The overlay implements also the check_password() function so it can be used in conjunction with ppolicy.
I believe the code is clean enough to be contributed and I will be glad to upload it if you think it can be of any interest. However, I have some questions first.
The overlay allows me to define a default password constraints object at a database level, or a subentry in the user entry, in a similar way as the ppolicy_default setting and the pwdPolicySubentry attributes. This is so similar that I think it would be more relevant to extend the ppolicy overlay so it could support basic syntax checking. I understand the need to have the pwdCheckModule functionality, for those in need of exotics or platform dependent checks, but counting the characters belonging to a class is not harder than checking the min/max length of the password.
So to summarize:
- Could the check_password function be modified? - Could basic syntax checking be integrated in ppolicy?
And If none of these options are acceptable, should I upload the overlay I developed?
Of course I'm willing to help on the first two points.
Regards,
Mathieu wrote:
Hi,
I am currently migrating a users database to an OpenLDAP solution. I have to deal with some constraints for this project, namely password policy and/or password syntax checking.
Fortunately the ppolicy overlay already implements the draft-behera-ldap-password-policy, and offers the possibility to use pwdCheckModule to check password via external modules.
Unfortunately, I did not find any module meeting all my requirements:
The check_password() function, as defined in ppolicy, provides to the underlying module two parameters:
- The entry being modified
- The new password.
Now to support per user settings, which is one of these requirements, I have to either store extra attributes among each entry, or the module has to perform a ldapsearch against the db.
An option is to modify the check_password() function so it sends the ppolicy object itself: int check_password (char *pPasswd, char **ppErrStr, Entry *pEntry, Entry *ppolicyEntry); This way people using external modules would just need to store their settings attributes in it.
As I don't want to break existing modules implementation, I have developed a simple overlay which enforces password syntax checking on a per user or per database basis. The overlay implements also the check_password() function so it can be used in conjunction with ppolicy.
I believe the code is clean enough to be contributed and I will be glad to upload it if you think it can be of any interest. However, I have some questions first.
The overlay allows me to define a default password constraints object at a database level, or a subentry in the user entry, in a similar way as the ppolicy_default setting and the pwdPolicySubentry attributes. This is so similar that I think it would be more relevant to extend the ppolicy overlay so it could support basic syntax checking. I understand the need to have the pwdCheckModule functionality, for those in need of exotics or platform dependent checks, but counting the characters belonging to a class is not harder than checking the min/max length of the password.
So to summarize:
- Could the check_password function be modified?
Yes, but we would not release this change until OpenLDAP 2.5.
- Could basic syntax checking be integrated in ppolicy?
Maybe; please give more details on how you propose to specify the nature of each check.
And If none of these options are acceptable, should I upload the overlay I developed?
You're always free to submit code to the ITS.
Of course I'm willing to help on the first two points.
On Thu, Mar 17, 2011 at 4:20 PM, Howard Chu hyc@symas.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 character classes.
For example:
'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 the password.
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.
Note: 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.
-
Howard Chu -
Mathieu