Re: global passwd policy for DS with existing users

[Thierry Bordaz <tbordaz@xxxxxxxxxx>]

On 9/14/21 4:33 PM, Ghiurea, Isabella wrote:

Thank you   both of you ,

From the documentation pointed by Thierry , seem the TPR ( Temporary  Password Rule)  can be the solution to have all users existing  old password updated/force update by DS Manager( with ldap modify)  and  only next  when the user  logging for first time will force to change the passwd according to the  Password Expiration Policy cfg in DS,will this design works?

This description is fulfill with passwordMustChange only. When DM reset the password, the only thing that the user can do after he binds (using the reset password) is to change his password.

TPR just extends that mechanism with:

• If the user does not bind/change password within a fixed delay, then the reset password expires (temporary password)
• If the user authenticate (successfully or not) more than a fixed number of time, then the reset password expires.
• The reset password is valid to authenticate a fixed delay after the reset time

regards
thierry

 

Isabella

 

From: Thierry Bordaz [mailto:tbordaz@xxxxxxxxxx]
Sent: September 14, 2021 7:13 AM
To: General discussion list for the 389 Directory server project. <389-users@xxxxxxxxxxxxxxxxxxxxxxx>; Mark Reynolds <mreynolds@xxxxxxxxxx>; Ghiurea, Isabella <Isabella.Ghiurea@xxxxxxxxxxxxxx>
Subject: Re: [389-users] Re: 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/14/21 3:15 PM, Mark Reynolds wrote:

 

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

1.     Thank you Mark,

2.      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

 

3.     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),

4.     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.

5.     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.

6.      How is this  design option sounds ?

7.       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. 

8.      

9.      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

10.   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

11.  Thank you

12.  Isabella

 

 

From: Mark Reynolds [mailto:mreynolds@xxxxxxxxxx]
Sent: September 10, 2021 12:38 PM
To: General discussion list for the 389 Directory server project. <389-users@xxxxxxxxxxxxxxxxxxxxxxx>; Ghiurea, Isabella <Isabella.Ghiurea@xxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxxxxxx

To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx

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@xxxxxxxxxxxxxxxxxxxxxxx

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@xxxxxxxxxxxxxxxxxxxxxxx

To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx

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@xxxxxxxxxxxxxxxxxxxxxxx

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@xxxxxxxxxxxxxxxxxxxxxxx

To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx

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@xxxxxxxxxxxxxxxxxxxxxxx

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

_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure