URL: https://github.com/freeipa/freeipa/pull/1138 Author: frasertweedale Title: #1138: KRA install: log into security domain on master Action: opened
PR body: """ KRA clone installation can fail due to security domain token authentication failure that arises because: 1. The security domain session gets created on the replica's CA instance. 2. The "updateNumberRange" is performed against the master's KRA subsystem, and results in a token authentication request to the CA subsystem on the same host (i.e. the master) 3. LDAP replication lag means that the master does not yet see the security domain session that was created on the replica. To avoid this problem, update the KRA pkispawn configuration for cloning to log into the security domain on the master, instead of the CA subsystem on the replica. Fixes: https://pagure.io/freeipa/issue/7087 ----- How to test: - Install DL0 master. Perform replica installation with CA and KRA (`--setup-ca --setup-kra`). - Install DL0 master. Perform replica installation with CA. Perform subsequent KRA installation with `ipa-kra-install`. - Install DL1 master. Perform replica installation with CA and KRA (i.e. check that this still works) """ To pull the PR as Git branch: git remote add ghfreeipa https://github.com/freeipa/freeipa git fetch ghfreeipa pull/1138/head:pr1138 git checkout pr1138
From 447615e7c3f0b3edcc3b8290b388a2abde3f4270 Mon Sep 17 00:00:00 2001 From: Fraser Tweedale <ftwee...@redhat.com> Date: Tue, 10 Oct 2017 16:29:46 +1100 Subject: [PATCH] KRA install: log into security domain on master KRA clone installation can fail due to security domain token authentication failure that arises because: 1. The security domain session gets created on the replica's CA instance. 2. The "updateNumberRange" is performed against the master's KRA subsystem, and results in a token authentication request to the CA subsystem on the same host (i.e. the master) 3. LDAP replication lag means that the master does not yet see the security domain session that was created on the replica. To avoid this problem, update the KRA pkispawn configuration for cloning to log into the security domain on the master, instead of the CA subsystem on the replica. Fixes: https://pagure.io/freeipa/issue/7087 --- ipaserver/install/krainstance.py | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/ipaserver/install/krainstance.py b/ipaserver/install/krainstance.py index c1af7c0bd6..9c0867de8a 100644 --- a/ipaserver/install/krainstance.py +++ b/ipaserver/install/krainstance.py @@ -253,7 +253,13 @@ def __spawn_instance(self): os.chown(p12_tmpfile_name, pent.pw_uid, pent.pw_gid) # Security domain registration - config.set("KRA", "pki_security_domain_hostname", self.fqdn) + # + # We log into the security domain on master_host instead of self + # to avoid replication lag causing authentication failure when + # the security domain session is created on the REPLICA, but + # validated on the MASTER during KRA configuration + # + config.set("KRA", "pki_security_domain_hostname", self.master_host) config.set("KRA", "pki_security_domain_https_port", "443") config.set("KRA", "pki_security_domain_user", self.admin_user) config.set("KRA", "pki_security_domain_password",
_______________________________________________ FreeIPA-devel mailing list -- freeipa-devel@lists.fedorahosted.org To unsubscribe send an email to freeipa-devel-le...@lists.fedorahosted.org
