Return-Path: X-Original-To: apmail-directory-dev-archive@www.apache.org Delivered-To: apmail-directory-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E9A3E18118 for ; Thu, 23 Jul 2015 17:07:33 +0000 (UTC) Received: (qmail 53175 invoked by uid 500); 23 Jul 2015 17:07:33 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 53123 invoked by uid 500); 23 Jul 2015 17:07:33 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 53113 invoked by uid 99); 23 Jul 2015 17:07:33 -0000 Received: from Unknown (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Jul 2015 17:07:33 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 24BCD1A778A for ; Thu, 23 Jul 2015 17:07:33 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.9 X-Spam-Level: ** X-Spam-Status: No, score=2.9 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-us-east.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id XE2Ff5uAfItU for ; Thu, 23 Jul 2015 17:07:23 +0000 (UTC) Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) by mx1-us-east.apache.org (ASF Mail Server at mx1-us-east.apache.org) with ESMTPS id B447043CC9 for ; Thu, 23 Jul 2015 17:07:22 +0000 (UTC) Received: by wicgb10 with SMTP id gb10so152157591wic.1 for ; Thu, 23 Jul 2015 10:07:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=M9uiPp1I2XK/ueSD+9s7npUa/2l7rGUTYW0+MAUmKZs=; b=IHUNXVDb5XQMylivnwaUoayqLgJ3RN9FNB1NRpEzr/lT+ecHHr/JnRogHjyOtRJt0Y S3o0bvXyS+N2Q/H4AzegR7uymFwBRslwu/hwrXzBmiOb+R3NzepEccXiU3axw8AOFLW5 p72ojyKDwCN6KQUhpHLQmt4kCmSB5LRXuqRyECO2K1NNnGkbwb8g9zZs2JavR8p6GkDZ LCVAyifb4aNJ9FMv9cWkt9rF0LvfdX2T65oJ1U9x0Ht4eW/EefecmP0kkuvynwr2fRM3 U8i4wSCeEkrvcZKHf5qTzTTYKQArB4wDXTsQM6v+yyODE4ZT1i7WTpu20Q0JJHk69c+7 vAew== MIME-Version: 1.0 X-Received: by 10.181.12.20 with SMTP id em20mr55502717wid.28.1437671235798; Thu, 23 Jul 2015 10:07:15 -0700 (PDT) Received: by 10.27.201.135 with HTTP; Thu, 23 Jul 2015 10:07:15 -0700 (PDT) In-Reply-To: <55B11D19.2040104@gmail.com> References: <55B11D19.2040104@gmail.com> Date: Thu, 23 Jul 2015 19:07:15 +0200 Message-ID: Subject: Re: pwdHistory and admin From: Pierre Smits To: Apache Directory Developers List Content-Type: multipart/alternative; boundary=f46d043bdfa2504986051b8deb85 --f46d043bdfa2504986051b8deb85 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable As i read the document, I could not establish the notion that admins are exempted. But I am inclined to agree that the (one and only) super user account could be immune to this. Given that there is controversy, we can establish our own ruling. However, we need to keep in mind that this potentially constitutes a security vulnerability and we should ask ourselves if we want to go down that path. It might endanger adoption. Best regards, Pierre Smits *ORRTIZ.COM * Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Thu, Jul 23, 2015 at 6:58 PM, Emmanuel L=C3=A9charny wrote: > Le 23/07/15 18:47, Theisen, Lucas a =C3=A9crit : > > The password policy RFC ( > http://tools.ietf.org/html/draft-behera-ldap-password-policy-10#section-8= .2.6) > is not very explicit, but it seems to me that an admin user account shoul= d > be exempt from the pwdHistory check. > > Agreed. > > > Its not uncommon (though ill advised) for admins to supply simple > temporary passwords, and if history is long enough, they may have already > done so with the same password. This is causing failures for me. I can > get around it be manipulating the pwdHistory beforehand, but that seems > like it should be unnecessary. What do you think? Should we enable admi= n > to avoid this check? > > The super admin (uid=3Dadmin, ou=3Dsystem) should be immune, IMHO. > > --f46d043bdfa2504986051b8deb85 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As i read the document, I could not establish the notion t= hat admins are exempted. But I am inclined to agree that the (one and only)= super user account could be immune to this.

Given that = there is controversy, we can establish our own ruling. However, we need to = keep in mind that this potentially constitutes a security vulnerability and= we should ask ourselves if we want to go down that path. It might endanger= adoption.

Best regards,

Pierre Smits

Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade

On Thu, Jul 23, 2015 at 6:58 PM, Emmanuel L= =C3=A9charny <elecharny@gmail.com> wrote:
Le 23/07/15 18:47, Theisen, Lucas a =C3=A9crit :
> The password policy=C2=A0 RFC (http://tools.ietf.org/html/draft-behera-ldap-password-policy-1= 0#section-8.2.6) is not very explicit, but it seems to me that an admin= user account should be exempt from the pwdHistory check.

Agreed.

>=C2=A0 Its not uncommon (though ill advised) for admins to supply simpl= e temporary passwords, and if history is long enough, they may have already= done so with the same password.=C2=A0 This is causing failures for me.=C2= =A0 I can get around it be manipulating the pwdHistory beforehand, but that= seems like it should be unnecessary.=C2=A0 What do you think?=C2=A0 Should= we enable admin to avoid this check?

The super admin (uid=3Dadmin, ou=3Dsystem) should be immune, IMHO.

--f46d043bdfa2504986051b8deb85--