lejeczek via FreeIPA-users wrote:
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.
You can file a doc bug I guess, or a bug against 389-ds-base. Please
don't file a bug against IPA as creating third-party agreements is not
supported.
rob