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>
Fix comparison bug that prevents ldap_disable to actually disable a
service.
Fixes: https://pagure.io/freeipa/issue/8143
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
ipa-server-install fails if idstart is set to 0. There might be
additional issues when idstart overlaps with local users. Ensure that
idstart is larger than UID_MAX or GID_MAX from /etc/login.defs.
Fixes: https://pagure.io/freeipa/issue/8137
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
After an upgrade, the group cn=adtrust agents may be missing some members.
Each ad trust controller must appear twice as member:
- krbprincipalname=cifs/hostname@realm,cn=services,cn=accounts,basedn
- fqdn=hostname,cn=computers,cn=accounts,basedn
Add an upgrade plugin that builds a list of hostnames from the cifs
principals and adds if needed fqdn=hostname...
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1778777
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abbra@users.noreply.github.com>
urllib3 now supports post-handshake authentication with TLS 1.3. Enable
TLS 1.3 support for Apache HTTPd.
The update depends on bug fixes for TLS 1.3 PHA support in urllib3 and
Apache HTTPd. New builds are available in freeipa-master COPR and in
F30/F31.
Overwrite crypto-policy on Fedora only. Fedora 31 and earlier have TLS
1.0 and 1.1 still enabled by default.
Fixes: https://pagure.io/freeipa/issue/8125
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
If a replica has no Samba bindings but there are trust agreements
configured on some trust controller, skip trust upgrade code on this
replica.
Resolves: https://pagure.io/freeipa/issue/8001
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
While [1] did open recursion, it also opened widely a security flaw.
This patch intends to close it back, while allowing operators to easily
add their open configuration within Bind9.
In order to allow operators to still open Bind recursion, a new file is
introduced, "ipa-ext.conf" (path might change according to the OS). This
file is not managed by the installer, meaning changes to it won't be
overridden.
Since it's included at the very end of the main configuration file, it
also allows to override some defaults - of course, operators have to be
careful with that.
Related-Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1754530
Fixes: https://pagure.io/freeipa/issue/8079
[1] 5f4c75eb28
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Stanislav Levin <slev@altlinux.org>
LDAP updater now ignores commented out lines after substitution.
Fixes: https://pagure.io/freeipa/issue/8111
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Add FIPS conditional to updates to prevent updater from adding camellia
encsalttypes.
Fixes: https://pagure.io/freeipa/issue/8111
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
New Pylint (2.4.3) catches several new 'true problems'. At the same
time, it warns about things that are massively and reasonably
employed in FreeIPA.
list of fixed:
- no-else-continue
- redeclared-assigned-name
- no-else-break
- unnecessary-comprehension
- using-constant-test (false positive)
list of ignored (responsibility of contributors and reviewers):
- import-outside-toplevel
Fixes: https://pagure.io/freeipa/issue/8102
Signed-off-by: Stanislav Levin <slev@altlinux.org>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Python2 and python3 have different interfaces for os.mkdir:
python2: os.mkdir(path[, mode])
python3: os.mkdir(path, mode=0o777, *, dir_fd=None)
ipa-backup is using the python3 format, which breaks deployments using
python2. The fix consists in using os.mkdir(path, 0o700) instead of
os.mkdir(path, mode=0o700).
Fixes: https://pagure.io/freeipa/issue/8099
Reviewed-By: Alexander Bokovoy <abbra@users.noreply.github.com>
Add an upgrade script to detect when ipakra people entry has
incorrect 'description' attribute and fix it.
Part of: https://pagure.io/freeipa/issue/8084
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
If IPA CA has custom subject DN (not "CN=Certificate
Authority,{subject_base}"), the uid=ipakra people entry gets an
incorrect 'description' attribute. The issuer DN in the
'description' attribute is based on the aforementioned pattern,
instead of the actual IPA CA subject DN.
Update KRAInstance.configure_instance() to require the CA subject DN
argument. Update ipaserver.install.kra.install() to pass the CA
subject DN.
Fixes: https://pagure.io/freeipa/issue/8084
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
This patche removes 93 pylint deprecation warnings due to invalid escape
sequences (mostly 'invalid escape sequence \d') on unicode strings.
Signed-off-by: Rafael Guterres Jeffman <rjeffman@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Dogtag had only one switch, ca.publish.enable, for both CRLs and certs.
Since cert publishing is not used in IPA it should be disabled to
avoid false positives in the logs.
https://pagure.io/freeipa/issue/7522
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Fraser Tweedale <ftweedal@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Previously it would end up being owned by root:root mode 0755
instead of dirsrv:dirsrv mode 0770.
https://pagure.io/freeipa/issue/7725
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
