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/ht... [2] https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/ht... [3] https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/ht...
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@redhat.com *Sent:* Thursday, January 25, 2024 5:44:57 PM *To:* General discussion list for the 389 Directory server project. 389-users@lists.fedoraproject.org *Cc:* alexander_nazarenko@harvard.edu alexander_nazarenko@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@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/html-single/configuring_and_managing_replication/index> 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/html/securing_red_hat_directory_server/assembly_enabling-tls-encrypted-connections-to-directory-server_securing-rhds>), 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@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue-- _______________________________________________ 389-users mailing list --389-users@lists.fedoraproject.org To unsubscribe send an email to389-users-leave@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
"LDAP error: Can't contact LDAP server (connection error)" is kind of generic, but often relates to PKI trust misconfiguration when TLS is used, a common issue is the issuer / CA certificate(s) chain is not installed, or not trusted. There should be a message in the access log, for example "Peer does not recognize and trust the CA that issued your certificate."
a typical scenario is when the default test /demo/self signed certs are left over and used between 2 LDAP instances for replication, we have an example in this article (subscription required) https://access.redhat.com/solutions/6449561 How To test LDAPS with RHDS instances on 2 systems and default test CA this happens as there is no shared configuration between instances.
in the links Thierry B. posted, also see this chapter:
1.8. Adding the CA certificate used by Directory Server to the trust store of Red Hat Enterprise Linux https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/ht...
I usually run a "trust anchor some.file.ca.crt" command, and add the issuer(s) to the LDAP instance's NSS db.
On Fri, Jan 26, 2024 at 1:21 AM Thierry Bordaz tbordaz@redhat.com wrote:
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/ht... [2] https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/ht... [3] https://access.redhat.com/documentation/en-us/red_hat_directory_server/12/ht...
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@redhat.com spichugi@redhat.com *Sent:* Thursday, January 25, 2024 5:44:57 PM *To:* General discussion list for the 389 Directory server project. 389-users@lists.fedoraproject.org 389-users@lists.fedoraproject.org *Cc:* alexander_nazarenko@harvard.edu alexander_nazarenko@harvard.edu alexander_nazarenko@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@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/html-single/configuring_and_managing_replication/index 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/html/securing_red_hat_directory_server/assembly_enabling-tls-encrypted-connections-to-directory-server_securing-rhds ) , 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
-- _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@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@lists.fedoraproject.org
-
Marc Sauton -
Thierry Bordaz