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 18.104.22.168~git0.5ac5a8aad. The problem was the same with 22.214.171.124.
I'm new in this list, thank you for developing 389ds!
I would like some hints about lib389.
dscreate allows to set some parameters only when you create an instance.
So it' very difficult to maintain all configuration parameters among db and instances and replicated instances.
I'm writing my tool to manage all configuration parameters in one place (a yaml file). Just a wrapper for dsconf. See at
I would like to call dsconf from an external host only, different from hosts where the 389ds run. So I have installed the python3-lib389 rpm in that different host.
Let suppose I have
where 389ds Directory Server run after dscreate process.
I have another host:
where I have installed lib389 rpm only, and from that remote host I configure the tst*.example.com servers through dsconf.
The problem is that dsconf exit with the error "defaults.inf not found in any well known location!".
So I have taken the defaults.inf from a 389ds host (one of tst*.example.com) and I have placed it in the new path /usr/share/dirsrv/inf of manage.example.com.
Now dsconf works fine.
I would like to know if there are some reason to avoid to do that. Or, if simply the python3-lib389 forgot to install the defaults.inf in the proper path.
Thank you very much
I'm testing my install recipes on debian and I've found two little problems.
on CentOS I execute
dsconf myinstance plugin retro-changelog enable
but today I tried in debian and it says is an invalid choice:
dsconf instance plugin: error: invalid choice: 'retro-changelog' (choose from 'memberof', 'automember', 'referint', 'rootdn', 'usn', 'accountpolicy', 'attruniq', 'dna', 'linkedattr', 'managedentries', 'passthroughauth', 'retrochangelog', 'whoami', 'list', 'get', 'edit')
So retro-changelog is called now retrochangelog.
Is that a Debian thing or it changed it's name on a recent version?
In addition I executed the command with the new name and it gives me a message without a correct variable.
dsconf myinstance plugin retrochangelog enable
Enabled plugin '%s' Retro Changelog Plugin
dsconf myinstance plugin retrochangelog status
Plugin '%s' is enabled Retro Changelog Plugin
it seems a cosmetic error but I just want to be sure if I need to open a bug.
here are the version of the packages:
dpkg -l | grep 389
ii 389-ds-base 126.96.36.199-1 amd64 389 Directory Server suite - server
ii 389-ds-base-legacy-tools 188.8.131.52-1 amd64 Legacy utilities for 389 Directory Server
ii 389-ds-base-libs:amd64 184.108.40.206-1 amd64 389 Directory Server suite - libraries
ii python3-lib389 220.127.116.11-1 all Python3 module for accessing and configuring the 389 Directory Server
thanks in advance,
-- Institut Mallorqui d'Afers Socials. Aquest missatge, i si escau, qualsevol fitxer annex, es dirigeix exclusivament a la persona que n'es destinataria i pot contenir informacio confidencial. En cap cas no heu de copiar aquest missatge ni lliurar-lo a terceres persones sense permis expres de l'IMAS. Si no sou la persona destinataria que s'hi indica (o la responsable de lliurar-l'hi) us demanam que ho notifiqueu immediatament a l'adreca electronica de la persona remitent. Abans d'imprimir aquest missatge, pensau si es realment necessari.
I am trying to have one way windows sync (from windows AD to LDAP) but i
need to exclude some attributes.
Is this possible? I cannot find any documentation on this.
I already try this with 389ds running on CentOS7 and CentOS8 with no
I am using nsDS5ReplicatedAttributeListTotal and
nsDS5ReplicatedAttributeList attributes but i am still getting
replicated values of the excluded attributes.
I found this but i am not sure if this is the case:
Can you please provide guidelines on this?
Anyone try this before?
Andry Michaelidou Papa | IT Systems Administrator|Department of Computer
Science| University of Cyprus
Tel: +357.22.892734 | Fax: +357.22.8927201 |
> On 19 Jan 2021, at 03:40, Gary Windham <windhamg(a)arizona.edu> wrote:
> Thanks for the reply, WIlliam. We are using Internet2's Grouper (which synchronizes group memberships to our 389 DS) to create a "chain" of groups that are being used to implement a COVID-19 testing compliance policy at the University of Arizona. One of these groups contains users who have had a test with a positive result in the last 90 days. Since that is personal health information, we didn't want the "isMemberOf" value containing that group to be visible, except to a particular set of users.
You may find it's safer in this case to sync any PHI to either an isolated or seperate directory, or to use a seperate attribute indicating the test positivity that can have strict access controls placed upon it.
> However, since sending my original email, we found a workaround -- fortunately, the end group in this "chain" is the only one we really need to sync to 389 DS, so we were able to omit the other groups (including the PHI one) from the sync process.
I'm glad you found a solution still,
Hope I was able to help,
> Thanks again,
> Gary Windham
> Principal Enterprise Systems Architect
> University Information Technology Services
> The University of Arizona
> Email: windhamg(a)arizona.edu
> Office: +1 520 626 5981
> On Sun, Jan 17, 2021 at 5:11 PM William Brown <wbrown(a)suse.de> wrote:
> External Email
> > On 16 Jan 2021, at 05:17, Gary Windham <windhamg(a)email.arizona.edu> wrote:
> > Hi all,
> > We're running 389-Directory/18.104.22.168 B2018.304.1940.
> > Is it possible via ACIs to restrict read/search permission on attributes with a particular value?
> > My use case is that we have an "isMemberOf" attribute in our directory, and we have some group memberships that are of a sensitive nature. I would like to have all "isMemberOf" attribute values *except* for these sensitive ones readable/searchable to all authenticated user DNs, and the "sensitive" ones only readable/searchable by a particular user DN.
> > Any ideas? From reading the Red Hat directory server ACI documentation, I can't find a way to do this.
> No, I don't think it's possible. Access controls are based on "which attributes you can/can't see", rather than "you can see these attributes except these values within them".
> I think that in this case, the possible solutions would be to have a isMemberOfSensitive seperate to the isMemberOf, but that may break many other integrations.
> An important question of course, is why are some group memberships sensitive? What is it you are trying to achieve?
> > Thanks in advance,
> > --Gary
> > --
> > Gary Windham
> > Principal Enterprise Systems Architect
> > University Information Technology Services
> > The University of Arizona
> > Email: windhamg(a)arizona.edu
> > Office: +1 520 626 5981
> > _______________________________________________
> > 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://email@example.com...
> William Brown
> Senior Software Engineer, 389 Directory Server
> SUSE Labs, Australia
Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
We're running 389-Directory/22.214.171.124 B2018.304.1940.
Is it possible via ACIs to restrict read/search permission on attributes
with a particular value?
My use case is that we have an "isMemberOf" attribute in our directory, and
we have some group memberships that are of a sensitive nature. I would like
to have all "isMemberOf" attribute values *except* for these sensitive ones
readable/searchable to all authenticated user DNs, and the "sensitive" ones
only readable/searchable by a particular user DN.
Any ideas? From reading the Red Hat directory server ACI documentation, I
can't find a way to do this.
Thanks in advance,
Principal Enterprise Systems Architect
University Information Technology Services
The University of Arizona
Office: +1 520 626 5981
389 Directory Server 126.96.36.199
The 389 Directory Server team is proud to announce 389-ds-base version
Fedora packages are available on Fedora 32.
<https://koji.fedoraproject.org/koji/taskinfo?taskID=59774017> - Fedora 32
<https://bodhi.fedoraproject.org/updates/FEDORA-2021-19b143e4a5> - Bodhi
The new packages and versions are:
Source tarballs are available for download at Download
Highlights in 188.8.131.52
* 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
There are no upgrade steps besides installing the new rpms
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.
New UI Progress (Cockpit plugin)
The new UI is complete and QE tested.
We are very interested in your feedback!
Please provide feedback and comments to the 389-users mailing list:
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 184.108.40.206
* Issue 4513 - CI Tests - fix test failures
* Issue 4528 - Fix cn=monitor SCOPE_ONE search (#4529)
* Issue 4504 - insure that repl_monitor_test use ldapi (for RHEL) -
fix merge issue (#4533)
* Issue 4315 - performance search rate: nagle triggers high rate
* Issue 4504 - Insure ldapi is enabled in repl_monitor_test.py (Needed
on RHEL) (#4527)
* Issue 4506 - BUG - Fix bounds on fd table population (#4520)
* Issue 4521 - DS crash in deref plugin if dereferenced entry exists
but is not returned by internal search (#4525)
* Issue 4418 - lib389 - fix ldif2db import_cl parameter
* Issue 4384 - Separate eventq into REALTIME and MONOTONIC
* Issue 4418 - ldif2db - offline. Warn the user of skipped entries
* Issue 4414 - disk monitoring - prevent division by zero crash
* Issue 4507 - Improve csngen testing task (#4508)
* Issue 4486 - Remove random ldif file generation from import test (#4487)
* Issue 4489 - Remove return statement from a void function (#4490)
* Issue 4419 - Warn users of skipped entries during ldif2db online
* Issue 4418 - ldif2db - offline. Warn the user of skipped entries
* Issue 4504 - Fix pytest test_dsconf_replication_monitor (#4505)
* Issue 4480 - Unexpected info returned to ldap request (#4491)
* Issue 4373 - BUG - one line cleanup, free results in mt if ent 0 (#4502)
* Issue 4500 - Add cockpit enabling to dsctl
* Issue 4272 - RFE - add support for gost-yescrypt for hashing
* Issue 1795 - RFE - Enable logging for libldap and libber in error
* Issue 4492 - Changelog cache can upload updates from a wrong
starting point (CSN)
* Issue 4373 - BUG - calloc of size 0 in MT build (#4496)
* Issue 4483 - heap-use-after-free in slapi_be_getsuffix
* Issue 4315 - performance search rate: nagle triggers high rate of
* Issue 4243 - Fix test (4th): SyncRepl plugin provides a wrong (#4475)
* Issue 4460 - BUG - add machine name to subject alt names in SSCA (#4472)
* Issue 4284 - dsidm fails to delete an organizationalUnit entry
* Issue 4243 - Fix test: SyncRepl plugin provides a wrong cookie (#4466)
389 Directory Server Development Team