We have a long standing 389ds master LDAP server that was found to be unable to contact it’s slaves. Most specifically, the slaves show nothing in their logs about any kind of connection, while the master is logging this:
[12/Nov/2019:21:39:47.212715697 +0000] - ERR - slapi_ldap_bind - Could not send bind request for id [(anon)] authentication mechanism [EXTERNAL]: error -1 (Can't contact LDAP server), system error 0 (no error), network error 0 (Unknown error, host “ldap01:636”)
Key is "system error 0 (no error)”, which leaves us stumped. The error is obviously “success”.
Has anyone seen this kind of thing before?
This is 389ds running on CentOS7 as follows:
We use the 389 Directory Server version 184.108.40.206.
In the documentation of the Red Hat Directory Server it says, as many as 20 masters are supported in an MMR. It sounds to be a hardcoded limitation defined to avoid overloaded servers and network. Shouldn't it be depending on the MMR topology, i.e. rather on the total number of replication agreements within the whole scenario? Or does "20 masters" indeed mean that the limitation of the MMR topology is the number of 380 replication agreements as shown in the "fully connected mesh" scenario (https://access.redhat.com/documentation/en-us/red_hat_directory_server/10...) with 20 masters and 20x19 replication agreements?
Is there someone who possibly has experience with scenarios of more than 20 master servers?
I am just now looking into our 389-ds migration strategy from CentOS 7 to 8. I successfully created my first master 389 instance on 8. It took some getting used to doing it on the cockpit plugin. But what I am missing is how do I merge a view where I can manage all of my DS from one view? I recall you saying the there will no longer be a java console, is there an alternative solution, such as an application, that will allow me to view all of my systems in a console (that is deprecated)?
Paul M. Whitney
Sent from my Mac Book Pro
We have the following scenario:
We use a "global" password policy at cn=config where a customer of ours defines:
We provide as default configuration "passwordMustChage: on" to force a new user to chage the initial password. In this setup a user whose password expired, i.e. also after this user is created and needs to change its initial password, cannot login to the account, but he can change the password.
The customer now wants a setup which prevents a user whose password expired from changing the password. A plugin "Account Policy Plugin" can therefore be activated by the customer, which uses the following configuration:
dn: cn=config,cn=Account Policy Plugin,cn=plugins,cn=config
As a consequence, the initial password change does not work anymore, thus the customer must change to "passwordMustChange: off". This would probably be acceptable.
A problem is, however, that a user account which has its own user password policy with "passwordexp: off" and "passwordmustchange: off" is affected by the plugin in such a way that the attribute passwordExpirationTime of the user itself is evaluated and the attribute passwordexp of the user password policy is ignored. That means, a user password policy for special user accounts without password expiration cannot be used in combination with the Account Policy Plugin.
Can the plugin be configured to enable this possiblity or is there another way to achieve the desired behaviour?
Is it possible to restrict some users to read,search,compare just specific
attributes but still use objectclass=* as a filter?
aci: (targetattr="uid || givenName || cn || sn || manager ||
mail")(targetfilter="(objectclass=*)")(version 3.0;aci "Access for app to
specific needed attributes";allow (read,compare,search)
If I do a ldapsearch with this user (myuser is in the group my-group):
ldapsearch -b "dc=rnp,dc=local" -W -D "uid=myuser" uid=alberto.viana
Returns me the user alberto.viana and the attributes that acis allows
but if I do:
ldapsearch -b "dc=rnp,dc=local" -W -D "uid=myuser" objectclass=*
returns me nothing.
I'm looking at the RH documentation for passwordMaxSeqSets, found here:
Their wording seems a little unclear, to me. The paragraph, before the
example states: "If you set the passwordMaxSeqSets parameter to a
value higher than 0, Directory Server rejects passwords with duplicate
monotonic sequences exceeding the length set in the parameter."
But, in their example, they list a password with two sequences of "XYZ".
And they say that setting the value to 2 would prevent that password.
But according to the paragraph before the example, shouldn't it be set
I have passwordMaxSequence set to 3. Can somebody clarify how
passwordMaxSeqSets should be set to prevent any duplicate sequences?
I recently upgraded my system from RHEL7 to RHEL8, together with 389ds.
Apparently this has caused to upgrade the storage scheme of the user
passwords to PBKDF2_SHA256. Everything works fine except freeradius does
not support this storage scheme at the moment.
How can I downgrade the storage scheme in 389ds to something that is
supported by freeradius in such a way, that doesn't force my users to
change their passwords?
I have one historical plug-in (from times of SunOne Directory), it was
in past ported for 1.2 version of 389 DS. But it fails to work with 1.4.
It is a bit more complicated than the one I was seeking help before, but
maybe it is possible to replace it with some standard plug-in. However,
I didn't find any suitable. :(
We are using attribute named entryStatus with several possible values
like prepared, active, marked, dead - those are used for keeping status
of user entry.
I need to keep track when and by whom was entryStatus attribute
modified. For those informations, we have two attributes
entryStatusTimestamp and entryStatusModifier attributes. And every time
entryStatus is changed, our plugin changes automatically those two
Is there any standard, or maybe some contributed plugin how I can
Jan Tomasek aka Semik