mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2024-12-23 15:40:01 -06:00
ae7cd4702d
Operations in FIPS mode make impossible use of NTLMSSP when authenticating to trusted Active Directory domain controllers because RC4 cipher is not allowed. Instead, Kerberos authentication have to be used. We switched to enforce Kerberos authentication when communicating with trusted domains' domain controllers everywhere. Kerberos library uses system wide configuration which in IPA defaults to resolving location of KDCs via DNS SRV records. Once trust is established, SSSD will populate a list of closest DCs and provide them through the KDC locator plugin. But at the time the trust is established performing DNS SRV-based discovery of Kerberos KDCs might fail due to multiple reasons. It might also succeed but point to a DC that doesn't know about the account we have to use to establish trust. One edge case is when DNS SRV record points to an unreachable DC, whether due to a firewall or a network topology limitations. In such case an administrator would pass --server <server> option to 'ipa trust-add' or 'ipa trust-fetch-domains' commands. 'ipa trust-fetch-domains' runs a helper via oddjobd. This helper was already modified to support --server option and generated custom krb5.conf overlay to pin to a specific AD DC. However, this configuration was removed as soon as we finished talking to AD DCs. With switch to always use Kebreros to authenticate in retrieval of the topology information, we have to use the overlay everywhere as well. Convert the code that generated the overlay file into a context that generates the overlay and sets environment. Reuse it in other trust-related places where this matters. Oddjob helper runs as root and can write to /run/ipa for the krb5.conf overlay. Server side of 'ipa trust-add' code calls into ipaserver/dcerpc.py and runs under ipaapi so can only write to /tmp. Since it is a part of the Apache instance, it uses private /tmp mounted on tmpfs. Fixes: https://pagure.io/freeipa/issue/8664 Related: https://pagure.io/freeipa/issue/8655 Signed-off-by: Alexander Bokovoy <abokovoy@redhat.com> Reviewed-By: Christian Heimes <cheimes@redhat.com> Reviewed-By: Rob Crittenden <rcritten@redhat.com> |
||
|---|---|---|
| .. | ||
| certmonger | ||
| custodia | ||
| html | ||
| migration | ||
| oddjob | ||
| restart_scripts | ||
| share | ||
| tools | ||
| ui | ||
| updates | ||
| wsgi | ||
| Makefile.am | ||
| README.schema | ||
Ground rules on adding new schema Brand new schema, particularly when written specifically for IPA, should be added in share/*.ldif. Any new files need to be explicitly loaded in ipaserver/install/dsinstance.py. These simply get copied directly into the new instance schema directory. Existing schema (e.g. in an LDAP draft) may either be added as a separate ldif in share or as an update in the updates directory. The advantage of adding the schema as an update is if 389-ds ever adds the schema then the installation won't fail due to existing schema failing to load during bootstrap. If the new schema requires a new container then this should be added to install/bootstrap-template.ldif.