sshd 8.2+ now supports the "Include" keyword in sshd_config and
ships by default /etc/ssh/sshd_config with
"Include /etc/ssh/sshd_config.d/*"
As fedora 32 provides a config file in that directory (05-redhat.conf) with
ChallengeResponseAuthentication no
that is conflicting with IPA client config, ipa-client-install now needs
to make its config changes in a drop-in file read before 05-redhat.conf
(the files are read in lexicographic order and the first setting wins).
There is no need to handle upgrades from sshd < 8.2: if openssh-server
detects a customisation in /etc/ssh/sshd_config, it will not update
the file but create /etc/ssh/sshd_config.rpmnew and ask the admin
to manually handle the config upgrade.
Fixes: https://pagure.io/freeipa/issue/8304
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Some places have to use the old name because it's part of the stable API
or stable LDAP attributes.
See: https://tools.ietf.org/id/draft-knodel-terminology-01.html
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abbra@users.noreply.github.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abbra@users.noreply.github.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
The term "CA renewal master" is a fixed term in FreeIPA and cannot
easily be replaced with an alternative term. At least we should use the
term consistently.
See: https://tools.ietf.org/id/draft-knodel-terminology-01.html
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abbra@users.noreply.github.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
We do two things:
1. Fix the xpath for AJP connector verification. An AJP connector is
one which has protocol="AJP/1.3", NOT one that has port="8009". An
AJP connector can exist on any port and port 8009 can have any
protocol. Secrets only make sense on AJP connectors, so make the
xpath match the existing comment.
2. Add some background in-line documentation about AJP secret
provisioning. This should help future developers understand why this
was added to IPA and what limitations there are in what PKI or IPA
can do. Most notably, explain why Dogtag can't upgrade the AJP
connector to have a secret in the general case.
Signed-off-by: Alexander Scheel <ascheel@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
It was found that if an account was created with a name corresponding to
an account local to a system, such as 'root', was created via IPA, such
account could access any enrolled machine with that account, and the local
system privileges. This also bypass the absence of explicit HBAC rules.
root principal alias
-------------------
The principal "root@REALM" is now a Kerberos principal alias for
"admin". This prevent user with "User Administrator" role or
"System: Add User" privilege to create an account with "root" principal
name.
Modified user permissions
-------------------------
Several user permissions no longer apply to admin users and filter on
posixaccount object class. This prevents user managers from modifying admin
acounts.
- System: Manage User Certificates
- System: Manage User Principals
- System: Manage User SSH Public Keys
- System: Modify Users
- System: Remove Users
- System: Unlock user
``System: Unlock User`` is restricted because the permission also allow a
user manager to lock an admin account. ``System: Modify Users`` is restricted
to prevent user managers from changing login shell or notification channels
(mail, mobile) of admin accounts.
New user permission
-------------------
- System: Change Admin User password
The new permission allows manipulation of admin user password fields. By
default only the ``PassSync Service`` privilege is allowed to modify
admin user password fields.
Modified group permissions
--------------------------
Group permissions are now restricted as well. Group admins can no longer
modify the admins group and are limited to groups with object class
``ipausergroup``.
- System: Modify Groups
- System: Remove Groups
The permission ``System: Modify Group Membership`` was already limited.
Notes
-----
Admin users are mostly unaffected by the new restrictions, except for
the fact that admins can no longer change krbPrincipalAlias of another
admin or manipulate password fields directly. Commands like ``ipa passwd
otheradmin`` still work, though. The ACI ``Admin can manage any entry``
allows admins to modify other entries and most attributes.
Managed permissions don't install ``obj.permission_filter_objectclasses``
when ``ipapermtargetfilter`` is set. Group and user objects now have a
``permission_filter_objectclasses_string`` attribute that is used
by new target filters.
Misc changes
------------
Also add new exception AlreadyContainsValueError. BaseLDAPAddAttribute
was raising a generic base class for LDAP execution errors.
Fixes: https://pagure.io/freeipa/issue/8326
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1810160
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
ipa-replica-install currently accepts both --setup-ca and *-cert-file
even though the options should be mutually exclusive (either install
CA-less with *-cert-file options or with a CA).
Add a check enforcing the options are mutually exclusive.
Fixes: https://pagure.io/freeipa/issue/8366
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
/etc/named.conf is now owned by IPA. The file is overwritten on
installation and all subsequent updates. All user modification will be
lost. Config file creation and update use the same code paths.
This simplifies upgrade process a lot. There is no errprone fiddling
with config settings any more.
During upgrade there is a one-time backup of named.conf to
named.conf.ipa-backup. It allows users to salvage their customization
and move them to one of two user config files which are included by
named.conf.
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The upgrade step used to add "dnssec-validation no" to named.conf IFF
named.conf did not contain "dnssec-validation" option at all. The
option has been moved to 'ipa-options-ext.conf' in IPA 4.8.7. The function
only removes the upgrade state.
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Commit a5cbdb57e5 introduced a bug when
updating IPA from 4.8.6 to 4.8.7. NAMED_DNSSEC_VALIDATION template
variable was not declared.
Fixes: https://pagure.io/freeipa/issue/8363
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
During upgrade, if discrepancies are detected in Certmonger tracking
request configuration we remove and re-create tracking requests.
The default behaviour of the CAInstance and KRAInstance
stop_tracking_certificates() method is to stop certmonger after the
requests have been removed. This behaviour results in an
unnecessary restart of certmonger and has also been observed to
cause problems. For example, subsequent certmonger operations have
to start the certmonger process and can fail because certmonger is
not yet properly initialised (manifesting as D-Bus errors).
Suppress the unnecessary restart(s) of certmonger during tracking
request update.
Related: https://pagure.io/freeipa/issue/8186
Reviewed-By: Alexander Bokovoy <abbra@users.noreply.github.com>
In the migration case of replica installation, if the CA server is
an older version it may not support the ipa-ca.$DOMAIN dnsName in
the HTTP cert (it is a special case in the cert_request command).
Therefore if the request fails, try it again without the
ipa-ca.$DOMAIN dnsName.
Part of: https://pagure.io/freeipa/issue/8186
Reviewed-By: Alexander Bokovoy <abbra@users.noreply.github.com>
Upgrade path to add additional include to named.conf is not handled.
Remove bindkeys-file directive from named config
The ISC DVL service was shut down (https://www.isc.org/bind-keys/).
BIND versions since April 2017 (i.e. 9.9.10, 9.10.5, 9.11.1 and later)
include a hard-coded copy of the root KSK which gets updates automatically
according to RFC 5011.
Move dnssec-enable directive to custom named config
Move comment named config being managed by FreeIPA to the top
Move settings which could be changed by administrators to
ipa-options-ext.conf. Settings defined there are sole responsibility of the
administrator. We do not check if they might collide with our settings in
named.conf.
Fixes: https://pagure.io/freeipa/issue/8287
Co-authored-by: Peter Keresztes Schmidt <carbenium@outlook.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The code in ipaldap got changed with df4ed77 but ldapupdate was never updated.
Closes: https://pagure.io/freeipa/issue/7610
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Make it possible to create a managed permission with
ipapermbindruletype="self". The ACI will have bind rule
'(userdn = "ldap:///self")'.
Example
-------
Allow users to modify their own fasTimezone and fasIRCNick attributes:
```
managed_permissions = {
"System: Self-Modify FAS user attributes": {
"ipapermright": {"write"},
"ipapermtargetfilter": ["(objectclass=fasuser)"],
"ipapermbindruletype": "self",
"ipapermdefaultattr": ["fasTimezone", "fasIRCNick"],
}
}
```
See: https://github.com/fedora-infra/freeipa-fas/pull/107
Fixes: https://pagure.io/freeipa/issue/8348
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
``dnssec-enable`` is obsolete in 9.16 and raises a warning. The option
defaults to ``yes`` in all supported versions of bind. The option is
removed when set to ``yes`` and a warning is emitted when the value is
``no``.
DNSSEC lookaside validation has been deprecated by RFC 8749 and the
feature removed from Bind 9.16. The only available lookaside provider
dlv.isc.org no longer provides DLV information since 2017.
Fixes: https://pagure.io/freeipa/issue/8349
Fixes: https://pagure.io/freeipa/issue/8350
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The ``--setup-dns`` knob and interactive installer now check for
presence of freeipa-server-dns early and stop the installer with an
error.
```
$ ipa-server-install
...
Do you want to configure integrated DNS (BIND)? [no]: yes
Integrated DNS requires 'freeipa-server-dns' package
The ipa-server-install command failed. See /var/log/ipaserver-install.log for more information
```
```
$ ipa-server-install --setup-dns
Usage: ipa-server-install [options]
ipa-server-install: error: option setup-dns: Integrated DNS requires 'freeipa-server-dns' package
The ipa-server-install command failed.
```
Fixes: https://pagure.io/freeipa/issue/7577
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Refactor code to use api.env.container_sysaccounts instead of
('cn', 'sysaccounts'), ('cn', 'etc')
Related: https://pagure.io/freeipa/issue/8276
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
ipa-backup does not check whether the IPA master it is running on has
all used roles installed. This can lead into situations where backups
are done on a CAless or KRAless host while these roles are used in the
IPA cluster. These backups cannot be used to restore a complete cluster.
With this change, ipa-backup refuses to execute if the roles installed
on the current host do not match the list of roles used in the cluster.
A --disable-role-check knob is provided to restore the previous behavior.
Fixes: https://pagure.io/freeipa/issue/8217
Signed-off-by: François Cami <fcami@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Mohammad Rizwan Yusuf <myusuf@redhat.com>
For detailed discussion on the purpose of this change and the design
decisions made, see `git log -1 $THIS_COMMIT~3`.
If the HTTP certificate does not have the ipa-ca.$DOMAIN dNSName,
resubmit the certificate request to add the name. This action is
performed after the tracking request has already been updated.
Note: due to https://pagure.io/certmonger/issue/143, the resubmitted
request, if it does not immediately succeed (fairly likely during
ipa-server-upgrade) and if the notAfter date of the current cert is
still far off (also likely), then Certmonger will wait 7 days before
trying again (unless restarted). There is not much we can do about
that in the middle of ipa-server-upgrade.
Part of: https://pagure.io/freeipa/issue/8186
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
For detailed discussion on the purpose of this change and the design
decisions made, see `git log -1 $THIS_COMMIT~2`.
For new server/replica installation, issue the HTTP server
certificate with the 'ipa-ca.$DOMAIN' SAN dNSName. This is
accomplished by adding the name to the Certmonger tracking request.
Part of: https://pagure.io/freeipa/issue/8186
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
BACKGROUND:
We are implementing ACME support in FreeIPA (umbrella ticket:
https://pagure.io/freeipa/issue/4751). ACME is defined in RFC 8555.
HTTPS is REQUIRED (https://tools.ietf.org/html/rfc8555#section-6.1).
Therefore, every FreeIPA server that provides the ACME service
capability must be reachable by HTTPS.
RFC 8555 does not say anything about which port to use for ACME.
The default HTTPS port of 443 is implied. Therefore, the FreeIPA
ACME service will be reached via the Apache httpd server, which will
be the TLS server endpoint.
As a usability affordance for ACME clients, and as a maintainability
consideration i.e. to allow the topology to change without having to
reconfigure ACME clients, there should be a a single DNS name used
to reach the IPA ACME service.
The question then, is which DNS name to use.
REQUIREMENTS:
Each FreeIPA server that is also an ACME server must:
1. Be reachable via a common DNS name
2. Have an HTTP service certificate with that DNS name as a SAN
dNSName value
DESIGN CONSIDERATION - WHAT DNS NAME TO USE?:
Some unrelated FreeIPA ACME design decisions provide important
context for the DNS name decision:
- The ACME service will be automatically and unconditionally
deployed (but not necessarily *enabled*) on all CA servers.
- Enabling or disabling the ACME service will have topology-wide
effect, i.e. the ACME service is either enabled on all CA
servers, or disabled on all CA servers.
In a CA-ful FreeIPA deployment there is already a DNS name that
resolves to all CA servers: ``ipa-ca.$DOMAIN``, e.g.
``ipa-ca.example.com``. It is expected to point to all CA servers
in the deployment, and *only* to CA servers. If internal DNS is
deployed, the DNS records for ``ipa-ca.$DOMAIN`` are created and
updated automatically. If internal DNS is not deployed,
administrators are required to maintain these DNS records
themselves.
The ``ipa-ca.$DOMAIN`` alias is currently used for OCSP and CRL
access. TLS is not required for these applications (and it can
actually be problematic for OCSP). Enabling TLS for this name
presents some risk of confusion for operators. For example, if they
see that TLS is available and alter the certificate profiles to
include an HTTPS OCSP URL in the Authority Information Access (AIA)
extension, OCSP-using clients may fail to validate such
certificates. But it is possible for administrators to make such a
change to the profile, whether or not HTTPS is available.
One big advantage to using the ``ipa-ca.$DOMAIN`` DNS name is that
there are no new DNS records to manage, either in the FreeIPA
implementation or for administrators in external DNS systems.
The alternative approach is to define a new DNS name, e.g.
``ipa-acme.$DOMAIN``, that ACME clients would use. For internal
DNS, this means the FreeIPA implementation must manage the DNS
records. This is straightforward; whenever we add or remove an
``ipa-ca.$DOMAIN`` record, also add/remove the ``ipa-acme.$DOMAIN``
record. But for CA-ful deployments using external DNS, it is
additional work for adminstrators and, unless automated, additional
room for error.
An advantage of using a different DNS name is ``ipa-ca.$DOMAIN`` can
remain inaccessible over HTTPS. This possibly reduces the risk of
administrator confusion or creation of invalid AIA configuration in
certificate profiles.
Weighing up the advantages and disadvantages, I decided to use the
``ipa-ca.$DOMAIN`` DNS name.
DESIGN CONSIDERATION - CA SERVERS, OR ALL SERVERS?:
A separate decision from which name to use is whether to include it
on the HTTP service certificate for ACME servers (i.e. CA servers)
only, or on all IPA servers.
Combined with the assumption that the chosen DNS name points to CA
servers *only*, there does not seem to be any harm in adding it to
the certificates on all IPA servers.
The alternative is to only include the chosen DNS name on the HTTP
service certificates of CA servers. This approach entails some
additional complexity:
- If a non-CA replica gets promoted to CA replica (i.e. via
``ipa-ca-install``), its HTTP certificate must be re-issued with
the relevant name.
- ipa-server-upgrade code must consider whether the server is a CA
replica when validating (and if necessary re-creating) Certmonger
tracking requests
- IPA Health Check must be made aware of this factor when checking
certificates and Certmonger tracking requests.
Weighing up the options, I decided to add the common DNS name to the
HTTP service certificate on all IPA servers. This avoids the
implementation complexity discussed above.
CHANGES IN THIS COMMIT
When (re-)tracking the HTTP certificate, explicitly add the server
FQDN and ipa-ca.$DOMAIN DNS names to the Certmonger tracking request.
Related changes follow in subsequent commits.
Part of: https://pagure.io/freeipa/issue/8186
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
This partially restores the pre-ec73de969f state of `http_proxy`,
which fails to restart the apache service during master
installation. The failure happens because of apache is not
configured yet on 'pki-tomcatd' installation phase. The mentioned
code and proposed one relies on the installer which bootstraps the
master.
Fixes: https://pagure.io/freeipa/issue/8233
Signed-off-by: Stanislav Levin <slev@altlinux.org>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
When IPA was not installed on the restore target host, and
when httpd was already running, "ipactl stop" does not stop
httpd. "ipactl start" at the end of the restore tool will
therefore not restart httpd either.
Calling "ipactl restart" at the end of the restore fixes the
issue, and as an added bonus, makes sure IPA can restart itself
properly.
Fixes: https://pagure.io/freeipa/issue/8226
Signed-off-by: François Cami <fcami@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Move all the routines run_ods* from tasks to _ods14 or _ods21 module
Related: https://pagure.io/freeipa/issue/8214
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
When migrating the DNSSec Master to a replica, the setup of
opendnssec is re-using the database and needs to call zonelist
export.
With opendnssec 1.4 this call is done with ods-ksmutil while
opendnssec 2.1 uses ods-enforcer that communicates with
odsenforcerd that is not started yet.
Move the call after ods-enforcerd is started.
Related: https://pagure.io/freeipa/issue/8214
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
The communication between ods-signer and the socket-activated process
has changed with OpenDNSSEC 2.1. Adapt ipa-ods-exporter to support also
the new protocol.
The internal database was also modified. Add a wrapper calling the
right code (table names hab=ve changed, as well as table columns).
With OpenDNSSEC the policy also needs to be explicitely loaded after
ods-enforcer-db-setup has been run, with
ods-enforcer policy import
The command ods-ksmutil notify must be replace with ods-enforce flush.
Related: https://pagure.io/freeipa/issue/8214
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
In opendnssec 2.1.6, the <Interval> element is not supported in the
configuration file.
Related: https://pagure.io/freeipa/issue/8214
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
AJP implementation in Tomcat is vulnerable to CVE-2020-1938 if used
without shared secret. Set up a shared secret between localhost
connector and Apache mod_proxy_ajp pass-through.
For existing secured AJP pass-through make sure the option used for
configuration on the tomcat side is up to date. Tomcat 9.0.31.0
deprecated 'requiredSecret' option name in favor of 'secret'. Details
can be found at https://tomcat.apache.org/migration-9.html#Upgrading_9.0.x
Fixes: https://pagure.io/freeipa/issue/8221
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
As we need to store credentials for AJP protocol comminucation,
ensure only root can read the configuration file.
Related: https://pagure.io/freeipa/issue/8221
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
When ipa-adtrust-install is run, the tool detects masters that are
not enabled as trust agents and propose to configure them. With the
current code, the Schema Compat plugin is not enabled on these new
trust agents and a manual restart of LDAP server + SSSD is required.
With this commit, ipa-adtrust-install now calls remote code on the new
agents through JSON RPC api, in order to configure the missing parts.
On the remote agent, the command is using DBus and oddjob to launch
a new command,
/usr/libexec/ipa/oddjob/org.freeipa.server.trust-enable-agent [--enable-compat]
This command configures the Schema Compat plugin if --enable-compat is
provided, then restarts LDAP server and SSSD.
If the remote agent is an older version and does not support remote
enablement, or if the remote server is not responding, the tool
ipa-adtrust-install prints a WARNING explaining the steps that need
to be manually executed in order to complete the installation, and
exits successfully (keeping the current behavior).
Fixes: https://pagure.io/freeipa/issue/7600
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Sergey Orlov <sorlov@redhat.com>
We cannot gather information about required DNS records before "ADTrust
Controller" role is enabled on this server. As result, we need to call
the step to add DNS records after the role was enabled.
Fixes: https://pagure.io/freeipa/issue/8192
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
This is the first time running Pylint-2.4 over the whole IPA codebase.
```
Pylint on /usr/bin/python is running, please wait ...
internal error with sending report for module ['ipaserver/plugins/serverroles.py']
maximum recursion depth exceeded while calling a Python object
************* Module ipatests.test_integration.base
ipatests/test_integration/base.py:84: [W0125(using-constant-test), IntegrationTest.install] Using a conditional statement with a constant value)
************* Module ipaserver.install.ipa_cacert_manage
ipaserver/install/ipa_cacert_manage.py:522: [R1724(no-else-continue), CACertManage.delete] Unnecessary "elif" after "continue")
```
The latest Pylint (via the Tox task) checks only:
```
{envsitepackagesdir}/ipaclient \
{envsitepackagesdir}/ipalib \
{envsitepackagesdir}/ipapython
```
, while the distro-Pylint runs over all project but it is not fresh.
That's why these warnings/errors weren't exposed before now.
Concerning `internal error`: a fix was accepted by upstream:
https://github.com/PyCQA/pylint/issues/3245, but wasn't released yet.
Until that is done, Pylint just warns.
Related: https://pagure.io/freeipa/issue/8116
Signed-off-by: Stanislav Levin <slev@altlinux.org>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Previously in order to enable the LDAP profile subsystem
the ca_enable_ldap_profile_subsystem() would check the
current value of the profile subsystem class parameter in
CS.cfg. If the parameter was still set to the default value
(i.e. ProfileSubsystem), the code would change it to
LDAPProfileSubsystem.
There is a effort in PKI to clean up the profile subsystem
classes which may require changing the default value for
this parameter. However, this improvement is blocked since
the ca_enable_ldap_profile_subsystem() is implicitly assuming
that the default value will always be ProfileSubsystem.
This patch modifies the code such that instead of checking
for a specific value that needs to be changed, it will check
whether it has the desired value already. This mechanism
will reduce potential conflicts with future PKI improvements.
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Commit 49cf5ec64b fixed a bug that
prevented migration from externally-signed to self-signed IPA CA.
But it introduced a subtle new issue: certmonger-initiated renewal
renews an externally-signed IPA CA as a self-signed CA.
To resolve this issue, introduce the `--force-self-signed' flag for
the dogtag-ipa-ca-renew-agent script. Add another certmonger CA
definition that calls this script with the `--force-self-signed'
flag. Update dogtag-ipa-ca-renew-agent to only issue a self-signed
CA certificate if the existing certificate is self-signed or if
`--force-self-signed' was given. Update `ipa-cacert-manage renew'
to supply `--force-self-signed' when appropriate.
As a result of these changes, certmonger-initiated renewal of an
externally-signed IPA CA certificate will not issue a self-signed
certificate.
Fixes: https://pagure.io/freeipa/issue/8176
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Before removing a CA re-verify all the other CAs to ensure that
the chain is not broken. Provide a force option to handle cases
where the CA is expired or verification fails for some other
reason, or you really just want them gone.
https://pagure.io/freeipa/issue/8124
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
The change to allow overlapping zone to be from the master itself has
introduced two issues: The check for the master itself should only executed
if options.force and options.allow_zone_overlap are both false and the
reverse zone check later on was still handling ValueError instead of
dnsutil.DNSZoneAlreadyExists.
Both issues have been fixed and the deployment with existing name servers
is properly working again.
Fixes: https://pagure.io/freeipa/issue/8150
Signed-off-by: Thomas Woerner <twoerner@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
When re-running `ipa-server-install --setup-dns` on already installed
server, we do not get to the check of being already installed because
DNS zone overlap forces us to fail earlier.
Change exception returned for this case from check_zone_overlap() to
return structured information that allows to understand whether we are
finding a conflict with ourselves.
Use the returned information to only fail DNS check at this point if DNS
zone overlap is generated by a different name server than ourselves.
Reviewed-By: Christian Heimes <cheimes@redhat.com>
After adding a replica to AD trust agent, the warning
message does not mention that restarting sssd is mantatory
for the trust agent to work. Fix the string.
Fixes: https://pagure.io/freeipa/issue/8148
Signed-off-by: François Cami <fcami@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
