On Dec 13, 2007, at 4:47 AM, Hallvard B Furuseth wrote:
> kurt(a)OpenLDAP.org writes:
>> There are lots of existing ways of searching an admin guide.
>>
>> First, most web search engines can be told to localize their search
>> to
>> a set of pages. For instance:
>> http://www.google.com/search?q=site:www.openldap.org/doc/
>> admin24+rwm
>
> Not everyone knows how to do that.
Right, not everyone knows how to make the fullest of the tools
available to them, or even know what tools are available to them. I
don't see providing yet another tool as a solution to these problems.
-- Kurt
mbackes(a)symas.com wrote:
> Full_Name: Matthew Backes
> Version: 2.3, 2.4, head, etc
> OS: all
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (67.115.65.234)
>
>
> When receiving a new userPassword, slapo-ppolicy checks to see if that password
> matches the hash already present in userPassword, and disallows it if this is
> the case.
>
> This is a sensible default for most circumstances, as otherwise the user could
> reset their age counters by using the same password.
>
> Unfortunately, it also blocks arguably-legitimate password changes; e.g. when
> migration to SSHA from CRYPT where the first 8 chars of the new password match
> the old.
>
> This patch changes this userPassword-has-changed check to only apply if there is
> a password policy defined which requires it; in particular, any of pwdInHistory,
> pwdMinAge, pwdMaxAge, pwdCheckQuality, or pwdMustChange must apply for this
> check to be enforced.
Rereading draft-behera, it says
5.2.4 pwdInHistory
This attribute specifies the maximum number of used passwords stored
in the pwdHistory attribute.
If this attribute is not present, or if the value is 0, used
passwords are not stored in the pwdHistory attribute and thus may be
reused.
As such the test can be simplified. Committing to HEAD.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
I did some minor cleanup and committed this. I think there may be other
changes that could be made, to take advantage of sorted values and so cut down
on the overhead of managing groups with large numbers of members.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
hyc(a)symas.com wrote:
> This looks mostly like ACI to me, with some special inheritance rules. Is it
> still relevant?
AFAIR that was a custom ACL checking development that I found
interesting from a technical point of view but (I might be wrong) of
limited usefulness outside the scope it was developed for. In the
meanwhile, and probably triggered by that posting, I added several ways
of customizing access checking: via overlays, using dynacl (that was
added earlier, for the purpose of isolating ACIs, but it could have
served the same purpose). In this sense, I don't think this
contribution can be of any use right now; it coulr be turned into a
dynacl for custom use by the posters, or by anyone who find it useful.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
hyc(a)symas.com wrote:
> In reviewing the patch, I see several small details that need to be fixed.
> E.g., you added a config keyword but re-used an existing OID for your new
> attribute. OIDs must never be re-used, and certainly you must not use two
> different attributes with the same OID.
Oh never mind, I see the confusion. You're just defining a new 2nd argument to
the existing keyword.
> You use strlen/strncat, which are heavily discouraged in our code. (We never
> use strcat/strncat; we use strlen only when it's unavoidable.) (Some uses of
> strlen already existed in constraint.c; we just didn't get around to
> eliminating them.) In general we use bervals instead of flat strings, and
> there's almost never a reason to count string lengths at runtime.
>
> I got 3 rejects when applying the patch to my source tree (current HEAD).
>
> I think these points can all be cleaned up pretty easily. Let me know if you
> need any particular pointers.
I'm working on getting this to build now.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
In reviewing the patch, I see several small details that need to be fixed.
E.g., you added a config keyword but re-used an existing OID for your new
attribute. OIDs must never be re-used, and certainly you must not use two
different attributes with the same OID.
You use strlen/strncat, which are heavily discouraged in our code. (We never
use strcat/strncat; we use strlen only when it's unavoidable.) (Some uses of
strlen already existed in constraint.c; we just didn't get around to
eliminating them.) In general we use bervals instead of flat strings, and
there's almost never a reason to count string lengths at runtime.
I got 3 rejects when applying the patch to my source tree (current HEAD).
I think these points can all be cleaned up pretty easily. Let me know if you
need any particular pointers.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
I think this is in general a bad idea. It's already noted as such in the
README, which is fine. The code generally looks pretty good, although it would
need to be updated for cn=config support. Does anyone else see a reason to
integrate this and get it working with cn=config?
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Full_Name: Matthew Backes
Version: 2.3, 2.4, head, etc
OS: all
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (67.115.65.234)
When receiving a new userPassword, slapo-ppolicy checks to see if that password
matches the hash already present in userPassword, and disallows it if this is
the case.
This is a sensible default for most circumstances, as otherwise the user could
reset their age counters by using the same password.
Unfortunately, it also blocks arguably-legitimate password changes; e.g. when
migration to SSHA from CRYPT where the first 8 chars of the new password match
the old.
This patch changes this userPassword-has-changed check to only apply if there is
a password policy defined which requires it; in particular, any of pwdInHistory,
pwdMinAge, pwdMaxAge, pwdCheckQuality, or pwdMustChange must apply for this
check to be enforced.
RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/ppolicy.c,v
retrieving revision 1.110
diff -u -r1.110 ppolicy.c
--- ppolicy.c 17 Nov 2007 12:39:19 -0000 1.110
+++ ppolicy.c 15 Dec 2007 03:21:27 -0000
@@ -1776,7 +1776,13 @@
* Last check - the password history.
*/
/* FIXME: no access checking? */
- if (slap_passwd_check( op, NULL, pa, bv, &txt ) == LDAP_SUCCESS)
{
+ if (( pp.pwdInHistory
+ || pp.pwdMinAge
+ || pp.pwdMaxAge
+ || pp.pwdCheckQuality
+ || pp.pwdMustChange ) /* make sure we care */
+ && ( slap_passwd_check( op, NULL, pa, bv, &txt )
+ == LDAP_SUCCESS )) {
/*
* This is bad - it means that the user is attempting
* to set the password to the same as the old one.
I was looking at this code in relation to current HEAD/RE24, and things have
changed quite a bit. Given the ability to dynamically load schema into
cn=config, is there still a need for this module? (It is in fact the changes
made for dynamic schema manipulation in slapd that causes the compatibility
issues with this module.)
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/