Password changes performed by cn=Directory Manager are excluded from
password policy checks according to [1]. This is correctly handled by
ipa-pwd-extop in case of a normal Kerberos principal in IPA. However,
non-kerberos accounts were not excluded from the check.
As result, password updates for PKI CA admin account in o=ipaca were
failing if a password policy does not allow a password reuse. We are
re-setting the password for PKI CA admin in ipa-replica-prepare in case
the original directory manager's password was updated since creation of
`cacert.p12`.
Do password policy check for non-Kerberos accounts only if it was set by
a regular user or admin. Changes performed by a cn=Directory Manager and
passsync managers should be excluded from the policy check.
Fixes: https://pagure.io/freeipa/issue/7181
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
[1] https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/user_account_management-managing_the_password_policy
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
SLAPI_BIND_TARGET_DN is deprecated since 2011 by 389-ds team,
see commit f6397113666f06848412bb12f754f04258cfa5fa in 389-ds:
https://pagure.io/389-ds-base/c/f6397113666f06848412bb12f754f04258cfa5fa?branch=master
Use SLAPI_BIND_TARGET_SDN instead and move internal ipa-pwd-extop
helpers to accept Slapi_DN references rather than strings.
Related: https://pagure.io/freeipa/issue/7181
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
ipa-pwd-extop plugin had a bug which prevented a cn=Directory Manager
to change a password to a value that is not allowed by an associated
password policy. Password policy checks should not apply to any
operations done as cn=Directory Manager.
The test creates a system account with associated policy that prevents
password reuse. It then goes to try to change a password three times:
- as a user: must succeeed
- as a cn=Directory Manager: must succeed even with a password re-use
- as a user again: must fail due to password re-use
Related: https://pagure.io/freeipa/issue/7181
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Extend ldappasswd_sysaccount_change() helper to allow changing
passwords as a cn=Directory Manager.
Related to: https://pagure.io/freeipa/issue/7181
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
SELinux policy on F30 doesn't have the interface
apache_manage_pid_files(). Define the interface conditionally.
Fixes: https://pagure.io/freeipa/issue/8241
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
'ipa group-add-member groupname --external some-object' will attempt to
ask interactive questions about other optional parameters (users and
groups) if only external group member was specified. This leads to a
timeout in the tests as there is no input provided.
Do not wait for the entry that would never come by using 'ipa -n'.
Related: https://pagure.io/freeipa/issue/8236
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Reviewed-By: Sergey Orlov <sorlov@redhat.com>
Add integration test that confirms that on CA-ful installation, the
(non-3rd-party) HTTP certificate bears the ipa-ca.$DOMAIN DNS name.
For detailed discussion on the purpose of this change and the design
decisions made, see `git log -1 $THIS_COMMIT~4`.
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~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>
For detailed discussion on the purpose of this change and the design
decisions made, see `git log -1 $THIS_COMMIT~1`.
ACME support requires TLS and we want ACME clients to access the
service via the ipa-ca.$DOMAIN DNS name. So we need to add the
ipa-ca.$DOMAIN dNSName to IPA servers' HTTP certificates. To
facilitiate this, add a special case to the cert-request command
processing. The rule is:
- if the dnsName being validated is "ipa-ca.$DOMAIN"
- and the subject principal is an "HTTP/..." service
- and the subject principal's hostname is an IPA server
Then that name (i.e. "ipa-ca.$DOMAIN") is immediately allowed.
Otherwise continue with the usual dnsName validation.
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>
We need to be able to filter Certmonger tracking requests by the DNS
names defined for the request. The goal is to add the
'ipa-ca.$DOMAIN' alias to the HTTP certificate tracking requests, so
we will use that name as a search criterion. Implement support for
this.
As a result of this commit it will be easy to add support for subset
match of other Certmonger request list properties. Just add the
property name to the ARRAY_PROPERTIES list (and update the
'criteria' description in the module docstring!)
Part of: https://pagure.io/freeipa/issue/8186
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
The 'criteria' parameter is used by several subroutines in the
ipalib.install.certmonger module. It has incomplete documentation
spread across several of these subroutines. Move the documentation
to the module docstring and reference it where appropriate.
Part of: https://pagure.io/freeipa/issue/8186
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
certmonger._get_requests has a mutable default argument. Although
at the present time it is never modified, this is an antipattern to
be avoided.
In fact, we don't even need the default argument, because it is
always called with a dict() argument. So just remove it.
Part of: https://pagure.io/freeipa/issue/8186
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
`ipa trust-add --password` command requires that user provides a password.
Related to: https://pagure.io/freeipa/issue/7895
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
This is to ensure if said entry is set after installation.
It also checks if compat tree is disable.
related: https://pagure.io/freeipa/issue/8193
Signed-off-by: Mohammad Rizwan Yusuf <myusuf@redhat.com>
Reviewed-By: Francois Cami <fcami@redhat.com>
Reviewed-By: Kaleemullah Siddiqui <ksiddiqu@redhat.com>
This is to ensure if said entry is set after installation with AD.
related: https://pagure.io/freeipa/issue/8193
Signed-off-by: Mohammad Rizwan Yusuf <myusuf@redhat.com>
Reviewed-By: Francois Cami <fcami@redhat.com>
Reviewed-By: Kaleemullah Siddiqui <ksiddiqu@redhat.com>
Several translated strings were splitted into smaller ones. The older
translation either is a duplicate of the new one or does not apply
anymore.
Reviewed-By: Christian Heimes <cheimes@redhat.com>
1. Build po/ipa.pot every time we update PO files (each build)
2. Drop any rebuilt PO changes if the only difference is in the
translation file's header in a timestamp or timestamp+bug report
link.
3. Only apply the logic for dropping the changes if we are operating on
a git tree checkout because there is no otherwise an easy way to
detect the changes.
4. Hook strip-po target to the cleanup target to allow dropping unneeded
translation changes automatically.
5. Finally, strip ipaclient/remote_plugins/* locations from the ipa.pot
template. This saves us around 23,000 lines from the ipa.pot file and
reduces visual clutter in the translation files.
This approach allows to avoid unneccesary commits because even when
there are no changes to translation files, po/ipa.pot header would be
updated with a new translation update timestamp.
Fixes: https://pagure.io/freeipa/issue/8159
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
Weblate tool sends pull requests that update translations directly.
For this to work, we need to keep ipa.pot in the tree.
Fixes: https://pagure.io/freeipa/issue/8159
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
The pytest_multihost transport does not provide password-based
authentication for OpenSSH transport. The OpenSSH command line tool has
no API to pass in a password securely.
The patch implements a custom transport that uses sshpass hack. It is
not recommended for production but good enough for testing.
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The test_integration/test_ordering.py is a test for pytest_sourceorder
plugin which is not part of freeipa project, it is not an integration test.
The up to date version of this test is available at project repository:
https://pagure.io/python-pytest-sourceorder/blob/master/f/test_sourceorder.py
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Since ipa_custodia got integrated into ipa policy package, the upstream policy
module needs to be disabled before ipa module installation (in order to be able
to make changes to the ipa_custodia policy definitions).
Upstream ipa module gets overridden automatically because of higher priority of
the custom module, but there is no mechanism to automatically disable
ipa_custodia.
Related: https://pagure.io/freeipa/issue/6891
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The code rather than the string was being displayed in human
output for non-SUCCESS messages. Verify that in case of an error
the right output will be present.
https://bugzilla.redhat.com/show_bug.cgi?id=1752849
Reviewed-By: Mohammad Rizwan Yusuf <myusuf@redhat.com>
Reviewed-By: Sumedh Sidhaye <ssidhaye@redhat.com>
Reviewed-By: Stanislav Levin <slev@altlinux.org>
Reviewed-By: Christian Heimes <cheimes@redhat.com>
