On 01/02/2021 13:33, Rob Crittenden wrote:
lejeczek via FreeIPA-users wrote:
On 01/02/2021 11:58, Alexander Bokovoy wrote:
On ma, 01 helmi 2021, lejeczek via FreeIPA-users wrote:
Hi guys,
I'm trying to set up replication for a non-IPA database following
RHEL's docs, I'm on Centos Stream, and I get errors:
....
[01/Feb/2021:11:25:38.854769282 +0000] - ERR - slapi_ldap_bind -
Could not send bind request for id [cn=replication manager,cn=config]
authentication mechanism [SIMPLE]: error -1 (Can't contact LDAP
server), system error -5987 (Invalid function argument.), network
error 0 (Unknown error, host "dzien.private:636")
[01/Feb/2021:11:25:38.856822436 +0000] - ERR - NSMMReplicationPlugin
- bind_and_check_pwp - agmt="cn=swir-dzien-agreement" (dzien:636) -
Replication bind with SIMPLE auth failed: LDAP error -1 (Can't
contact LDAP server) (error:0407008A:rsa
routines:RSA_padding_check_PKCS1_type_1:invalid padding)
[01/Feb/2021:11:25:41.874045655 +0000] - ERR - slapi_ldap_bind -
Could not send bind request for id [cn=replication manager,cn=config]
authentication mechanism [SIMPLE]: error -1 (Can't contact LDAP
server), system error -5987 (Invalid function argument.), network
error 0 (Unknown error, host "dzien.private:636")
...
Instructions seem rather solid & easy to follow. What am I missing
when you look at the errors?
From seeing openssl errors ('rsa
routines:RSA_padding_check_PKCS1_type_1:invalid padding'), I guess your
other LDAP server was set up using SSL parameters which don't work
against the current system-wide crypto policy in CentOS 8 Stream.
In particular, error:0407008A means signature verification failures.
These might also be connected with TLS 1.0 and RSA 1024-bit length keys
or being under POODLE attacks on that RSA key.
What you can do: to verify if this is indeed an issue with the other
key, you can temporarily set a LEGACY crypto policy with
update-crypto-policies --show
update-crypto-policies --set LEGACY
on IPA server side, restart IPA, retry. If that fixes the issue, it
means the other side's LDAPS support is bad with regards to contemporary
crypto standards. Upgrading the other side to TLS 1.2 + most likely
regenarating the RSA key in that LDAP server would be needed anyway.
Once you have figured out an upgrade on the other LDAP server side, make
sure to switch IPA's server's crypto policy back to DEFAULT.
But these are just guesses.
Before I begin fiddling - both ends/nodes show "DEFAULT" and both ends
had this policy at the time new ds instance were created, this way:
-> $ dscreate interactive
so, it then may make you wonder how come 'dscreate' process (and 389ds
in entirety) "allowed" such a ds instance which did not stick to policy
to come into existence.
Could it be that something which should "just" work, did not and it's
possibly buggy?
many! thanks, L.
Crypto policies are enforced regardless of what the user requests.
exactly what I was guessing... :)
This may also point that one side is using TLS and the other side is not.
rob
I'm itching to file a bug report but before I do I'd like to
say - what I see should be very easy to reproduce and if
anybody else is itchy too: 1) grab Centos Stream, 2) get
389ds module and install needed packages, 3) follow RHEL's
docs on "15.3. Multi-Master Replication" and you should hit
that very same error I'm getting.
regards, L.
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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.fedorahosted.org/archives/list/[email protected]
