Replication with SSLCLIENTAUTH: server sent no certificate
by Eugen Lamers
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:
objectclass: nsds5ReplicationAgreement
nsds5replicahost: <consumer-hostname>
nsds5replicaport: 389
nsds5replicatransportinfo: TLS
nsds5replicabindmethod: SSLCLIENTAUTH
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 1.4.1.6~git0.5ac5a8aad. The problem was the same with 1.4.0.3.
Thanks,
Eugen
2 years, 8 months
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
by Graham Leggett
Hi all,
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:
389-ds-base-1.3.9.1-10.el7.x86_64
Regards,
Graham
—
2 years, 10 months
Announcing 389 Directory Server 1.4.4.6
by Mark Reynolds
389 Directory Server 1.4.4.6
The 389 Directory Server team is proud to announce 389-ds-base version
1.4.4.6
Fedora packages are available on Fedora 33 and Rawhide (Fedora 34).
Fedora 33:
https://koji.fedoraproject.org/koji/taskinfo?taskID=54270607
<https://koji.fedoraproject.org/koji/taskinfo?taskID=54270607> - Koji
https://bodhi.fedoraproject.org/updates/FEDORA-2020-a998e68006
<https://bodhi.fedoraproject.org/updates/FEDORA-2020-a998e68006> - Bohdi
Rawhide:
https://koji.fedoraproject.org/koji/taskinfo?taskID=46829414
<https://koji.fedoraproject.org/koji/taskinfo?taskID=46829414>
The new packages and versions are:
* 389-ds-base-1.4.4.6-1
Source tarballs are available for download at Download
389-ds-base Source
<https://releases.pagure.org/389-ds-base/389-ds-base-1.4.4.6.tar.bz2>
Highlights in 1.4.4.6
* Bug fixes
Installation and Upgrade
See Download <https://www.port389.org/docs/389ds/download.html> for
information about setting up your yum repositories.
To install the server use *dnf install 389-ds-base*
To install the Cockpit UI plugin use *dnf install cockpit-389-ds*
After rpm install completes, run *dscreate interactive*
For upgrades, simply install the package. There are no further
steps required.
There are no upgrade steps besides installing the new rpms
See Install_Guide
<https://www.port389.org/docs/389ds/howto/howto-install-389.html> for
more information about the initial installation and setup
See Source <https://www.port389.org/docs/389ds/development/source.html>
for information about source tarballs and SCM (git) access.
Feedback
We are very interested in your feedback!
Please provide feedback and comments to the 389-users mailing list:
https://lists.fedoraproject.org/admin/lists/389-users.lists.fedoraproject...
If you find a bug, or would like to see a new feature, file it in our
GitHub project: https://github.com/389ds/389-ds-base
* Bump version to 1.4.4.6
* Issue 4262 - Remove legacy tools subpackage (final cleanup)
* Issue 4262 - Remove legacy tools subpackage (restart instances after
rpm install)
* Issue 4262 - Remove legacy tools subpackage
* Issue 2526 - revert API change in slapi_be_getsuffix()
* Issue 4363 - Sync repl: per thread structure was incorrectly
initialized (#4395)
* Issue 4392 - Update create_test.py
* Issue 2820 - Fix CI tests (#4365)
* Issue 2526 - suffix management in backends incorrect
* Issue 4389 - errors log with incorrectly formatted
message parent_update_on_childchange
* Issue 4295 - Fix a closing quote issue (#4386)
* Issue 1199 - Misleading message in access log for idle timeout (#4385)
* Issue 3600 - RFE - openldap migration tooling (#4318)
* Issue 4176 - import ldif2cl task should not close all changelogs
* Issue 4159 - Healthcheck code DSBLE0002 not returned on disabled suffix
* Issue 4379 - allow more than 1 empty AttributeDescription for
ldapsearch, without the risk of denial of service (#4380)
* Issue 4329 - Sync repl - if a serie of updates target the same entry
then the cookie get wrong changenumber (#4356)
* Issue 3555 - Fix npm audit issues (#4370)
* Issue 4372 - BUG - Chaining DB did not validate bind mech
parameters (#4374)
* Issue 4334 - RFE - Task timeout may cause larger dataset imports to
fail (#4359)
* Issue 4361 - RFE - add - dscreate –advanced flag to avoid user confusion
* Issue 4368 - ds-replcheck crashes when processing glue entries
* Issue 4366 - lib389 - Fix account status inactivity checks
* Issue 4265 - UI - Make the secondary plugins read-only (#4364)
* Issue 4360 - password policy max sequence sets is not working
as expected
* Issue 4348 - Add tests for dsidm
* Issue 4350 - One line, fix invalid type error in tls_cacertdir
check (#4358)
--
389 Directory Server Development Team
2 years, 11 months
Max number of users in a group?
by murmansk@hotmail.com
We have a two machine 389DS multimaster cluster holding about 850.000 users. It's been working great for over three years now.
But we are creating some big groups, that will have about 150.000 users in them.
I've read in the list some posts about groups larger than that.
But I would like to know if there is any limit or precaution when working with groups this size?
2 years, 11 months
Limits for Multi Master Replication?
by Eugen Lamers
Hi,
We use the 389 Directory Server version 1.4.2.15.
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?
Thanks,
Eugen
2 years, 11 months
Fwd: 389-AD on CentOS 8
by Mark Reynolds
Forwarding to the correct list...
First it is NOT 389 Actrive Directory Server. Active Directory is
Microsoft's LDAP server...
Going back to your question, there is no 389-admin package on CentOS 8
anymore. There is a new Web UI that is a Cockpit plugin
(cockpit-389-ds). For more info see the admin guide:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/11/
Regards,
Mark
-------- Forwarded Message --------
Subject: 389-AD on CentOS 8
Date: Wed, 21 Oct 2020 10:03:09 +0100
From: Frank Allotey <noblyfrank(a)gmail.com>
To: 389-users-owner(a)lists.fedoraproject.org
Hello team,
I wanted to get hands-on experience with the 389 active directory but
then after doing the installation on a server I seem not to find my way
around for an admin console.
After further research on how to get the admin console failed I decided
to revert to CentOS 7 but some of the repositories are not available for
download.
Kindly assist with the necessary support to achieve this.
--
Kind Regards,
Allotey Frank Kpakpo
+233241293585
+233501373619
/DISCLAIMER:
/
/The content of this email is confidential and intended for the
recipient specified in message only. It is strictly forbidden to share
any part of this message with any third party, without a written consent
of the sender. If you received this message by mistake, please reply to
this message and follow with its deletion, so that we can ensure such a
mistake does not occur in the future./
2 years, 11 months
Re: 389-users Digest, Vol 185, Issue 12
by Ghiurea, Isabella
Thank you ! yes there were groups associate to that users,removing them solved the issues
-----Original Message-----
From: 389-users-request(a)lists.fedoraproject.org [mailto:389-users-request@lists.fedoraproject.org]
Sent: Wednesday, October 14, 2020 9:02 PM
To: 389-users(a)lists.fedoraproject.org
Subject: 389-users Digest, Vol 185, Issue 12
Send 389-users mailing list submissions to
389-users(a)lists.fedoraproject.org
To subscribe or unsubscribe via email, send a message with subject or
body 'help' to
389-users-request(a)lists.fedoraproject.org
You can reach the person managing the list at
389-users-owner(a)lists.fedoraproject.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of 389-users digest..."
Today's Topics:
1. Re: ldapdelete error (Mark Reynolds)
----------------------------------------------------------------------
Date: Wed, 14 Oct 2020 08:03:00 -0400
From: Mark Reynolds <mreynolds(a)redhat.com>
Subject: [389-users] Re: ldapdelete error
To: "General discussion list for the 389 Directory server project."
<389-users(a)lists.fedoraproject.org>, William Brown <wbrown(a)suse.de>
Message-ID: <9fdfe761-9cb3-e0c5-72d1-2ead5a282141(a)redhat.com>
Content-Type: text/plain; charset=utf-8; format=flowed
ldapdelete has a "-r" option to recursiviely delete. So that would
solve your problem, but you better make sure you know what is under that
user entry before blindly removing it and its child entries :-)
On 10/13/20 10:23 PM, William Brown wrote:
> Generally this means there is content still under the ou=Users. You can't do a subtree delete in LDAP, so that's probably the error here. Can you check what's under the OU?
>
>> On 14 Oct 2020, at 10:32, Ghiurea, Isabella <Isabella.Ghiurea(a)nrc-cnrc.gc.ca> wrote:
>>
>> Hi List
>> I’m looking for a solution for the following ldapdelete error in a multimaster replication cfg with memberof pluging enabled locally on each server and excluded from replication agreement :
>> ldapdelete -D "cn=directory manager" -W -x "ou=Users,ou=ds,dcxxxxx " "(uid=9995)"
>> Enter LDAP Password:
>> ldap_delete: Operation not allowed on non-leaf (66)
>>
>> My DS version is : 389-ds-base-1.3.7.5-24.el7_5.x86_64
>>
>> Running a basic search for this error seems this was a known bug in older version 7 years ago which I assume is been fixed.
>> Thank you
>> Isabella
>> _______________________________________________
>> 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...
> —
> Sincerely,
>
> William Brown
>
> Senior Software Engineer, 389 Directory Server
> 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...
--
389 Directory Server Development Team
------------------------------
Subject: Digest Footer
_______________________________________________
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...
------------------------------
End of 389-users Digest, Vol 185, Issue 12
******************************************
2 years, 11 months
ldapdelete error
by Ghiurea, Isabella
Hi List
I'm looking for a solution for the following ldapdelete error in a multimaster replication cfg with memberof pluging enabled locally on each server and excluded from replication agreement :
ldapdelete -D "cn=directory manager" -W -x "ou=Users,ou=ds,dcxxxxx " "(uid=9995)"
Enter LDAP Password:
ldap_delete: Operation not allowed on non-leaf (66)
My DS version is : 389-ds-base-1.3.7.5-24.el7_5.x86_64
Running a basic search for this error seems this was a known bug in older version 7 years ago which I assume is been fixed.
Thank you
Isabella
2 years, 11 months