From steven.legg@eb2bcom.com Wed Jul 1 22:57:43 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3572E3A6CF4 for ; Wed, 1 Jul 2009 22:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.678 X-Spam-Level: X-Spam-Status: No, score=0.678 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HOST_EQ_STATIC=1.172, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQ86Jznorvp0 for ; Wed, 1 Jul 2009 22:57:42 -0700 (PDT) Received: from eb2bcom.com (165.203.232.72.static.reverse.ltdomains.com [72.232.203.165]) by core3.amsl.com (Postfix) with ESMTP id 69EC93A69A6 for ; Wed, 1 Jul 2009 22:57:42 -0700 (PDT) Received: from eth3065.vic.adsl.internode.on.net ([150.101.156.248] helo=[192.168.1.182]) by host.eb2bcom.com with esmtpa (Exim 4.69) (envelope-from ) id 1MMFJ3-0007u9-HA; Thu, 02 Jul 2009 15:58:02 +1000 Message-ID: <4A4C4C63.3020106@eb2bcom.com> Date: Thu, 02 Jul 2009 15:57:55 +1000 From: Steven Legg User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Kurt Zeilenga References: <49C497F9.7010200@zioup.com> <49C870C6.4010803@zioup.com> <49CB192E.5050105@zioup.com> <49CB211C.6070108@eb2bcom.com> <49CB87FE.1050809@zioup.com> <49CC01DE.6040506@eb2bcom.com> <4A24557D.7030006@zioup.com> <4A26A05D.8040105@zioup.com> <245BF18B-2066-4E36-9502-16F4A3140D9E@Isode.com> <4A309775.3080406@zioup.com> <4A311ED1.1030202@stroeder.com> <4A31D27B.3090208@zioup.com> <35B2A165-CE5D-4650-AADE-CC233F71470E@Isode.com> <4A35D23D.5040307@zioup.com> <4A37BCEB.5040103@zioup.com> <68380E97-521C-4A80-A569-D09F8F626F6F@Isode.com> <4A3A1D81.1000407@stroeder.com> <32A3DDC8-FC80-490B-89A2-71ADC9582190@Isode.com> <4A4A8E14.5020909@stroeder.com> <5EF85B07-379E-4549-8112-17B9D0428589@Isode.com> In-Reply-To: <5EF85B07-379E-4549-8112-17B9D0428589@Isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.eb2bcom.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - eb2bcom.com X-Source: X-Source-Args: X-Source-Dir: Cc: ldapext@ietf.org, =?ISO-8859-1?Q?Michael_Str=F6der?= Subject: Re: [ldapext] UTF-8 full support in LDIF / LDIF v2 X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jul 2009 05:57:43 -0000 Kurt, Kurt Zeilenga wrote: > > On Jun 30, 2009, at 3:13 PM, Michael Ströder wrote: [snip] >> I agree that LDIF is just an alternative encoding of protocol data >> units. So lifting the ASCII limitation in LDIF would IMO not introduce >> any other problem a LDAP client with user interface does not already >> have today (despite the new-line issue). > > Removing the ASCII restriction will mean that users and systems will > need to be far more careful in how they transfer LDIF data. Today, one > can email LDIF files about, FTP them without putting clients in "binary" > mode, etc, because of the ASCII restriction. Without this restriction, > users and systems will have to be quite careful to ensure transfers > preserve the LDIF data octet-for-octet. [snip] I'm broadly in agreement with Michael that extended LDIF and LDAP clients face much the same issues, but there is one way in which they differ. If I use a client to edit an attribute value, then the scope of invisible, inadvertent changes is probably that one value (which I'm changing anyway), or if it is a poor client, then maybe the whole attribute or whole entry. If I carelessly edit or transmit an extended LDIF dump, then the scope of inadvertent changes is the entire collection of entries in the dump. As a way to mitigate wholesale inadvertent changes I suggest that the extended format should allow each attribute value with non-ASCII characters that is presented in the clear to be optionally followed by the same value in the base64 encoding. The format would be designed so that the following base64 encoding is clearly paired with the value in the clear rather than it being the next attribute value that happens to be base64 encoded. The paired base64 encoding, if present, will always take precedence over the value in the clear. That is, on parsing, the base64 encoding is used and the value in the clear is ignored. Normal practice for directory servers when outputting non-ASCII values in the clear would be to pair them up with their base64 encoding. Anyone manually editing the dump file has to remember to remove the base64 encoding part for a change to the value in the clear to be accepted, which is a minor inconvenience. However, any inadvertent changes to other values in the clear won't have any effect because their base64 encoded parts will still be there, and the extended LDIF format will be just as robust as normal LDIF for transport around the network. When composing data from non-directory data sources to import into a directory, the values can still be conveniently presented in the clear without needing to generate a base64 encoding for them. When extracting data from the directory to feed into other systems the values in the clear can be used and the base64 encoded parts ignored. Comments anyone ? Regards, Steven From hyc@highlandsun.com Fri Jul 3 20:02:40 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F7FD3A6CF2 for ; Fri, 3 Jul 2009 20:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvS5YCQjCeW3 for ; Fri, 3 Jul 2009 20:02:39 -0700 (PDT) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by core3.amsl.com (Postfix) with ESMTP id 32DE03A6BB6 for ; Fri, 3 Jul 2009 20:02:39 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id C6E1883EFA; Fri, 3 Jul 2009 23:02:35 -0400 (EDT) Message-ID: <4A4EC639.3070706@highlandsun.com> Date: Fri, 03 Jul 2009 20:02:17 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; rv:1.9.1b5pre) Gecko/20090630 SeaMonkey/2.0a1pre Firefox/3.0.3 MIME-Version: 1.0 To: John McGarvey References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org, Kurt Zeilenga Subject: Re: [ldapext] Unfinished business: password policy and VLV X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 03:02:40 -0000 John McGarvey wrote: > > Kurt, > > It seems questionable to introduce a new password policy approach when > many existing servers implement a form of the Behera draft. I suspect > that the result would not be widely implemented. And another year goes by... I have to agree. Whatever problems exist with the Behera draft should be fixed, rather than launching another completely different proposal. Going thru Appendix A of http://tools.ietf.org/html/draft-zeilenga-ldap-passwords-00 re: the "guessing limit" - as braindead as this feature may be, many sites are required to support it due to Sarbanes-Oxley or various other government regulations. I think the best thing to do here is note that it is bass-ackwards from a security point of view, but because ignorant policy makers require it, it is included in the spec. I.e., provide the feature but fully document why it's a bad feature and provide alternatives to use in its place. re: lockout - it may be beyond the scope of "password policy" management but the solution is needed. In the absence of any additional work occurring in this area in a year and a half, it seems best to simply expand the scope of this spec - to include rudimentary account management - and define formal mechanisms for account expiration and disablement. re: grace logins - time-limited is certainly more sensible. re: disallowing user password changes - ok. re: protocol extension - that section appears to be missing from the draft. While providing this info at other times may be useful, the most common case for users to interact with the password policy machinery is at login time, so it's not clear what other cases you wanted to allow for. If I successfully change my password and get a reply "by the way - your password will expire in 90 days" I will promptly forget it, nor do I actually need to spend any time thinking about it until shortly before it expires again. re: bind and compare - ok, certainly we should discourage use of Compare as an authentication method. re: DSA-generated passwords - ok, let's add this to Behera. re: password min length and max length - ok. re: password history - ok, time-based is better. re: password history storage - it may be a local matter, but I think we should still provide an Informational definition here, because leaving it up to each individual site to implement will cause too much wheel-reinvention and will harm interoperability. At this point we have several years worth of accumulated experience with deployments of the Behera draft. We shouldn't throw that away. Most of the issues you address can be fixed as an incremental revision of Behera. Requests for an absolute expiration/lockout mechanism keep coming up time and again. It's too small a feature to merit its own document. We should simply add a couple new attributes to the existing Policy schema and be done with it. Another item that has come up from my perusal of Kerberos KDC policy - in addition to specifying a time when a password stops being valid, it would be nice to provide an attribute specifying the time when a password *starts* being valid. For password constraints, a regexp constraint would definitely be useful. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From Kurt.Zeilenga@Isode.com Sat Jul 4 06:59:45 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E38263A6BC3 for ; Sat, 4 Jul 2009 06:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XKDzThxJMr5 for ; Sat, 4 Jul 2009 06:59:45 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 550EA28C29A for ; Sat, 4 Jul 2009 06:59:38 -0700 (PDT) Received: from [192.168.1.102] ((unknown) [75.141.233.128]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 4 Jul 2009 15:00:01 +0100 X-SMTP-Protocol-Errors: NORDNS Message-Id: From: Kurt Zeilenga To: Howard Chu In-Reply-To: <4A4EC639.3070706@highlandsun.com> Date: Sat, 4 Jul 2009 06:59:54 -0700 References: <4A4EC639.3070706@highlandsun.com> X-Mailer: Apple Mail (2.935.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org Subject: Re: [ldapext] Unfinished business: password policy and VLV X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2009 13:59:46 -0000 Howard, I note that the ITU/ISO has been working on a X.500 Password Policy mechanism, see . I would argue that if the IETF is to do anything in the area of password policy standardization, it should consider simply adapting the X.500 mechanism for use in LDAP. I encourage those who have issue with the ITU/ISO proposal to comment on the X.500 mailing list, see . -- Kurt From hyc@highlandsun.com Mon Jul 6 17:37:47 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E38F428C134 for ; Mon, 6 Jul 2009 17:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DKrJ38bDDpmh for ; Mon, 6 Jul 2009 17:37:46 -0700 (PDT) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by core3.amsl.com (Postfix) with ESMTP id AF0A03A6919 for ; Mon, 6 Jul 2009 17:37:46 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id C4B5910F96; Mon, 6 Jul 2009 20:36:16 -0400 (EDT) Message-ID: <4A52986B.80001@highlandsun.com> Date: Mon, 06 Jul 2009 17:35:55 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; rv:1.9.1b5pre) Gecko/20090630 SeaMonkey/2.0a1pre Firefox/3.0.3 MIME-Version: 1.0 To: Kurt Zeilenga References: <4A4EC639.3070706@highlandsun.com> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org Subject: Re: [ldapext] Unfinished business: password policy and VLV X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2009 00:37:48 -0000 Kurt Zeilenga wrote: > Howard, > > I note that the ITU/ISO has been working on a X.500 Password Policy > mechanism, see n=Ig.Extension>. I would argue that if the IETF is to do anything in > the area of password policy standardization, it should consider simply > adapting the X.500 mechanism for use in LDAP. > > I encourage those who have issue with the ITU/ISO proposal to comment > on the X.500 mailing list, see >. I've sent an initial set of comments to the X.500 list. It seems that a number of the concerns you raised with the Behera spec are already addressed in their current draft. E.g., they at least mention the DOS problems with failure-based lockouts, providing policy state attributes for delaying instead of plain lockouts. The X.500 draft also supports time-based password history limiting and grace logins, which looks good. It has some obvious flaws too, such as storing the pwdExpirationDate instead of just computing it from pwdChangedTime and pwdExpireAge. In the meantime, whether we discuss this in the X.500 context or here, I'd like to add these features in addition to what has already been discussed: a) pwdStartDate - when the credential becomes valid b) pwdLastSuccess - date of the last successful authentication c) pwdMaxIdle - interval after which account is locked if no successful auth occurs And also an extended op "ExternalBind" for allowing external authentication providers to interact with the existing policy. I.e., this op will supply an LDAP username and a success/fail code to the directory server, and the server will execute the policy mechanisms accordingly. (E.g., if a Fail code is supplied then the failure time and any relevant lockouts are recorded.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From hyc@highlandsun.com Mon Jul 13 08:44:27 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE4BF3A6DE0 for ; Mon, 13 Jul 2009 08:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.562 X-Spam-Level: X-Spam-Status: No, score=-1.562 tagged_above=-999 required=5 tests=[AWL=-0.453, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQulzmEosmxX for ; Mon, 13 Jul 2009 08:44:25 -0700 (PDT) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by core3.amsl.com (Postfix) with ESMTP id BCCD03A67F3 for ; Mon, 13 Jul 2009 08:44:25 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id 277B010F96; Mon, 13 Jul 2009 11:44:56 -0400 (EDT) Message-ID: <4A5B5661.3070609@highlandsun.com> Date: Mon, 13 Jul 2009 08:44:33 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; rv:1.9.1b5pre) Gecko/20090630 SeaMonkey/2.0a1pre Firefox/3.0.3 MIME-Version: 1.0 To: John McGarvey References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ldapext@ietf.org Subject: Re: [ldapext] Unfinished business: password policy and VLV X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2009 15:44:27 -0000 John McGarvey wrote: > > LDAP password policy and VLV (scrolling view browsing) are implemented > by a number of LDAP servers, more or less in accordance with now expired > drafts. Both of these extensions are quite valuable, and both now have > multiple independent implementations, but there are no corresponding > RFCs. Is there a plan to get these drafts back on track? It seems to me > that there should be. While we're on the topic, the VLV draft is missing a feature to release the search context. E.g., in PagedResults if the client sends a control with PageSize set to 0 then the paging context is abandoned/released and no further results are returned. The VLV spec is written from the perspective of using a persistent dedicated DB index to satisfy the requests, so it doesn't take releasing of resources into account. But it also doesn't *require* a persistent index for the implementation. In the case where a temporary/transient index is used, currently the only way to release the resources is by closing the connection, which is not very friendly. It seems that the tone of this discussion only went toward documenting current practice, but it would be nice to fix the flaws along the way. > John McGarvey > IBM directory architect > 919-877-4892 or t/l 254-4892 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ From hyc@highlandsun.com Tue Jul 14 17:38:07 2009 Return-Path: X-Original-To: ldapext@core3.amsl.com Delivered-To: ldapext@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 398BE3A67FA for ; Tue, 14 Jul 2009 17:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8-q56LMqWKw for ; Tue, 14 Jul 2009 17:38:06 -0700 (PDT) Received: from mail.highlandsun.com (mail.highlandsun.com [70.87.222.79]) by core3.amsl.com (Postfix) with ESMTP id 18A173A67A5 for ; Tue, 14 Jul 2009 17:38:06 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by mail.highlandsun.com (Postfix) with ESMTP id 73B9A10F97 for ; Tue, 14 Jul 2009 20:37:29 -0400 (EDT) Message-ID: <4A5D24C9.7070009@highlandsun.com> Date: Tue, 14 Jul 2009 17:37:29 -0700 From: Howard Chu User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; rv:1.9.1b5pre) Gecko/20090630 SeaMonkey/2.0a1pre Firefox/3.0.3 MIME-Version: 1.0 To: Ldapext Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [ldapext] Fwd: Re: [x500standard] Re: New draft on password policy X-BeenThere: ldapext@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: LDAP Extension Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 00:38:07 -0000 Food for thought re: pwdQuality checking rules, not sure where this discussion needs to be centralized. One way or another, I would like to get a new revision of the LDAP ppolicy draft written up with some of the additions I've already outlined and move ahead on implementation. -------- Original Message -------- Subject: Re: [x500standard] Re: New draft on password policy Date: Tue, 14 Jul 2009 17:35:03 -0700 From: Howard Chu To: x500standard@freelists.org Howard Chu wrote: > Section 18.1.6: > a) why is pwdQualityRule single-valued? Without an initial set of rules to > serve as examples, it's difficult to evaluate the usefulness of this > attribute. I would expect that multiple orthogonal rules will be defined and > that a policy would allow combinations of these rules to be chosen. IMO this > attribute should be multi-valued and at least one or two prototypical rules > need to be part of the spec. As an example, a rule that validates the > plaintext of a password against a regular expression would be useful. In thinking about what custom modules we've implemented for this in the past, I propose a couple rules for usage. First of all, assume that pwdQualityRule is multivalued, where each value defines a single type of rule, and a given password must pass every rule to be valid. regexp: expression Succeeds if the password matches the expression dict: URL Succeeds if the password is not found in a word list residing at the given URL scan: LDAPURL Succeeds if the specified LDAP query returns no matching entry I suppose the use of an LDAPURL here may be inconvenient, but I don't recall seeing X.500 URLs in wide use. In practice I would prefer a Compare operation which must return CompareFalse to succeed, but the LDAPURL format is too braindead and only supports Searches. (I have an overlay for OpenLDAP which supports this feature: do a compare on a magic DN and the argument is processed with cracklib.) "dict" may be too simplistic since it presumably wouldn't account for case variations and other simple transformations of common dictionary words. Again, in OpenLDAP we punted this to an externally loadable module because spelling out a variety of transformations here was too awkward. Since the most commonly used module just calls cracklib, perhaps "cracklib" itself should be one of the pwdQualityRule types. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/