[389-users] Re: global passwd policy for DS with existing users

On 9/14/21 3:15 PM, Mark Reynolds wrote:

On 9/10/21 5:14 PM, Ghiurea, Isabella wrote:

·        Thank you Mark,

·         I am considering  the  DS global password Policy with  the configuration to have the users  "must" change their passwords according to a schedule.

If the schedule is fixed delay of validity of reset password, then you may have look a temporary password rules https://www.port389.org/docs/389ds/design/otp-password-policy.html.

regards

·        Since there are already 6K users in DS  with  no password policy in place I am thinking for start we shall  force and update each uid userPassword attribute ( running a script in DS),

·        and next step  configure the DS for global password policy with  the new attributes in place ( which specific attributes you suggest?)

That is up to you which policies you want to use.

·        and the last step when the users are trying to logging they must change their passw since their old passwd was removed already.

If you remove their old password then they can not reset their password since they can not even log in.  It would need to be done by a different entry/user.  I do not recommend removing the userpassword attribute from your entries.

If you want to force all your users to reset their passwords then you need to set "passwordMustChange" to "on", and set the passwordExpirationtime to "19700101000000Z".  This will force users to have to reset their passwords after they log in.

·         How is this  design option sounds ?

·          I assume  for the  new passwd  policy  the following attributes will need to be configured : passwordExp - , passwordMaxAge , passwordWarning ,passwordMustChange passwordGracelimit – is this correct ?

If these are the settings you want, then yes.  There is no single recommendation that fits everyone's needs. 

·         

·         The two DSs  are configured in multimaster replication  and  another  DS acting as slave cfg   in master to slave ( only reads  accepted) , from what I read will need to configure each  of the master DS   with  same Password Policy correct ?

Correct

Also see:

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication-replicating-password-attributes

·         How about the slave DS any configuration changes  and which ones ?

You need to set the password policies the same on all servers, or else those servers will not enforce the password policies.

HTH,
Mark

·        Thank you

·        Isabella

 

 

From: Mark Reynolds [mailto:mreynolds@redhat.com]
Sent: September 10, 2021 12:38 PM
To: General discussion list for the 389 Directory server project. <389-users@lists.fedoraproject.org>; Ghiurea, Isabella <Isabella.Ghiurea@nrc-cnrc.gc.ca>
Subject: Re: [389-users] global passwd policy for DS with existing users

 

***ATTENTION*** This email originated from outside of the NRC. ***ATTENTION*** Ce courriel provient de l'extérieur du CNRC

 

On 9/10/21 1:46 PM, Ghiurea, Isabella wrote:

Hi List,

I need your expertise  , I am looking to configure global  password policy for an existing DS  with  aprox 7 k users, at present we are using only the userPassword attribute  , no extra password plugins or  attributes are  enabled , the DS is running 1.3.7.5-24.el7_5.x86_64

What is the  less intrusive  solution to implement  a  global Password Policy  and cfg  attributes  for all   existing user accounts  without sending each user emails notification to reset their password ?  I  understand the Password Policy will take effect  only after the users passwords  are  reset , is this correct ?

Depends...

You are not being specific about what password policy you want to implement, there are countless variations.  Some require the password to be reset to start working, others do not.  So please let us know exactly what you want to implement from password policy so we can answer your questions.  For example there is password history, password expiration, password warning, grace periods, syntax checking, account lockout, etc. Each one has its own behavior and configuration.

If you are not sure what you want to implement then I recommend looking over the admin guide to see more details on the password policy options:

https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/user_account_management-managing_the_password_policy

HTH,

Mark

_______________________________________________

389-users mailing list -- 389-users@lists.fedoraproject.org

To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org

Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/

List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines

List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org

Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

-- 

Directory Server Development Team

_______________________________________________  389-users mailing list -- 389-users@lists.fedoraproject.org  To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines  List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure  

--   Directory Server Development Team

_______________________________________________  389-users mailing list -- 389-users@lists.fedoraproject.org  To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines  List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org  Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure