Re: global passwd policy for DS with existing users
by Thierry Bordaz
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@redhat.com]
> *Sent:* September 14, 2021 7:13 AM
> *To:* General discussion list for the 389 Directory server project.
> <389-users(a)lists.fedoraproject.org>; Mark Reynolds
> <mreynolds(a)redhat.com>; Ghiurea, Isabella
> <Isabella.Ghiurea(a)nrc-cnrc.gc.ca>
> *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
> <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...
> <https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...>
>
> 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@redhat.com
> <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>
> <mailto:389-users@lists.fedoraproject.org>; Ghiurea, Isabella
> <Isabella.Ghiurea(a)nrc-cnrc.gc.ca>
> <mailto: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...
> <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 <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 <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>
>
2 years, 6 months
global passwd policy for DS with existing users
by Ghiurea, Isabella
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 ?
Isabella
2 years, 6 months
Additional IP-Address
by Bernd Nachtigall
Hi,
during my first steps with 389DS I wonder how I can configure a
dedicated IP-Address for the different instances.
Are there some hints?
Bernd
2 years, 6 months
Two Factor Authentication
by Xinhuan Zheng
Does 389 directory server support Two Factor Authentication? Can it be integrated with Google Authenticator?
- Xinhuan
2 years, 6 months
user password policy
by Ghiurea, Isabella
Hi
I need to cfg user passwd policy and trying to understand what's the most robust solution ?
I am reading the documentation and see there are different levels- to implement passwd policy: global ldap cfg password policy AND/OR only user level passwd policy?
Thank you
Isabella
2 years, 6 months
Re: nsslapd-conntablesize & nsslapd-maxfiledescriptors
by William Brown
> On 3 Sep 2021, at 23:37, Michael Starling <mlstarling31(a)hotmail.com> wrote:
>
> Given the current settings on a directory server I'm still seeing the errors below in the logs at peak times.
>
> "ERR - setup_pr_read_pds - Not listening for new connections - too many fds open"
>
>
> nsslapd-reservedescriptors: 64
> nsslapd-maxdescriptors: 65535
> nsslapd-conntablesize: 8192
>
> At the OS level the ns-slapd process is set to 65535 as well.
>
> Max open files 65535
>
>
> After reading the RHDS documentation it's a bit unclear as to how these parameters work together.
>
> The conntablesize documentation states:
>
> "The default value for nsslapd-conntablesize is the systems maxdescriptors which can be confiured using nsslapd-maxdescriptors"
>
>
> Now we look at the documentation for maxdescriptors:
>
>
> The number of descriptors available for TCP/IP to serve client connections is determined by nsslapd-conntablesize, and is equal to the nsslapd-maxdescriptors attribute minus the number of file descriptors used by the server as specified in the nsslapd-reservedescriptors attribute for non-client connections, such as index management and managing replication. The nsslapd-reservedescriptors attribute is the number of file descriptors available for other uses as described above.
>
> Based on the numbers currently set does this mean no action needs to be taken as this implies maxdescriptors takes precedence over conntablesize?
>
> Or should I set conntablesize to 65535-64 = 65471?
Perhaps there is a bug here if conntablesize is still set. Alternately, it could have been set manually and the config upgrade code never kicked in.
It's probably best to increase this a bit carefully, adjust up conntablesize in increments of 8192 until you stop having connection issues?
Hope that helps,
>
>
>
>
> 3.1.1.60. nsslapd-conntablesize
>
> This attribute sets the connection table size, which determines the total number of connections supported by the server.
> The server has to be restarted for changes to this attribute to go into effect.
> Parameter Description
> Entry DN cn=config
> Valid Values Operating-system dependent
> Default Value The default value is the system's max descriptors, which can be configured using the nsslapd-maxdescriptors attribute as described in Section 3.1.1.115, “nsslapd-maxdescriptors (Maximum File Descriptors)”
> Syntax Integer
> Example nsslapd-conntablesize: 4093
> Increase the value of this attribute if Directory Server is refusing connections because it is out of connection slots. When this occurs, the Directory Server's error log file records the message Not listening for new connections -- too many fds open.
> A server restart is required for the change to take effect.
>
>
> Thanks
> _______________________________________________
> 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
--
Sincerely,
William Brown
Senior Software Engineer, Identity and Access Management
SUSE Labs, Australia
2 years, 6 months
Enabling retro changelog maxage with 3 million entries make dirsrv not respond anymore
by Kees Bakker
Hi,
First a bit of context.
CentOS 7, FreeIPA
389-ds-base-snmp-1.3.9.1-13.el7_7.x86_64
389-ds-base-libs-1.3.9.1-13.el7_7.x86_64
389-ds-base-1.3.9.1-13.el7_7.x86_64
A long time ago I was experiencing a deadlock during retro changelog cleanup
and I was advised to disable it as a workaround. Disabling was done by setting
nsslapd-changelogmaxage to -1. SInce then the number of entries grew to
about 3 million.
Last week I enabled maxage again. I set it to 470 days. I was hoping to limit
this pile of old changelog entries., starting by cleaning very old entries.
However, what I noticed is that it was removing entries with a pace of 16 entries
per second. Meanwhile the server was doing nothing. Server load was very low.
The real problem is that dirsrv (LDAP) is not responding to any requests anymore. I
had to disable maxage again, which requires patience restarting the server when
it is not responding ;-)
Now my questions
1) is it normal dat removing repo changelog entries is slooow?
2) why is dirsrv not responding anymore when the cleanup kicks in?
3) are there alternatives to cleanup the old repo changelog entries?
--
Kees
2 years, 6 months
Re: update_pw_encoding messages
by Mark Reynolds
On 9/3/21 9:43 AM, Michael Starling wrote:
> I see these errors in my logs for some accounts on my consumers with
> chaining enabled.
>
> - WARN - update_pw_encoding - Could not read password attribute on
> 'uid=someuser,ou=people,dc=domain,dc=lott'
This means the user does not have a userpassword attribute in its
entry. Can you confirm, on the consumer, if that entry has this attribute?
>
>
>
> Are these spurious messages or something that needs to be addressed?
>
> I came across this:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1833266
> <https://bugzilla.redhat.com/show_bug.cgi?id=1833266>
>
> upgrade-hash is set to "on" on all servers.
>
> What is this code doing?
It's checking if you are using an outdated password storage scheme, and
if it is then it re-encodes the password in a more secure algorithm.
Mark
>
> int32_t update_pw_encoding(Slapi_PBlock *orig_pb, Slapi_Entry *e,
> Slapi_DN *sdn, char *cleartextpassword) {
> char *dn = (char *)slapi_sdn_get_ndn(sdn);
> Slapi_Attr *pw = NULL;
> Slapi_Value **password_values = NULL;
> passwdPolicy *pwpolicy = NULL;
> struct pw_scheme *curpwsp = NULL;
> Slapi_Mods smods;
> char *hashed_val = NULL;
> Slapi_PBlock *pb = NULL;
> int32_t res = 0;
> slapi_mods_init(&smods, 0);
> /*
> * Does the entry have a pw?
> */
> if (e == NULL || slapi_entry_attr_find(e, SLAPI_USERPWD_ATTR,
> &pw) != 0 || pw == NULL) {
> slapi_log_err(SLAPI_LOG_WARNING,
> * "update_pw_encoding", "Could not read
> password attribute on '%s'\n",*
> dn);
> res = -1;
> goto free_and_return;
> }
>
> Mike
>
> _______________________________________________
> 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
2 years, 6 months
update_pw_encoding messages
by Michael Starling
I see these errors in my logs for some accounts on my consumers with chaining enabled.
- WARN - update_pw_encoding - Could not read password attribute on 'uid=someuser,ou=people,dc=domain,dc=lott'
Are these spurious messages or something that needs to be addressed?
I came across this:
https://bugzilla.redhat.com/show_bug.cgi?id=1833266
upgrade-hash is set to "on" on all servers.
What is this code doing?
int32_t update_pw_encoding(Slapi_PBlock *orig_pb, Slapi_Entry *e, Slapi_DN *sdn, char *cleartextpassword) {
char *dn = (char *)slapi_sdn_get_ndn(sdn);
Slapi_Attr *pw = NULL;
Slapi_Value **password_values = NULL;
passwdPolicy *pwpolicy = NULL;
struct pw_scheme *curpwsp = NULL;
Slapi_Mods smods;
char *hashed_val = NULL;
Slapi_PBlock *pb = NULL;
int32_t res = 0;
slapi_mods_init(&smods, 0);
/*
* Does the entry have a pw?
*/
if (e == NULL || slapi_entry_attr_find(e, SLAPI_USERPWD_ATTR, &pw) != 0 || pw == NULL) {
slapi_log_err(SLAPI_LOG_WARNING,
"update_pw_encoding", "Could not read password attribute on '%s'\n",
dn);
res = -1;
goto free_and_return;
}
Mike
2 years, 6 months
nsslapd-conntablesize & nsslapd-maxfiledescriptors
by Michael Starling
Given the current settings on a directory server I'm still seeing the errors below in the logs at peak times.
"ERR - setup_pr_read_pds - Not listening for new connections - too many fds open"
nsslapd-reservedescriptors: 64
nsslapd-maxdescriptors: 65535
nsslapd-conntablesize: 8192
At the OS level the ns-slapd process is set to 65535 as well.
Max open files 65535
After reading the RHDS documentation it's a bit unclear as to how these parameters work together.
The conntablesize documentation states:
"The default value for nsslapd-conntablesize is the systems maxdescriptors which can be confiured using nsslapd-maxdescriptors"
Now we look at the documentation for maxdescriptors:
The number of descriptors available for TCP/IP to serve client connections is determined by nsslapd-conntablesize, and is equal to the nsslapd-maxdescriptors attribute minus the number of file descriptors used by the server as specified in the nsslapd-reservedescriptors attribute for non-client connections, such as index management and managing replication. The nsslapd-reservedescriptors attribute is the number of file descriptors available for other uses as described above.
Based on the numbers currently set does this mean no action needs to be taken as this implies maxdescriptors takes precedence over conntablesize?
Or should I set conntablesize to 65535-64 = 65471?
3.1.1.60. nsslapd-conntablesize
This attribute sets the connection table size, which determines the total number of connections supported by the server.
The server has to be restarted for changes to this attribute to go into effect.
Parameter Description
Entry DN cn=config
Valid Values Operating-system dependent
Default Value The default value is the system's max descriptors, which can be configured using the nsslapd-maxdescriptors attribute as described in Section 3.1.1.115, “nsslapd-maxdescriptors (Maximum File Descriptors)”<https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...>
Syntax Integer
Example nsslapd-conntablesize: 4093
Increase the value of this attribute if Directory Server is refusing connections because it is out of connection slots. When this occurs, the Directory Server's error log file records the message Not listening for new connections -- too many fds open.
A server restart is required for the change to take effect.
Thanks
2 years, 6 months