Re: 389 DS 2.3.6 on RHEL 9 replication over TLS
by Thierry Bordaz
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...
[2]
https://access.redhat.com/documentation/en-us/red_hat_directory_server/12...
[3]
https://access.redhat.com/documentation/en-us/red_hat_directory_server/12...
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...>
> 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...>),
> 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.fedoraproje...
> 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.fe...
> Do not reply to spam, report it:https://pagure.io/fedora-infrastructure/new_issue
3 months, 2 weeks
389 DS 2.3.6 on RHEL 9 replication over TLS
by Nazarenko, Alexander
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...> 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...>) , 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 months, 3 weeks
389ds connection not successful
by Jaehwan Kim
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
3 months, 3 weeks
Solving naming conflicts in replicated environment
by William Faulk
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.)
3 months, 3 weeks
Password storage scheme - choices
by John Thurston
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
4 months
