Bug 1749786

Note that enabling FAST might not be enough. The referenced article suggests to enable a policy to require claims at Windows systems. Claims (CBAC) is a special extension of MS-KILE that requires FAST to be enabled but also adds a lot more into MS-PAC structure.

MIT Kerberos (and Heimdal) do not implement CBAC extensions of MS-KILE. Thus, even if FAST is in use, it might be not enough.

Additionally, a special flag has to be set on a trust between IdM and AD forests to denote that FAST is available. There is a separate flag for CBAC availability.

MIT Kerberos supports FAST, but MIT Kerberos needs to be adapted. The KDB plugins doesn't have information required to validate the packets correctly.

Andreas, can you elaborate on what's needed (when you know)?  Alternately, if you want to do the work, that's of course fine too :)

Hi,

this can most probably not be solved on the SSSD side alone but needs support in libkrb5 as well, as discussion in https://github.com/krb5/krb5/pull/1131.

bye,
Sumit

*** Bug 1826645 has been marked as a duplicate of this bug. ***

I'm curious to know if there's been any progress here.  It seems as though https://github.com/krb5/krb5/pull/1131 was meant to correct this was back in Dec.

(In reply to Alex Mayberry from comment #12)
> I'm curious to know if there's been any progress here.  It seems as though
> https://github.com/krb5/krb5/pull/1131 was meant to correct this was back in
> Dec.

Hi,

my current tests indicate that it is sufficient to have a two-way trust between the involved domains to make authentication in SSSD work if FAST is enabled. But I'm waiting for further feedback before closing this ticket.

HTH

bye,
Sumit

Hi,

please find below a draft version of a section which can de added to the IdM documentation about setting up trust with AD.

HTH

bye,
Sumit

Kerberos armoring enabled in Active Directory

Since Windows 2012 Active Directory supports a feature typically called
"Kerberos armoring" in Active Directory documentation. On the IdM side the
feature is also called "Kerberos Flexible Authentication Secure Tunneling" or
in short "FAST".

FAST is enabled in the IdM domain by default and provides additional
protection for the Kerberos communication between the IdM clients and the KDCs
running on the IdM servers. It is even a requirement for IdM's
Two-Factor-Authentication feature.

In Active Directory Kerberos armoring is not enabled by default. It is a
requirement for another Active Directory feature called "compound
authentication" and can be enabled on the Domain Controllers with the same
group policy setting:

    - Computer Configuration
        - Policies
            - Administrative Templates
                - System
                    - KDC
                        - KDC support for claims, compound authentication, and Kerberos armoring.

The policy setting allows the following options "Not supported", "Supported",
"Always provide claims" and "Fail unarmored authentication requests". See
https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/ad-fs-compound-authentication-and-ad-ds-claims
for details

IdM clients can either be configured to use FAST for all trusted domains which
advertise FAST or to not use FAST at all. If FAST (Kerberos armoring) is
enabled in the trusted Active Directory forest the IdM client will try to use
FAST by default. To be able to establish "Secure Tunneling" cryptographic
keys from already available Kerberos Ticket Granting Tickets (TGTs) are used.
Those tickets and keys are only valid inside a single domain (Kerberos realm)
and to be able to protect a connection to the Domain Controllers of a trusted
domain a cross-realm TGT must be requested. At this point there are no tickets
from the trusted Active Directory domain available because the FAST tunnel 
should be established to protect the authentication request of an Active 
Directory user. This means that the cross-realm TGT for the Active Directory 
domain has to be request with credentials from the IdM domain. And this can 
only work if the Active Directory forest trusts the IdM domain, i.e. the trust
between the two domains is a two-way trust.

By default 'ipa trust-add' will create a one-way trust where only the IdM 
domain trusts the domains from the Active Directory forest. To enabled two-way
trust the existing trust must be remove and re-created with the 
'--two-way=True' option. [[QUESTION FOR IDM DEVELOPERS: this operation might 
be a bit tricky/risky for production environments, shall we really mention it
here? Would it be possible to add an option of 'ipa trust-mod', I guess AD 
admin credentials might be needed as well to update the TDO on the AD side.]]

If using a two-way trust is not possible FAST must be disabled on all IdM
clients which should offer password based authentication or direct Smartcard
authentication at the IdM client for users from the trusted Active Directory
forest by setting

    krb5_use_fast = never

in the [domain/...] section of sssd.conf. Please note, this is not needed if
only authentication based on ssh-keys, GSSAPI authentication or ssh with
Smartcards from a remote Windows clients is used. In those cases FAST is not
used during authentication because the IdM client does not have to communicate
with a Domain Controller. Additionally please note that disabling FAST on the
IdM client will disable the two-factor authentication IdM feature on this
client as well.

Thanks, Sumit.

It looks good (barring few typos). To answer your questions, I think we could re-formulate the paragraph 'By default "ipa trust-add" ...' to show first what you have in the last paragraph. Then add something along the following lines:

---------------
If enforcing FAST use is required by Active Directory policies, a trust between RHEL IdM
domain and Active Directory forest should be made two-way. This has to be planned at
the time when trust is established since information about direction and type of trust
has to be recorded on both RHEL IdM and Active Directory sides.

In case there is already one-way trust established, re-running 'ipa trust-add ... --two-way=true'
will remove existing trust agreement and re-create it. Thus, this requires use of 
the administrative credentials. Since RHEL IdM will attempt to remove existing trust agreement
from the Active Directory side, permissions of Enterprise Admins are required here for Active Directory
access.

If original trust was established with the use of a shared secret rather than an Active Directory 
administrative account, re-creating the trust as two-way one will only change trusted domain objects 
on RHEL IdM side. Windows administrators would need to repeat the same procedure using Windows UI 
and make sure a bi-directional trust is chosen as well and the same shared secret was used 
to re-create the trust.
---------------

Documentation piece was published: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/planning_identity_management/index#con_kerberos-fast-for-trusted-domains_planning-a-cross-forest-trust-between-idm-and-ad