The subsystem.select is not a reliable indicator to determine
whether the CA is a renewal master since there is no process in
PKI to update the param when the role of the instance changes
(from master to clone and vice versa) so the param has been
removed in PKI 11.5.
Instead, it's better to use CAInstance.is_crlgen_enabled() since
CRL generation is only enabled in a renewal master.
Signed-off-by: Endi Sukma Dewata <edewata@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
Currently LWCA is only supported in IPA since the key
replication depends on Custodia, so LWCA is not actually
supported in regular PKI installation. However, currently
the AuthorityMonitor is enabled by default and it executes
a persistent search to monitor LWCA replication so it is
wasting resources in non-IPA environment.
To reduce unnecessary resource consumption the LWCA monitor
will be disabled by default in PKI, so IPA will need to
enable it explicitly for new and existing installations.
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The replica install was unilaterally removing KRB5CCNAME from
os.environ in some cases. Instead check first to see if it is
present and only remove in that case.
Fixes: https://pagure.io/freeipa/issue/9446
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
389DS supports BDB and LMDB backends. FreeIPA installation fails with
LMDB backend since it tries to apply tuning for BDB backend.
Instead, tuning for BDB should be applied only when 389DS uses BDB
backend.
Fixes: https://pagure.io/freeipa/issue/9435
Signed-off-by: Viktor Ashirov <vashirov@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Write a new krb5.conf in case any values changed finding the
right server to configure against (e.g. for CA, KRA) and
ensure the API connection is to the remote server that
will be installed against.
When finding a CA or KRA during initial replica installation
set the remote master as well. The order is:
- existing server value in /etc/ipa/default.conf
- the chosen CA host if the server doesn't provide one
- the chosen KRA host if the server doesn't provide one
This is more or less heirarchical. If a server is provided
then that is considered first. If it provides all the
optional services needed (CA and/or KRA) then it will
be used. Otherwise it will fall back to a server that provides
all the required services.
In short, providing --server either at client install or
with ipa-replica-install is no guarantee that it will
define all topology. This may be unexpected behavior.
For the case of adding a CA or KRA things are effectively
unchanged. This type of install does not appear to be
impacted by affinity issues.
Fixes: https://pagure.io/freeipa/issue/9289
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Clean up and remove obsolete code from ipa-replica-install. For several
versions replica installer first ensures that a host is an IPA client,
then promotes the client to a replica. The client installer code sets up
CA stores like IPA_CA_CRT already.
Related: https://pagure.io/freeipa/issue/9272
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Rafael Guterres Jeffman <rjeffman@redhat.com>
Reviewed-By: Thomas Woerner <twoerner@redhat.com>
ipa-server-guard reads a lock file in order to
check if the lock is still taken by comparing
the stored value, for instance:
expire = 20230810155452589311
with the current datetime.
The expire value needs to be timezone-aware in
order to be compared with "now" which is also tz aware.
Related: https://pagure.io/freeipa/issue/9425
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
ipa-cert-fix compares the current datetime with the
value obtained from a cert.not_valid_after.
With the fix for #9425, not_valid_after is timezone
aware and cannot be compared to a naive datetime.
Make the datetime "now" timezone aware.
Related: https://pagure.io/freeipa/issue/9425
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The following warning is displayed on a system running with Python 3.12:
-------------------
/usr/lib/python3.12/site-packages/ipalib/rpc.py:925: DeprecationWarning:
datetime.utcnow() is deprecated and scheduled for removal in a future
version. Use timezone-aware objects to represent datetimes in UTC:
datetime.now(datetime.UTC).
timestamp=datetime.datetime.utcnow())
-------------------
Fixes: https://pagure.io/freeipa/issue/9425
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
In order to know if ca/kra is installed locally, the code
is calling pki-server subsystem-show _subsystem_
and ensures that "Enabled: True" is in the output.
If a subsystem fails to start, the command returns
"Enabled: False" but it doesn't mean that the subsystem
is not installed, it just means that it is not active
right now.
Same output if the subsystem has been disabled with
pki-server subsystem-disable _subsystem_.
The correct way to check if a subsystem is installed is to
ensure that subsystem-show does not exit on error and
contains "Enabled: ", whatever the value.
Related: https://pagure.io/freeipa/issue/9330
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
The uninstaller is stopping all the services before
calling pkidestroy to uninstall the CA.
With PKI 11.4+ this sequence fails as pkidestroy tries
to connect to PKI server in order to unregister from the
security domain. The error interrupts the full completion
of pkidestroy, is logged but doesn't make ipa uninstallation
fail.
The issue is that trying to re-install later on would fail because
pkidestroy did not completely uninstall the CA.
To avoid this, call pkidestroy before shutting down the services.
Also add an uninstall_check method that restarts IPA if it is
not running, and use pkidestroy --force to make sure that PKI
is uninstalled even if restart failed.
Fixes: https://pagure.io/freeipa/issue/9330
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
The upgrade checks the replication agreements to ensure that
some attributes are excluded from replication. The agreements
are stored in entries like
cn=serverToreplica,cn=replica,cn=_suffix_,cn=mapping tree,cn=config
but those entries are managed by the replication topology plugin
and should not be updated directly. The consequence is that the update
of the attributes fails and ipa-server-update prints an error message:
Error caught updating nsDS5ReplicatedAttributeList: Server is unwilling
to perform: Entry and attributes are managed by topology plugin.No direct
modifications allowed.
Error caught updating nsDS5ReplicatedAttributeListTotal: Server is
unwilling to perform: Entry and attributes are managed by topology
plugin.No direct modifications allowed.
The upgrade continues but the replication is not excluding
passwordgraceusertime.
Instead of editing the agreements, perform the modifications on
the topology segments.
Fixes: https://pagure.io/freeipa/issue/9385
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
During the installation of IPA server, the installer adds a drop-in
file in /etc/systemd/system/pki-tomcatd@pki-tomcat.service.d/ipa.conf
that ensures the CA is reachable before the start command returns.
If the file is missing (for instance because the server was installed
with an old version before this drop-in was created), the upgrade
should add the file.
Fixes: https://pagure.io/freeipa/issue/9381
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Without this the installation is successful but the DNS
records will not work. With --setup-dns there will be no
A record for the host (only an NS record) and the PTR record
will point to the domain name.
Fixes: https://pagure.io/freeipa/issue/9003
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Since November 2020, Active Directory KDC generates a new type of
signature as part of the PAC. It is called "ticket signature", and is
generated based on the encrypted part of the ticket. The presence of
this signature is not mandatory in order for the PAC to be accepted for
S4U requests.
However, the behavior is different for MIT krb5. Support was added as
part of the 1.20 release, and this signature is required in order to
process S4U requests. Contrary to the PAC extended KDC signature, the
code generating this signature cannot be isolated and backported to
older krb5 versions because this version of the KDB API does not allow
passing the content of the ticket's encrypted part to IPA.
This is an issue in gradual upgrade scenarios where some IPA servers
rely on 1.19 and older versions of MIT krb5, while others use version
1.20 or newer. A service ticket that was provided by 1.19- IPA KDC will
be rejected when used by a service against a 1.20+ IPA KDC for S4U
requests.
On Fedora, CentOS 9 Stream, and RHEL 9, when the krb5 version is 1.20 or
newer, it will include a downstream-only update adding the
"optional_pac_tkt_chksum" KDB string attribute allowing to tolerate the
absence of PAC ticket signatures, if necessary.
This commit adds an extra step during the installation and update
processes where it adds a "pacTktSignSupported" ipaConfigString
attribute in "cn=KDC,cn=[server],cn=masters,cn=ipa,cn=etc,[basedn]" if
the MIT krb5 version IPA what built with was 1.20 or newer.
This commit also set "optional_pac_tkt_chksum" as a virtual KDB entry
attribute. This means the value of the attribute is not actually stored
in the database (to avoid race conditions), but its value is determined
at the KDC starting time by search the "pacTktSignSupported"
ipaConfigString in the server list. If this value is missing for at
least of them is missing, enforcement of the PAC ticket signature is
disabled by setting "optional_pac_tkt_chksum" to true for the local
realm TGS KDB entry.
For foreign realm TGS KDB entries, the "optional_pac_tkt_chksum" virtual
string attribute is set to true systematically, because, at least for
now, trusted AD domains can still have PAC ticket signature support
disabled.
Given the fact the "pacTktSignSupported" ipaConfigString for a single
server is added when this server is updated, and that the value of
"optional_pac_tkt_chksum" is determined at KDC starting time based on
the ipaConfigString attributes of all the KDCs in the domain, this
requires to restart all the KDCs in the domain after all IPA servers
were updated in order for PAC ticket signature enforcement to actually
take effect.
Fixes: https://pagure.io/freeipa/issue/9371
Signed-off-by: Julien Rische <jrische@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
DS does not enable plugins unless nsslapd-dynamic-plugins is enabled or
DS is restarted. The DNA plugin creates its configuration entries with
some delay after the plugin is enabled.
DS is now restarted after the DNA plugin is enabled so it can create the
entries while Dogtag and the rest of the system is installing. The
updater `update_dna_shared_config` no longer blocks and waits for two
times 60 seconds for `posix-ids` and `subordinate-ids`.
Fixes: https://pagure.io/freeipa/issue/9358
Signed-off-by: Christian Heimes <cheimes@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Replace comparisons of "if value" with "if value is not None"
in order to handle 0.
Add a short reference to the man page to indicat that a cert
or request retention time of 0 means remove at the next
execution.
Also indicate that the search time limit is in seconds.
Fixes: https://pagure.io/freeipa/issue/9325
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Francisco Trivino <ftrivino@redhat.com>
Configures PKI to remove expired certificates and non-resolved
requests on a schedule.
This is geared towards ACME which can generate a lot of certificates
over a short period of time but is general purpose. It lives in
ipa-acme-manage because that is the primary reason for including it.
Random Serial Numbers v3 must be enabled for this to work.
Enabling pruning enables the job scheduler within CS and sets the
job user as the IPA RA user which has full rights to certificates
and requests.
Disabling pruning does not disable the job scheduler because the
tool is stateless. Having the scheduler enabled should not be a
problem.
A restart of PKI is required to apply any changes. This tool forks
out to pki-server which does direct writes to CS.cfg. It might
be easier to use our own tooling for this but this makes the
integration tighter so we pick up any improvements in PKI.
The "cron" setting is quite limited, taking only integer values
and *. It does not accept ranges, either - or /.
No error checking is done in PKI when setting a value, only when
attempting to use it, so some rudimentary validation is done.
Fixes: https://pagure.io/freeipa/issue/9294
Signed-off-by: Rob Crittenden rcritten@redhat.com
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The installer is currently creating the samba domain object
before it adds the RID base and secondary RID base. As a consequence,
there is a window during which the sidgen plugin is active but
unable to generate SIDs (it requires the samba domain object to
find the domain SID and RID base to know where to start from).
There is no direct impact except the error log of 389ds that reports
ERR - get_ranges - [file ipa_sidgen_common.c, line 276]: Failed to convert LDAP entry to range struct.
This fix configures the RID base and secondary RID base before the
domain object is created, thus removing this window.
Fixes: https://pagure.io/freeipa/issue/9309
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
> Emitted when a local variable is accessed before its assignment took
place. Assignments in try blocks are assumed not to have occurred when
evaluating associated except/finally blocks. Assignments in except
blocks are assumed not to have occurred when evaluating statements
outside the block, except when the associated try block contains a
return statement.
Fixes: https://pagure.io/freeipa/issue/9278
Signed-off-by: Stanislav Levin <slev@altlinux.org>
Reviewed-By: Stanislav Levin <slev@altlinux.org>
The newer version of pylint has fixed false positives and
does not need anymore these suppressions:
- global-variable-not-assigned
- invalid-sequence-index
- no-name-in-module
- not-callable
- unsupported-assignment-operation
Related: https://pagure.io/freeipa/issue/9278
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Stanislav Levin <slev@altlinux.org>
The config file /var/kerberos/krb5kdc/kdc.conf is customized
during IPA server installation with a list of supported
encryption types.
In FIPS mode, camellia encryption is not supported and should
be filtered out. Because of a typo in the filtering method,
the camellia encryptions are appended while they should not.
Fix the typo (camelia vs camellia) in order to filter properly.
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The PKCS12 MAC requires PKCS12KDF which is not an approved FIPS
algorithm and cannot be supported by the FIPS provider.
Do not require mac verification in FIPS mode: append the option
--nomacver to the command openssl pkcs12 used to extract a pem file
or a key from a p12 file.
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
The IPA location system relies on DNS record priorities in order to give
higher precedence to servers from the same location. For Kerberos, this
is done by redirecting generic SRV records (e.g.
_kerberos._udp.[domain].) to location-aware records (e.g.
_kerberos._udp.[location]._locations.[domain].) using CNAMEs.
This commit applies the same logic for URI records. URI location-aware
record were created, but there were no redirection from generic URI
records. It was causing them to be ignored in practice.
Kerberos URI and TXT records have the same name: "_kerberos". However,
CNAME records cannot coexist with any other record type. To avoid this
conflict, the generic TXT realm record was replaced by location-aware
records, even if the content of these records is the same for all
locations.
Fixes: https://pagure.io/freeipa/issue/9257
Signed-off-by: Julien Rische <jrische@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
The default ID generators used by PKI might change in the
future, so to preserve the current behavior the installation
code has been updated to explicitly use the legacy ID
generators by default.
Signed-off-by: Endi S. Dewata <edewata@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
ipa-cacert-manage prune is removing the expired certs one
at a time and this may result in verifying that one of
the expired certs is still valid.
As a consequence, ipa-cacert-manage prune always fails
when more than 1 cert are expired.
To avoid the issue, remove all the expired certs in a single
pass, and validate only the ones that would remain after full
pruning.
Fixes: https://pagure.io/freeipa/issue/9244
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
There are currently three sets of CA schema changes applied
in ipa-server-upgrade:
* addition of ACME schema
* addition of certificate profile schema
* addition of lightweight CA schema
None of these require a restart of the CA to be supported.
There is an issue in schema parsing such that it doesn't handle
X-ORIGIN properly. A difference is detected and a change applied
but no change is recorded in LDAP so every time upgrade is
run it thinks a CA restart is needed. The CA is not quick to
restart so avoiding one is best, particularly when the update is
run as part of an rpm transaction where a user with an itchy finger
may think things have hung and break out of it.
https://github.com/389ds/389-ds-base/issues/5366 was
filed to track this.
Related: https://pagure.io/freeipa/issue/9204
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
In the memory check failure message, add a hint to the administrator
that they can use the --skip-mem-check flag to skip the check.
Related: https://pagure.io/freeipa/issue/8404
Signed-off-by: Fraser Tweedale <frase@frase.id.au>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
PKI 10.10 unconditionally added an upgrade script for the AJP
connector which replaced the AJP secret regardless of tomcat
version. It replaced requiredSecret with secret. IPA expects
the attribute by version so this could make the secrets out of
date and/or have connectors with both secrets and different
values.
PKI commit e70373ab131aba810f318c1d917896392b49ff4b has since
been reverted but there may be servers with both secrets still.
On next IPA upgrade clean them up.
Also allow re-writing ipa-pki-proxy.conf in case the secret
changes to ensure they remain in sync.
Fixes: https://pagure.io/freeipa/issue/9176
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
nsds5replicaUpdateInProgress is defined in LDAP schema as a boolean.
Now that IPA API is able to properly map booleans to the python
bool type, this attribute is not a string any more and
comparisons can be done directly based on its real type.
The code in ipa-replica-install was reading nsds5replicaUpdateInProgress
and calling value.tolower() == 'true' but should now use
value == True instead.
Related: https://pagure.io/freeipa/issue/9171
Signed-off-by: Florence Blanc-Renaud <flo@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
In IPA framework we don't properly convert to Python bool type and just
return a string (TRUE or FALSE). This can be seen with many boolean
attributes, like
Bool('idnsallowdynupdate?',
cli_name='dynamic_update',
label=_('Dynamic update'),
doc=_('Allow dynamic updates.'),
attribute=True,
default=False,
autofill=True
),
in 'ipa dnszone-show':
> > > api.Command.dnszone_show('ipa.test')['result']['idnsallowdynupdate']
['TRUE']
This is because we don't have the reverse (from LDAP to Python) mapping
for the LDAP boolean OID 1.3.6.1.4.1.1466.115.121.1.7.
When Web UI asks for the entry, it gets back JSON output that contains
this 'TRUE' value:
"idnsallowdynupdate": [
"TRUE"
],
Add proper mapping from LDAP to Python bool type. With this, a simple
'checkbox' type can be used in Web UI instead of a complex radio-box
setup.
Note that when IPA API is asked to return raw values, 'TRUE' and 'FALSE'
still returned. These are the actual LDAP boolean attribute values. Care
needs to be done in tests:
- if output is from a command with --raw option, 'TRUE' or 'FALSE'
should be expected
- if output if from a normal (non-raw) command, True or False would be
returned
Fixes: https://pagure.io/freeipa/issue/9171
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Florence Blanc-Renaud <flo@redhat.com>
The graceperiod plugin was only being enabled on new
installations. Enable also on upgrade.
Loading a new plugin requires a restart. Do so if a
new one is configured.
Fixes: https://pagure.io/freeipa/issue/1539
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Florence Blanc-Renaud <frenaud@redhat.com>
Add support for bind grace limiting per
https://datatracker.ietf.org/doc/html/draft-behera-ldap-password-policy-06
389-ds provides for alternative naming than the draft, using those
instead: passwordGraceUserTime for pwdGraceUserTime and
passwordGraceLimit for pwdGraceLoginLimit.
passwordGraceLimit is a policy variable that an administrator
sets to determine the maximum number of LDAP binds allowed when
a password is marked as expired. This is suported for both the
global and per-group password policies.
passwordGraceUserTime is a count per-user of the number of binds.
When the passwordGraceUserTime exceeds the passwordGraceLimit then
all subsequent binds will be denied and an administrator will need
to reset the user password.
If passwordGraceLimit is less than 0 then grace limiting is disabled
and unlimited binds are allowed.
Grace login limitations only apply to entries with the objectclass
posixAccount or simplesecurityobject in order to limit this to
IPA users and system accounts.
Some basic support for the LDAP ppolicy control is enabled such that
if the ppolicy control is in the bind request then the number of
remaining grace binds will be returned with the request.
The passwordGraceUserTime attribute is reset to 0 upon a password
reset.
user-status has been extended to display the number of grace binds
which is stored centrally and not per-server.
Note that passwordGraceUserTime is an operational attribute.
https://pagure.io/freeipa/issue/1539
Signed-off-by: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Add the --subid option to client, server and replica installers.
This option allows to configure authselect with the sssd
profile + with-subid feature, in order to have SSSD setup as
a datasource for subid in /etc/nsswitch.conf.
The default behavior remains unchanged: without the option,
/etc/nsswitch.conf keeps the line subid: files
Fixes: https://pagure.io/freeipa/issue/9159
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
So that it prints out a valid command:
- replace "ipa-replica-manage del" by "ipa server-del" (only domain-level1 is now supported)
- the commands needs to be run on a working server, not on the host where ipa-replica-install failed
Fixes: https://pagure.io/freeipa/issue/9162
Reviewed-By: Michal Polovka <mpolovka@redhat.com>
KDC configuration in /var/kerberos/krb5kdc/kdc.conf is generated from
the template in install/share/kdc.conf.template. Master key encryption
type specified there is used to bootstrap the master key in LDAP
database. Once it is done, actual deployment does not rely on the
master_key_type value anymore. The actual master key(s) get loaded from
LDAP database where they stored in a BER-encoded format, preserving all
parameters, including encryption type.
This means we can safely migrate to AES256-SHA2 as the default master
key encryption type for new installations. Replicas will get their
master key encryption type details from the server they were provisioned
from.
MIT Kerberos supports AES256-SHA2 since 1.15 (2015), meaning RHEL 7.4 is
the earliest supported version as it provides krb5 1.15.1. Current
supported RHEL 7 version is RHEL 7.9. Since RHEL 6 already cannot be
used as a replica to IPA 4.5+ due to a domain level 1 upgrade, this
change does not affect old releases.
Migration from the previously deployed master key encryption type is
described by MIT Kerberos upstream in
http://web.mit.edu/kerberos/krb5-latest/doc/admin/advanced/retiring-des.html#the-database-master-key
One would need to use '-x ipa-setup-override-restrictions' to allow
the `kdb5_util` utility to modify the data over IPA KDB driver.
Fixes: https://pagure.io/freeipa/issue/9119
Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Francisco Trivino <ftrivino@redhat.com>