freeipa/install/tools/ipa-ca-install

317 lines
12 KiB
Plaintext
Raw Normal View History

#! /usr/bin/python2 -E
# Authors: Rob Crittenden <rcritten@redhat.com>
#
# Copyright (C) 2011 Red Hat
# see file 'COPYING' for use and warranty information
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
#
import sys
Add a KRA to IPA This patch adds the capability of installing a Dogtag KRA to an IPA instance. With this patch, a KRA is NOT configured by default when ipa-server-install is run. Rather, the command ipa-kra-install must be executed on an instance on which a Dogtag CA has already been configured. The KRA shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. To create a clone KRA, simply execute ipa-kra-install <replica_file> on a replica on which a Dogtag CA has already been replicated. ipa-kra-install will use the security domain to detect whether the system being installed is a replica, and will error out if a needed replica file is not provided. The install scripts have been refactored somewhat to minimize duplication of code. A new base class dogtagintance.py has been introduced containing code that is common to KRA and CA installs. This will become very useful when we add more PKI subsystems. The KRA will install its database as a subtree of o=ipaca, specifically o=ipakra,o=ipaca. This means that replication agreements created to replicate CA data will also replicate KRA data. No new replication agreements are required. Added dogtag plugin for KRA. This is an initial commit providing the basic vault functionality needed for vault. This plugin will likely be modified as we create the code to call some of these functions. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 The uninstallation option in ipa-kra-install is temporarily disabled. Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Petr Viktorin <pviktori@redhat.com>
2014-03-18 10:23:30 -05:00
import os
import shutil
import tempfile
from ipapython import ipautil
Add a KRA to IPA This patch adds the capability of installing a Dogtag KRA to an IPA instance. With this patch, a KRA is NOT configured by default when ipa-server-install is run. Rather, the command ipa-kra-install must be executed on an instance on which a Dogtag CA has already been configured. The KRA shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. To create a clone KRA, simply execute ipa-kra-install <replica_file> on a replica on which a Dogtag CA has already been replicated. ipa-kra-install will use the security domain to detect whether the system being installed is a replica, and will error out if a needed replica file is not provided. The install scripts have been refactored somewhat to minimize duplication of code. A new base class dogtagintance.py has been introduced containing code that is common to KRA and CA installs. This will become very useful when we add more PKI subsystems. The KRA will install its database as a subtree of o=ipaca, specifically o=ipakra,o=ipaca. This means that replication agreements created to replicate CA data will also replicate KRA data. No new replication agreements are required. Added dogtag plugin for KRA. This is an initial commit providing the basic vault functionality needed for vault. This plugin will likely be modified as we create the code to call some of these functions. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 The uninstallation option in ipa-kra-install is temporarily disabled. Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Petr Viktorin <pviktori@redhat.com>
2014-03-18 10:23:30 -05:00
from ipaserver.install import installutils
from ipaserver.install import certs
from ipaserver.install.installutils import create_replica_config
from ipaserver.install.installutils import check_creds, ReplicaConfig
from ipaserver.install import bindinstance, dsinstance, ca
from ipaserver.install import cainstance, custodiainstance, service
from ipapython import version
from ipalib import api
from ipalib.constants import DOMAIN_LEVEL_0
from ipapython.config import IPAOptionParser
from ipapython.ipa_log_manager import root_logger, standard_logging_setup
from ipaplatform.paths import paths
log_file_name = paths.IPAREPLICA_CA_INSTALL_LOG
REPLICA_INFO_TOP_DIR = None
def parse_options():
usage = "%prog [options] REPLICA_FILE"
parser = IPAOptionParser(usage=usage, version=version.VERSION)
parser.add_option("-d", "--debug", dest="debug", action="store_true",
default=False, help="gather extra debugging information")
parser.add_option("-p", "--password", dest="password", sensitive=True,
help="Directory Manager (existing master) password")
parser.add_option("-w", "--admin-password", dest="admin_password", sensitive=True,
help="Admin user Kerberos password used for connection check")
parser.add_option("--no-host-dns", dest="no_host_dns", action="store_true",
default=False,
help="Do not use DNS for hostname lookup during installation")
parser.add_option("--skip-conncheck", dest="skip_conncheck", action="store_true",
default=False, help="skip connection check to remote master")
Fix schema replication from old masters The new merged database will replicate with both the IPA and CA trees, so all DS instances (IPA and CA on the existing master, and the merged one on the replica) need to have the same schema. Dogtag does all its schema modifications online. Those are replicated normally. The basic IPA schema, however, is delivered in ldif files, which are not replicated. The files are not present on old CA DS instances. Any schema update that references objects in these files will fail. The whole 99user.ldif (i.e. changes introduced dynamically over LDAP) is replicated as a blob. If we updated the old master's CA schema dynamically during replica install, it would conflict with updates done during the installation: the one with the lower CSN would get lost. Dogtag's spawn script recently grew a new flag, 'pki_clone_replicate_schema'. Turning it off tells Dogtag to create its schema in the clone, where the IPA modifications are taking place, so that it is not overwritten by the IPA schema on replication. The patch solves the problems by: - In __spawn_instance, turning off the pki_clone_replicate_schema flag. - Providing a script to copy the IPA schema files to the CA DS instance. The script needs to be copied to old masters and run there. - At replica CA install, checking if the schema is updated, and failing if not. The --skip-schema-check option is added to ipa-{replica,ca}-install to override the check. All pre-3.1 CA servers in a domain will have to have the script run on them to avoid schema replication errors. https://fedorahosted.org/freeipa/ticket/3213
2012-10-24 03:37:16 -05:00
parser.add_option("--skip-schema-check", dest="skip_schema_check", action="store_true",
default=False, help="skip check for updated CA DS schema on the remote master")
parser.add_option("-U", "--unattended", dest="unattended", action="store_true",
default=False, help="unattended installation never prompts the user")
parser.add_option("--external-ca", dest="external_ca", action="store_true",
default=False, help="Generate a CSR to be signed by an external CA")
parser.add_option("--external-ca-type", dest="external_ca_type",
type="choice", choices=("generic", "ms-cs"),
help="Type of the external CA")
parser.add_option("--external-cert-file", dest="external_cert_files",
action="append", metavar="FILE",
help="File containing the IPA CA certificate and the external CA certificate chain")
parser.add_option("--ca-signing-algorithm", dest="ca_signing_algorithm",
type="choice",
choices=('SHA1withRSA', 'SHA256withRSA', 'SHA512withRSA'),
help="Signing algorithm of the IPA CA certificate")
parser.add_option("-P", "--principal", dest="principal", sensitive=True,
default=None, help="User allowed to manage replicas")
options, args = parser.parse_args()
safe_options = parser.get_safe_opts(options)
if args:
filename = args[0]
if len(args) != 1:
parser.error("you must provide a file generated by "
"ipa-replica-prepare")
options.external_ca = None
options.external_cert_files = None
else:
filename = None
if options.external_ca:
if options.external_cert_files:
parser.error("You cannot specify --external-cert-file "
"together with --external-ca")
if options.external_ca_type and not options.external_ca:
parser.error(
"You cannot specify --external-ca-type without --external-ca")
return safe_options, options, filename
Add a KRA to IPA This patch adds the capability of installing a Dogtag KRA to an IPA instance. With this patch, a KRA is NOT configured by default when ipa-server-install is run. Rather, the command ipa-kra-install must be executed on an instance on which a Dogtag CA has already been configured. The KRA shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. To create a clone KRA, simply execute ipa-kra-install <replica_file> on a replica on which a Dogtag CA has already been replicated. ipa-kra-install will use the security domain to detect whether the system being installed is a replica, and will error out if a needed replica file is not provided. The install scripts have been refactored somewhat to minimize duplication of code. A new base class dogtagintance.py has been introduced containing code that is common to KRA and CA installs. This will become very useful when we add more PKI subsystems. The KRA will install its database as a subtree of o=ipaca, specifically o=ipakra,o=ipaca. This means that replication agreements created to replicate CA data will also replicate KRA data. No new replication agreements are required. Added dogtag plugin for KRA. This is an initial commit providing the basic vault functionality needed for vault. This plugin will likely be modified as we create the code to call some of these functions. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 The uninstallation option in ipa-kra-install is temporarily disabled. Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Petr Viktorin <pviktori@redhat.com>
2014-03-18 10:23:30 -05:00
def get_dirman_password():
Add a KRA to IPA This patch adds the capability of installing a Dogtag KRA to an IPA instance. With this patch, a KRA is NOT configured by default when ipa-server-install is run. Rather, the command ipa-kra-install must be executed on an instance on which a Dogtag CA has already been configured. The KRA shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. To create a clone KRA, simply execute ipa-kra-install <replica_file> on a replica on which a Dogtag CA has already been replicated. ipa-kra-install will use the security domain to detect whether the system being installed is a replica, and will error out if a needed replica file is not provided. The install scripts have been refactored somewhat to minimize duplication of code. A new base class dogtagintance.py has been introduced containing code that is common to KRA and CA installs. This will become very useful when we add more PKI subsystems. The KRA will install its database as a subtree of o=ipaca, specifically o=ipakra,o=ipaca. This means that replication agreements created to replicate CA data will also replicate KRA data. No new replication agreements are required. Added dogtag plugin for KRA. This is an initial commit providing the basic vault functionality needed for vault. This plugin will likely be modified as we create the code to call some of these functions. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 The uninstallation option in ipa-kra-install is temporarily disabled. Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Petr Viktorin <pviktori@redhat.com>
2014-03-18 10:23:30 -05:00
return installutils.read_password(
"Directory Manager (existing master)", confirm=False, validate=False)
def install_replica(safe_options, options, filename):
if options.promote:
if filename is not None:
sys.exit("Too many parameters provided. "
"No replica file is required")
else:
if filename is None:
sys.exit("A replica file is required")
if not ipautil.file_exists(filename):
sys.exit("Replica file %s does not exist" % filename)
if not options.promote:
# Check if we have admin creds already, otherwise acquire them
check_creds(options, api.env.realm)
# get the directory manager password
dirman_password = options.password
if not dirman_password:
if options.unattended:
sys.exit('Directory Manager password required')
try:
dirman_password = get_dirman_password()
except KeyboardInterrupt:
sys.exit(0)
if dirman_password is None:
sys.exit("Directory Manager password required")
if (not options.promote and not options.admin_password and
not options.skip_conncheck and options.unattended):
Add a KRA to IPA This patch adds the capability of installing a Dogtag KRA to an IPA instance. With this patch, a KRA is NOT configured by default when ipa-server-install is run. Rather, the command ipa-kra-install must be executed on an instance on which a Dogtag CA has already been configured. The KRA shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. To create a clone KRA, simply execute ipa-kra-install <replica_file> on a replica on which a Dogtag CA has already been replicated. ipa-kra-install will use the security domain to detect whether the system being installed is a replica, and will error out if a needed replica file is not provided. The install scripts have been refactored somewhat to minimize duplication of code. A new base class dogtagintance.py has been introduced containing code that is common to KRA and CA installs. This will become very useful when we add more PKI subsystems. The KRA will install its database as a subtree of o=ipaca, specifically o=ipakra,o=ipaca. This means that replication agreements created to replicate CA data will also replicate KRA data. No new replication agreements are required. Added dogtag plugin for KRA. This is an initial commit providing the basic vault functionality needed for vault. This plugin will likely be modified as we create the code to call some of these functions. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 The uninstallation option in ipa-kra-install is temporarily disabled. Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Petr Viktorin <pviktori@redhat.com>
2014-03-18 10:23:30 -05:00
sys.exit('admin password required')
if options.promote:
config = ReplicaConfig()
config.master_host_name = None
config.realm_name = api.env.realm
config.host_name = api.env.host
config.domain_name = api.env.domain
config.dirman_password = dirman_password
config.ca_ds_port = 389
config.top_dir = tempfile.mkdtemp("ipa")
config.dir = config.top_dir
cafile = paths.IPA_CA_CRT
else:
config = create_replica_config(dirman_password, filename, options)
cafile = config.dir + '/ca.crt'
Add a KRA to IPA This patch adds the capability of installing a Dogtag KRA to an IPA instance. With this patch, a KRA is NOT configured by default when ipa-server-install is run. Rather, the command ipa-kra-install must be executed on an instance on which a Dogtag CA has already been configured. The KRA shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. To create a clone KRA, simply execute ipa-kra-install <replica_file> on a replica on which a Dogtag CA has already been replicated. ipa-kra-install will use the security domain to detect whether the system being installed is a replica, and will error out if a needed replica file is not provided. The install scripts have been refactored somewhat to minimize duplication of code. A new base class dogtagintance.py has been introduced containing code that is common to KRA and CA installs. This will become very useful when we add more PKI subsystems. The KRA will install its database as a subtree of o=ipaca, specifically o=ipakra,o=ipaca. This means that replication agreements created to replicate CA data will also replicate KRA data. No new replication agreements are required. Added dogtag plugin for KRA. This is an initial commit providing the basic vault functionality needed for vault. This plugin will likely be modified as we create the code to call some of these functions. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 The uninstallation option in ipa-kra-install is temporarily disabled. Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Petr Viktorin <pviktori@redhat.com>
2014-03-18 10:23:30 -05:00
global REPLICA_INFO_TOP_DIR
REPLICA_INFO_TOP_DIR = config.top_dir
config.setup_ca = True
if config.subject_base is None:
attrs = api.Backend.ldap2.get_ipa_config()
config.subject_base = attrs.get('ipacertificatesubjectbase')[0]
if config.master_host_name is None:
config.ca_host_name = \
service.find_providing_server('CA', api.Backend.ldap2, api.env.ca_host)
config.master_host_name = config.ca_host_name
else:
config.ca_host_name = config.master_host_name
options.realm_name = config.realm_name
options.domain_name = config.domain_name
options.dm_password = config.dirman_password
options.host_name = config.host_name
options.subject = config.subject_base
if os.path.exists(cafile):
options.ca_cert_file = cafile
else:
options.ca_cert_file = None
ca.install_check(True, config, options)
if options.promote:
ca_data = (os.path.join(config.dir, 'cacert.p12'),
config.dirman_password)
custodia = custodiainstance.CustodiaInstance(config.host_name,
config.realm_name)
custodia.get_ca_keys(config.ca_host_name, ca_data[0], ca_data[1])
CA = cainstance.CAInstance(config.realm_name, certs.NSS_DIR,
host_name=config.host_name)
CA.configure_replica(config.ca_host_name,
config.dirman_password,
subject_base=config.subject_base,
ca_cert_bundle=ca_data)
# Install CA DNS records
if bindinstance.dns_container_exists(api.env.host, api.env.basedn,
ldapi=True, realm=api.env.realm):
bind = bindinstance.BindInstance()
bind.update_system_records()
else:
ca.install(True, config, options)
Add a KRA to IPA This patch adds the capability of installing a Dogtag KRA to an IPA instance. With this patch, a KRA is NOT configured by default when ipa-server-install is run. Rather, the command ipa-kra-install must be executed on an instance on which a Dogtag CA has already been configured. The KRA shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. To create a clone KRA, simply execute ipa-kra-install <replica_file> on a replica on which a Dogtag CA has already been replicated. ipa-kra-install will use the security domain to detect whether the system being installed is a replica, and will error out if a needed replica file is not provided. The install scripts have been refactored somewhat to minimize duplication of code. A new base class dogtagintance.py has been introduced containing code that is common to KRA and CA installs. This will become very useful when we add more PKI subsystems. The KRA will install its database as a subtree of o=ipaca, specifically o=ipakra,o=ipaca. This means that replication agreements created to replicate CA data will also replicate KRA data. No new replication agreements are required. Added dogtag plugin for KRA. This is an initial commit providing the basic vault functionality needed for vault. This plugin will likely be modified as we create the code to call some of these functions. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 The uninstallation option in ipa-kra-install is temporarily disabled. Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Petr Viktorin <pviktori@redhat.com>
2014-03-18 10:23:30 -05:00
def install_master(safe_options, options):
dm_password = options.password
if not dm_password:
if options.unattended:
sys.exit('Directory Manager password required')
try:
dm_password = get_dirman_password()
except KeyboardInterrupt:
sys.exit(0)
if dm_password is None:
sys.exit("Directory Manager password required")
config = api.Command['config_show']()['result']
subject_base = config['ipacertificatesubjectbase'][0]
options.realm_name = api.env.realm
options.domain_name = api.env.domain
options.dm_password = dm_password
options.host_name = api.env.host
options.subject = subject_base
ca.install_check(True, None, options)
ca.install(True, None, options)
Add a KRA to IPA This patch adds the capability of installing a Dogtag KRA to an IPA instance. With this patch, a KRA is NOT configured by default when ipa-server-install is run. Rather, the command ipa-kra-install must be executed on an instance on which a Dogtag CA has already been configured. The KRA shares the same tomcat instance and DS instance as the Dogtag CA. Moreover, the same admin user/agent (and agent cert) can be used for both subsystems. Certmonger is also confgured to monitor the new subsystem certificates. To create a clone KRA, simply execute ipa-kra-install <replica_file> on a replica on which a Dogtag CA has already been replicated. ipa-kra-install will use the security domain to detect whether the system being installed is a replica, and will error out if a needed replica file is not provided. The install scripts have been refactored somewhat to minimize duplication of code. A new base class dogtagintance.py has been introduced containing code that is common to KRA and CA installs. This will become very useful when we add more PKI subsystems. The KRA will install its database as a subtree of o=ipaca, specifically o=ipakra,o=ipaca. This means that replication agreements created to replicate CA data will also replicate KRA data. No new replication agreements are required. Added dogtag plugin for KRA. This is an initial commit providing the basic vault functionality needed for vault. This plugin will likely be modified as we create the code to call some of these functions. Part of the work for: https://fedorahosted.org/freeipa/ticket/3872 The uninstallation option in ipa-kra-install is temporarily disabled. Reviewed-By: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Petr Viktorin <pviktori@redhat.com>
2014-03-18 10:23:30 -05:00
def install(safe_options, options, filename):
options.promote = False
try:
if filename is None:
install_master(safe_options, options)
else:
install_replica(safe_options, options, filename)
finally:
# Clean up if we created custom credentials
created_ccache_file = getattr(options, 'created_ccache_file', None)
if created_ccache_file is not None:
try:
os.unlink(created_ccache_file)
except OSError:
pass
def promote(safe_options, options, filename):
options.promote = True
with ipautil.private_ccache():
ccache = os.environ['KRB5CCNAME']
ipautil.kinit_keytab(
'host/{env.host}@{env.realm}'.format(env=api.env),
paths.KRB5_KEYTAB,
ccache)
ca_host = service.find_providing_server('CA', api.Backend.ldap2)
if ca_host is None:
install_master(safe_options, options)
else:
install_replica(safe_options, options, filename)
def main():
safe_options, options, filename = parse_options()
if os.geteuid() != 0:
sys.exit("\nYou must be root to run this script.\n")
if not dsinstance.DsInstance().is_configured():
sys.exit("IPA server is not configured on this system.\n")
if (not options.external_cert_files and
cainstance.is_ca_installed_locally()):
sys.exit("CA is already installed on this host.")
standard_logging_setup(log_file_name, debug=options.debug)
root_logger.debug("%s was invoked with options: %s,%s",
sys.argv[0], safe_options, filename)
root_logger.debug("IPA version %s", version.VENDOR_VERSION)
# override ra_plugin setting read from default.conf so that we have
# functional dogtag backend plugins during CA install
api.bootstrap(in_server=True, ra_plugin='dogtag')
api.finalize()
api.Backend.ldap2.connect()
domain_level = dsinstance.get_domain_level(api)
if domain_level > DOMAIN_LEVEL_0:
promote(safe_options, options, filename)
else:
install(safe_options, options, filename)
# execute ipactl to refresh services status
ipautil.run(['ipactl', 'start', '--ignore-service-failures'],
raiseonerr=False)
api.Backend.ldap2.disconnect()
fail_message = '''
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
'''
if __name__ == '__main__':
try:
installutils.run_script(main, log_file_name=log_file_name,
operation_name='ipa-ca-install',
fail_message=fail_message)
finally:
# always try to remove decrypted replica file
try:
if REPLICA_INFO_TOP_DIR:
shutil.rmtree(REPLICA_INFO_TOP_DIR)
except OSError:
pass