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? many thanks, L.
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.
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.
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.
This may also point that one side is using TLS and the other side is not.
rob
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.
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:
- grab Centos Stream, 2) get 389ds module and install needed packages,
- 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
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.
This may also point that one side is using TLS and the other side is not.
rob
I also wonder if there something up with 389-ds-base-1.4.3.8-6.module_el8.3.0+604+ab7bf9cc.x86_64(which I've not tried) VS 389-ds-base-1.4.3.16-8.module_el8.4.0+644+ed25d39e.x86_64 (ps. also IPA 4.9.0 has just vanished from Centos' repos, so it seems)
On ma, 01 helmi 2021, lejeczek via FreeIPA-users wrote:
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.
This may also point that one side is using TLS and the other side is not.
rob
I also wonder if there something up with 389-ds-base-1.4.3.8-6.module_el8.3.0+604+ab7bf9cc.x86_64(which I've not tried) VS 389-ds-base-1.4.3.16-8.module_el8.4.0+644+ed25d39e.x86_64 (ps. also IPA 4.9.0 has just vanished from Centos' repos, so it seems)
This might be your local mirror's issue. The packages are available in http://mirror.centos.org/centos/8-stream/AppStream/x86_64/os/Packages/
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
lejeczek -
Rob Crittenden