Adding proper error handling to the is_master_host() function to allow
it to make the difference between the absence of a master host object
and a connection failure. This will keep the krb5kdc daemon from
continuing to run with a NULL LDAP context.
Fixes: https://pagure.io/freeipa/issue/9422
Signed-off-by: Julien Rische <jrische@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Commit f78dc0b163 was missing an exception for the constrained
delegation ACL TL data type during the principal entry update operation.
This ACL is not meant to be stored as encoded data in krbExtraData.
Signed-off-by: Julien Rische <jrische@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@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>
In November 2022, Microsoft introduced a new PAC signature type called
"extended KDC signature" (or "full PAC checksum"). This new PAC
signature will be required by default by Active Directory in July 2023
for S4U requests, and opt-out will no longer be possible after October
2023.
Support for this new signature type was added to MIT krb5, but it relies
on the new KDB API introduced in krb5 1.20. For older MIT krb5 versions,
the code generating extended KDC signatures cannot be backported as it
is without backporting the full new KDB API code too. This would have
too much impact to be done.
As a consequence, krb5 packages for Fedora 37, CentOS 8 Stream, and RHEL
8 will include a downstream-only update adding the
krb5_pac_full_sign_compat() function, which can be used in combination
with the prior to 1.20 KDB API to generate PAC extended KDC signatures.
Fixes: https://pagure.io/freeipa/issue/9373
Signed-off-by: Julien Rische <jrische@redhat.com>
Reviewed-By: Rob Crittenden <rcritten@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>
Since 5d51ae5, principal keys were dropped in case user auth indicator
was not including password. Thereafter, the key removal behavior was
removed by 15ff9c8 in the context of the kdcpolicy plugin introduction.
Support for hardened pre-auth methods (FAST and SPAKE) was added in
d057040, and the removal of principal keys was restored afterwards by
f0d12b7, but not taking the new hardened auth indicator into account.
Fixes: https://pagure.io/freeipa/issue/9065
Related to: https://pagure.io/freeipa/issue/8001
Signed-off-by: Julien Rische <jrische@redhat.com>
Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com>
Reviewed-By: Francisco Trivino <ftrivino@redhat.com>
Julien Rische