You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by "Theisen, Lucas" <lt...@mitre.org> on 2015/07/23 18:47:48 UTC
pwdHistory and admin
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 should be exempt from the pwdHistory check. 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 admin to avoid this check?
Thank You,
Lucas Theisen
ltheisen@mitre.org
Re: pwdHistory and admin
Posted by Lothar Haeger <lo...@brummelhook.com>.
Sounds advisable to me, this is how Edirectory handles admin password resets, btw.. Not just to prevent reuse of simple temp passwords, but also to prevent
a) telling admins real previous passwords that could still be in use elsewhere or
b) giving hints on a user's password scheme which may enable the admin to guess current/future passwords.
For that reason only a user himself must be able to see the "already in history" type of error on a password change. Admins should be able to set any password for other accounts, as long as it adhere's to the password complexity policy.
Cheers, Lothar
> Am 23.07.2015 um 18:47 schrieb Theisen, Lucas <lt...@mitre.org>:
>
> The password policy RFC (http://tools.ietf.org/html/draft-behera-ldap-password-policy-10#section-8.2.6 <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 should be exempt from the pwdHistory check. 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 admin to avoid this check?
Re: pwdHistory and admin
Posted by Pierre Smits <pi...@gmail.com>.
Thanks, Emmanuel. I would say that such also constitutes an adoption risk.
Reinstalling a in-production setup is not an option!? I wonder how our
major competitors are handling/selling this.
Best regards,
Pierre Smits
*ORRTIZ.COM <http://www.orrtiz.com>*
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com
On Thu, Jul 23, 2015 at 8:09 PM, Emmanuel Lécharny <el...@gmail.com>
wrote:
> Le 23/07/15 19:07, Pierre Smits a écrit :
> > 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.
>
> Consider that it's like the Unix root's password. Would it be locked,
> you would have no other option than to reinstall the system...
>
>
>
Re: pwdHistory and admin
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 23/07/15 19:07, Pierre Smits a écrit :
> 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.
Consider that it's like the Unix root's password. Would it be locked,
you would have no other option than to reinstall the system...
Re: pwdHistory and admin
Posted by Pierre Smits <pi...@gmail.com>.
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 <http://www.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écharny <el...@gmail.com>
wrote:
> Le 23/07/15 18:47, Theisen, Lucas a écrit :
> > 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 should
> 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 admin
> to avoid this check?
>
> The super admin (uid=admin, ou=system) should be immune, IMHO.
>
>
Re: pwdHistory and admin
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 23/07/15 18:47, Theisen, Lucas a écrit :
> 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 should 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 admin to avoid this check?
The super admin (uid=admin, ou=system) should be immune, IMHO.