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
_______________________________________________
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]
