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
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
Two Factor Authentication
by Xinhuan Zheng
Does 389 directory server support Two Factor Authentication? Can it be integrated with Google Authenticator?
- Xinhuan
2 years
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
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
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
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
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
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
Re: Database and OS tuning. (open files)
by Paul Robert Marino
actually thats 5 minutes for the first probe then 75 seconds on
subsequent failed probes up to 9 failures so it's actually 900 seconds
i usually set it to
time = 120
intv = 30
probes = 4
keep in mind this just gets rid of Zombie connections. if the first
probe after 300 seconds of the connection being idle is successful it
waits another 300 seconds this is network bandwidth equivalent to 1
ping per probe. this bandwidth is very small keep in mind every
instance of Windows 10 on your network uses far more bandwidth to
verify they have internet access.
On Wed, Sep 1, 2021 at 11:05 PM Michael Starling
<mlstarling31(a)hotmail.com> wrote:
>
>
>
> ________________________________
> From: William Brown <william.brown(a)suse.com>
> Sent: Wednesday, September 1, 2021 7:20 PM
> To: 389-users(a)lists.fedoraproject.org <389-users(a)lists.fedoraproject.org>
> Subject: [389-users] Re: Database and OS tuning. (open files)
>
>
>
> > On 2 Sep 2021, at 00:50, Michael Starling <mlstarling31(a)hotmail.com> wrote:
> >
> > Thank you, Paul.
> >
> > This is our current setting. Looks like we are at 5 minutes so we should be ok.
> >
> > net.ipv4.tcp_keepalive_intvl = 75
> > net.ipv4.tcp_keepalive_probes = 9
> > net.ipv4.tcp_keepalive_time = 300
>
> There are also a number of IO tuning options for connection life inside LDAP you can tune to help discard and cycle out stale connections quicker.
>
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/11...
>
> If we receive a partial message, how long to wait for the remaining components to be recieved.
>
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/11...
>
> If a client is idle with no messages being received, how long before we disconnect them.
>
> https://access.redhat.com/documentation/en-us/red_hat_directory_server/11...
>
> Maximum number of connections. IIRC this might be automatically set from FD's in the system, but if not you may need to set this to probably 80% of your FD limit frlom the systemd service tunings you have provided.
>
> Hope that helps,
>
> --
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, Identity and Access Management
> SUSE Labs, Australia
> _______________________________________________
> 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
>
>
> Thanks William.
>
> I've made some changes tonight. Let's see if it helps.
>
> 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
2 years
