In complex replication setups a replica may try to obtain CA keys from a host that is not the master we initially create the keys against. In this case race conditions may happen due to replication. So we need to make sure the server we are contacting to get the CA keys has our keys in LDAP. We do this by waiting to positively fetch our encryption public key (the last one we create) from the target host LDAP server. Fixes: https://pagure.io/freeipa/issue/6838 Signed-off-by: Simo Sorce <simo@redhat.com>
The cachedproperty class was used in one special use-case where it only caused issues. Let's get rid of it. https://pagure.io/freeipa/issue/6878 Reviewed-By: Martin Basti <mbasti@redhat.com> Reviewed-By: Christian Heimes <cheimes@redhat.com>
Refresh the ca_host property of the Dogtag's RestClient class when it's requested as a context manager. This solves the problem which would occur on DL0 when installing CA which needs to perform a set of steps against itself accessing 8443 port. This port should however only be available locally so trying to connect to remote master would fail. We need to make sure the right CA host is accessed. https://pagure.io/freeipa/issue/6878 Reviewed-By: Martin Basti <mbasti@redhat.com> Reviewed-By: Christian Heimes <cheimes@redhat.com>
ipa-client-install modifies /etc/krb5.conf and defines the following line:
pkinit_anchors = FILE: /etc/ipa/ca.crt
The extra space between FILE: and /etc/ipa/ca.crt break pkinit.
https://pagure.io/freeipa/issue/6916
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Http request performed in finalize_kerberos_acquisition doesn't use CA certificate/certificate store with full certificate chain of IPA server. So it might happen that in case that IPA is installed with externally signed CA certificate, the call can fail because of certificate validation and e.g. prevent session acquisition. If it will fail for sure is not known - the use case was not discovered, but it is faster and safer to fix preemptively. https://pagure.io/freeipa/issue/6876 Reviewed-By: Martin Basti <mbasti@redhat.com>
Reviewed-By: Martin Basti <mbasti@redhat.com>
So that gssproxy picks up new configuration and therefore related usages like authentication of CLI against server works https://pagure.io/freeipa/issue/6902 Reviewed-By: Tomas Krizek <tkrizek@redhat.com>
Change in 2d4d1a9dc0ef2bbe86751768d6e6b009a52c0dc9 no longer initializes api in `ipa-client-automount --uninstallation` Which caused error in wait_for_sssd which gets realm from initialized API. This patch initializes the API in a way that it doesn't download schema on uninstallation and on installation it uses host keytab for it so it no longer requires user's Kerberos credentials. Also fix call of xxx_service_class_factory which requires api as param. https://pagure.io/freeipa/issue/6861 Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Tomas Krizek <tkrizek@redhat.com>
An exception is raised when using echo "Secret123\n" | ipa vault-add myvault This happens because the code is using (string).decode(sys.stdin.encoding) and sys.stdin.encoding is None when the input is read from a pipe. The fix is using the prompt_password method defined by Backend.textui, which gracefully handles this issue. https://pagure.io/freeipa/issue/6907 Reviewed-By: Christian Heimes <cheimes@redhat.com> Reviewed-By: Abhijeet Kasurde <akasurde@redhat.com> Reviewed-By: Stanislav Laznicka <slaznick@redhat.com>
Local FAST armoring will now work regardless of PKINIT status so there is no need to explicitly test for working PKINIT. If there is, there should be a test case for that. https://pagure.io/freeipa/issue/6830 Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com> Reviewed-By: Jan Cholasta <jcholast@redhat.com> Reviewed-By: Martin Basti <mbasti@redhat.com> Reviewed-By: Simo Sorce <ssorce@redhat.com>