I'm trying to setup a replication with a certificate based authentication between supplier and consumer. The certificates in the certdb at /etc/dirsrv/slapd-XXX contain the very same CA with which the respective server certificates in the certdbs have been signed. The certificates all have the 'u' flag, and the CA has the C and T flag.
The replication (on the supplier) has been setup such that TLS and certificate based authentication is used, see extract from the replication agreement object:
Trying to initialize the consumer raises this error in the error-log of the supplier (the host sending the starttls connection request):
Replication bind with EXTERNAL auth failed: LDAP error 48 (Inappropriate authentication) (missing client certificate)
The certificate that the server should have sent can, however, be used with the ldap commandline tools as ldapsearch. In this case a wireshark trace clearly shows that the client sends the certificate during the TLS handshake, while in the above case it doesn't.
The TLS handshake defines that the client has to send an "empty certificate" if it does not have a certificate that has been issued by a CA offered by the server during the handshake. I can't see a reason for the client to think the condition isn't met. The certificate with which the server (supplier) is setup is the only one available.
Is it possible that the server does not know which certificate it has to use for authentication with the consumer server? And if so, how do I make the server know?
The 389-ds in use is the version 126.96.36.199~git0.5ac5a8aad. The problem was the same with 188.8.131.52.
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?