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
> ·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 to389-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.fe...
> 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(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