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.
·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...
· 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(a)lists.fedoraproject.org>; Ghiurea, Isabella
<Isabella.Ghiurea(a)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...
<
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...
HTH,
Mark
_______________________________________________
389-users mailing list --389-users(a)lists.fedoraproject.org
<mailto:389-users@lists.fedoraproject.org>
To unsubscribe send an email to389-users-leave(a)lists.fedoraproject.org
<mailto:389-users-leave@lists.fedoraproject.org>
Fedora Code of
Conduct:https://docs.fedoraproject.org/en-US/project/code-of-conduct/
<
https://docs.fedoraproject.org/en-US/project/code-of-conduct/>
List
Guidelines:https://fedoraproject.org/wiki/Mailing_list_guidelines
<
https://fedoraproject.org/wiki/Mailing_list_guidelines>
List
Archives:https://lists.fedoraproject.org/archives/list/389-users@lists.fe...
<
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproje...
Do not reply to spam on the list, report it:https://pagure.io/fedora-infrastructure
<
https://pagure.io/fedora-infrastructure>
--
Directory Server Development Team
_______________________________________________
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://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.fedoraproje...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Directory Server Development Team