389-users January 2024

389-users@lists.fedoraproject.org

12 participants
6 discussions

Re: 389 DS 2.3.6 on RHEL 9 replication over TLS
by Thierry Bordaz 26 Jan '24

26 Jan '24

You may follow the doc to configure TLS on your both suppliers [1] and check the trusted CA on both side [2]. On troubleshooting side you may look at [3] [1] https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/h… [2] https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/h… [3] https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/h… On 1/25/24 23:55, Ciara Gadsden wrote: > Idk how to do that lol > > Sent from my Boost Samsung Galaxy A23 5G > Get Outlook for Android <https://aka.ms/AAb9ysg> > ------------------------------------------------------------------------ > *From:* Simon Pichugin <spichugi(a)redhat.com> > *Sent:* Thursday, January 25, 2024 5:44:57 PM > *To:* General discussion list for the 389 Directory server project. > <389-users(a)lists.fedoraproject.org> > *Cc:* alexander_nazarenko(a)harvard.edu <alexander_nazarenko(a)harvard.edu> > *Subject:* [389-users] Re: 389 DS 2.3.6 on RHEL 9 replication over TLS > Hello Alex, > I think we need a bit more information here. > > First of all, could you please run the "dsconf repl-agmt create" > (LDAPS one) with "-v" flag? It will give a detailed verbose output. > Also, I recommend checking the server's error and access log for more > information why it fails (additionally, you may enable at least > 16384+8192 (Default + Replication debugging) in nsslapd-errorlog-level). > > As for possible issues and actions, at first glance, I recommend > checking that the TLS certificates used are correctly installed and > trusted on both the supplier and consumer instances. It's important > that the instances trust each other; even though ldapsearch (OpenLDAP > client) on the supplier already trusts the consumer machine, it's not > enough. > > Sincerely, > Simon > > > > On Thu, Jan 25, 2024 at 1:07 PM Nazarenko, Alexander > <alexander_nazarenko(a)harvard.edu> wrote: > > Hello colleagues, > > Lately we started looking into 389 DS 2.3.6 on RHEL 9 platform. > > We followed instructions Configuring and managing replication > <https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/h…> > on Red Hat site to establish replication between two remote instances, > > The instances where previously configured to support TLS channel > on port 636 (Enabling TLS-encrypted connections to Directory > Server > <https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/h…>), > and we made sure ldapsearch is working with LDAPS:// protocol with > the certificate verification (TLS_REQCERT demand). > > The following issue with the replication over TLS was observed: > > After we ran the command below to configure secure replication: > > dsconf -D "cn=Directory Manager" -w *** > ldaps://server.example.edu <http://server.example.edu> repl-agmt > create --suffix "dc=example,dc=com" --host "consumer.example.edu > <http://consumer.example.edu>" --port 636 --conn-protocol=LDAPS > --bind-dn "cn=replication manager,cn=config" --bind-passwd "***" > --bind-method=SIMPLE --init consumer.example.edu-RO > > the error occurred: > > Error (-1) Problem connecting to replica - LDAP error: Can't > contact LDAP server (connection error) > > We double-checked that after we configure clear text replication > with the command: > > dsconf -D "cn=Directory Manager" -w *** > ldaps://server.example.edu <http://server.example.edu> repl-agmt > create --suffix "dc=example,dc=com" --host "consumer.example.edu > <http://consumer.example.edu>" --port 389 --conn-protocol=LDAP > --bind-dn "cn=replication manager,cn=config" --bind-passwd "***" > --bind-method=SIMPLE --init 10.140.133.36-RO > > no problem occurred, and the replication completed successfully. > > My question is whether this means the replication over TLS > required different config steps, and if yes – what they are? > > Thank you, > > - Alex > > -- > _______________________________________________ > 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.fedoraproject… > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > > > -- > _______________________________________________ > 389-users mailing list --389-users(a)lists.fedoraproject.org > To unsubscribe send an email to389-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.fedo… > Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue

2 1

389 DS 2.3.6 on RHEL 9 replication over TLS
by Nazarenko, Alexander 25 Jan '24

25 Jan '24

Hello colleagues, Lately we started looking into 389 DS 2.3.6 on RHEL 9 platform. We followed instructions Configuring and managing replication<https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/h…> on Red Hat site to establish replication between two remote instances, The instances where previously configured to support TLS channel on port 636 (Enabling TLS-encrypted connections to Directory Server<https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/h…>) , and we made sure ldapsearch is working with LDAPS:// protocol with the certificate verification (TLS_REQCERT demand). The following issue with the replication over TLS was observed: After we ran the command below to configure secure replication: dsconf -D "cn=Directory Manager" -w *** ldaps://server.example.edu repl-agmt create --suffix "dc=example,dc=com" --host "consumer.example.edu" --port 636 --conn-protocol=LDAPS --bind-dn "cn=replication manager,cn=config" --bind-passwd "***" --bind-method=SIMPLE --init consumer.example.edu-RO the error occurred: Error (-1) Problem connecting to replica - LDAP error: Can't contact LDAP server (connection error) We double-checked that after we configure clear text replication with the command: dsconf -D "cn=Directory Manager" -w *** ldaps://server.example.edu repl-agmt create --suffix "dc=example,dc=com" --host "consumer.example.edu" --port 389 --conn-protocol=LDAP --bind-dn "cn=replication manager,cn=config" --bind-passwd "***" --bind-method=SIMPLE --init 10.140.133.36-RO no problem occurred, and the replication completed successfully. My question is whether this means the replication over TLS required different config steps, and if yes – what they are? Thank you, - Alex

3 2

