directory manager bypassing password policies, alternatives?

[Eric Freeman]

After upgrading from 389 version 1.2.11.15-33.el6_5.x86_64 to
1.2.11.15-97.el6_10.x86_64, we're finding that the Directory Manager
account can bypass configured password policies and set user passwords to
anything. I believe this is now by design, but is there a configuration
file flag to revert to the previous behavior where Directory Manager needed
to conform to the password policy?

If not, how do we create a user account in 389 ldap server with rights to
check and update user password hashes, and still enforce configured
password policies?

Please advise

help. directory manager bypassing password policies, alternatives?

[Eric Freeman]

Between 389 LDAP versions 1.2.11.15-33 and 1.2.11.15-97, we're finding that
the Directory Manager account can bypass configured password policies and
set user passwords to anything. I believe this is now by design, but is
there a configuration file flag to revert to the previous behavior where
Directory Manager needed to conform to the password policy?

If not, how do we create a user account in 389 ldap server with rights to
check and update user password hashes, and still enforce configured
password policies?

Please advise

help. directory manager bypassing password policies, alternatives?

[Mark Reynolds]

On 6/3/19 1:16 PM, Eric Freeman wrote:
>  Between 389 LDAP versions 1.2.11.15-33 and 1.2.11.15-97, we're finding 
>  that the Directory Manager account can bypass configured password 
>  policies and set user passwords to anything. I believe this is now by 
>  design, but is there a configuration file flag to revert to the 
>  previous behavior where Directory Manager needed to conform to the 
>  password policy? 
Sorry there is not.
>  If not, how do we create a user account in 389 ldap server with rights 
>  to check and update user password hashes, and still enforce configured 
>  password policies? 
You create a new user, and you add an ACI to the suffix to allow this 
user to update passwords.


Create a user, something like this

dn: uid=password update user,ou=people,dc=example,dc=com


Add "aci" to the suffix to allow this user rights to update userpassword

ldapmodify -D "cn=directory manager" -W
dn: dc=example,dc=com
changetype: modify
add: aci
aci: (targetattr = "userPassword") (version 3.0; acl "Allow user to 
update passwords"; allow (write) (userdn = "ldap:///uid=password update 
user,ou=people,dc=example,dc=com");)


That should do it.

HTH,

Mark


>  Please advise
>
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]...

[William Brown]

>  On 3 Jun 2019, at 19:13, Eric Freeman <efreem01(a)gmail.com&gt;
> wrote:
>  
>  After upgrading from 389 version 1.2.11.15-33.el6_5.x86_64 to 1.2.11.15-97.el6_10.x86_64,
> we're finding that the Directory Manager account can bypass configured password
> policies and set user passwords to anything. I believe this is now by design, but is there
> a configuration file flag to revert to the previous behavior where Directory Manager
> needed to conform to the password policy? 
>  
>  If not, how do we create a user account in 389 ldap server with rights to check and
> update user password hashes, and still enforce configured password policies? 
I would assume that you would give an account an aci that allows targetAttr userPassword
with the ability to write to them, and set the scope to an ou/subtree of some nature. 

Does that help? 

>  
>  Please advise
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]... 
—
Sincerely,

William Brown

Senior Software Engineer, 389 Directory Server
SUSE Labs

[Eric Freeman]

Yes, thanks!

On Fri, Jun 7, 2019, 5:49 AM William Brown <wbrown(a)suse.de&gt; wrote:

>  > On 3 Jun 2019, at 19:13, Eric Freeman <efreem01(a)gmail.com&gt; wrote:
>  >
>  > After upgrading from 389 version 1.2.11.15-33.el6_5.x86_64 to
>  1.2.11.15-97.el6_10.x86_64, we're finding that the Directory Manager
>  account can bypass configured password policies and set user passwords to
>  anything. I believe this is now by design, but is there a configuration
>  file flag to revert to the previous behavior where Directory Manager needed
>  to conform to the password policy?
>  >
>  > If not, how do we create a user account in 389 ldap server with rights
>  to check and update user password hashes, and still enforce configured
>  password policies?
>
>  I would assume that you would give an account an aci that allows
>  targetAttr userPassword with the ability to write to them, and set the
>  scope to an ou/subtree of some nature.
>
>  Does that help?
>
>  >
>  > Please advise
>  > _______________________________________________
>  > 389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  > To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  > List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]...
>
>  —
>  Sincerely,
>
>  William Brown
>
>  Senior Software Engineer, 389 Directory Server
>  SUSE Labs
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]...
>