389ds connection not successful
by Jaehwan Kim 21 Jan '24

21 Jan '24

Hello. I use FreeIPA and encountered a 389ds connection problem when new hosts was added to FreeIPA server with the rate of 14 hosts per min. I don't know how many times FreeIPA server actually accesses LDAP in this scenario. Can you give us advice to resolve my problem, with regard to following logs? I'd like to find out configuration to fix this error. ========= access log [18/Jan/2024:23:34:13.087718471 +0000] conn=788 fd=258 slot=258 connection from 52.78.30.18 to 34.84.136.11 [18/Jan/2024:23:34:13.088018506 +0000] conn=788 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="start_tls_plugin" [18/Jan/2024:23:34:13.088053934 +0000] conn=788 op=0 RESULT err=0 tag=120 nentries=0 wtime=0.000228592 optime=0.000040018 etime=0.000268106 [18/Jan/2024:23:34:13.158931686 +0000] conn=788 TLS1.3 128-bit AES-GCM [18/Jan/2024:23:34:13.159223459 +0000] conn=788 op=-1 fd=258 Disconnect - Bad Ber Tag or uncleanly closed connection - B1 security log { "date": "[18\/Jan\/2024:23:34:13.159227408 +0000] ", "utc_time": "1705620853.159227408", "event": "TCP_ERROR", "client_ip": "52.78.30.18", "server_ip": "34.84.136.11", "ldap_version": 3, "conn_id": 788, "msg": "Bad Ber Tag or uncleanly closed connection - B1" } ========= I tested with FreeIpa fedora-39-4.11.0 docker with the recent version of 389ds. ldapsearch -V ldapsearch: @(#) $OpenLDAP: ldapsearch 2.6.6 (Jul 31 2023 00:00:00) $ Thank you. JHK

1 0

Solving naming conflicts in replicated environment
by William Faulk 19 Jan '24

19 Jan '24

I have an IdM/freeipa installation with around 30 replicas. I have an entry for a computer that exist across all of those replicas. However, one of the replicas has incorrect data in the DN, with the correct data found in a conflict entry. (It appears that that entry was created on that replica, somehow didn't get replicated anywhere else, and then the entry was created again on a different replica.) I would like to resolve this naming conflict. The documentation (RHDS 10 Admin Guide, §15.26.1) states that the correct way to "promote" a conflict entry to the active entry is to first delete the active entry and then rename the conflict entry. (I'm running an old version of IdM that uses a 389-ds that doesn't include the dsconf utility.) But it seems to me that if I send a delete operation to the replica with the bad data, it's just going to replicate that delete operation to all the other replicas, deleting the correct data from all the other replicas, which seems like an awfully dramatic action to take. To reiterate, the correct data exists on all of the other replicas in an entry with the same DN as the entry with the bad data on the "bad" replica. I have tried to recreate this situation with a new DN that doesn't reference active systems, but I have been unsuccessful. Can someone confirm that deleting the bad entry from the bad replica will cause the good entries on all the good replicas to also be deleted? If so, is there a better way to resolve this conflict? (At the moment, I'm inclined to just reinitialize the data on this one replica.)

4 10

Announcing 389 Directory Server 2.4.5
by Viktor Ashirov 18 Jan '24

18 Jan '24

389 Directory Server 2.4.5 The 389 Directory Server team is proud to announce 389-ds-base version 2.4.5 Fedora packages are available on Fedora 39 and Rawhide. Fedora 39: https://koji.fedoraproject.org/koji/taskinfo?taskID=111921314 - Koji https://bodhi.fedoraproject.org/updates/FEDORA-2024-a6081ceaf9 - Bodhi Rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=111921327 - Koji https://bodhi.fedoraproject.org/updates/FEDORA-2024-2f482da5c8 - Bodhi The new packages and versions are: - 389-ds-base-2.4.5 Source tarballs are available for download at GitHub Releases page <https://github.com/389ds/389-ds-base/releases/tag/389-ds-base-2.4.5>: - https://github.com/389ds/389-ds-base/releases/download/389-ds-base- 2.4.5/389-ds-base-2.4.5.tar.bz2 <https://github.com/389ds/389-ds-base/releases/download/389-ds-base-2.4.5/38…> Highlights in 2.4.5 - Enhancements, and 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.o… 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 2.4.5 - Issue 5989 - RFE support of inChain Matching Rule (#5990) - Issue 5939 - During an update, if the target entry is reverted in the entry cache, the server should not retry to lock it (#6007) - Issue 5944 - Reversion of the entry cache should be limited to BETXN plugin failures (#5994) - Issue 5954 - Disable Transparent Huge Pages - Issue 5984 - Crash when paged result search are abandoned - fix2 (#5987) - Issue 5984 - Crash when paged result search are abandoned (#5985)

1 0

Password storage scheme - choices
by John Thurston 12 Jan '24

12 Jan '24

We've moving from DS 1.4 --> DS 2.1 With DS 1.4, we have our password hashing set to PBKDF2_SHA256. Our DS 2.1 defaults to PBKDF2-SHA512. During the cutover phase, I want to set the 2.1 instances back to SHA256. We'd then advance the storage scheme to SHA512 when we were ready to sever our links to the past. Through the cockpit-interface, I may choose among: * PBKDF2-SHA1 * PBKDF2-SHA256 * PBKDF2-SHA512 * PBKDF2_SHA256 Are the two SHA256 choices the same? Is there some significance I'm missing in the "_" and the "-" characters? -- -- Do things because you should, not just because you can. John Thurston 907-465-8591 John.Thurston(a)alaska.gov Department of Administration State of Alaska

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users January 2024