The way to using s4u2self in winbindd

Tue Aug 11 05:58:25 UTC 2020

Hi metze,

On Fri, Aug 7, 2020 at 2:17 PM Stefan Metzmacher via samba-technical
<samba-technical at lists.samba.org> wrote:
>
> As the work in the last month revealed that there're quite some
> missing features around S4U2Self in existing Kerberos libraries
> (Samba's (lorikeet-)Heimdal, Upstream Heimdal and Upstream MIT Kerberos)
> and it's harder than expected to fill the missing gaps, this proposes
> to start with the feature set that currently exists and prepare the
> infrastructure in Samba first. From there the remaining parts can
> be added as required.

If we are willing to do with what we have, then for basic local-realm
S4U2Self I think we have got what we need upstream, do you agree? it
would be nice to have something to aspire to, not pending upstream.

For MIT, i hope to cleanup the initial work soon (almost ready):
https://gitlab.com/samba-team/samba/-/merge_requests/818

> So far there are a few challenges, which prevented further
> imports in the past:
> - Samba's AD server testing relies on (and only exist of)
>   only a few smbtorture tests, which rely on the internal behavior
>   of Samba's Heimdal copy using the send_to_kdc hooks.
>
>   Heimdal's internals have changed in the meantime
>   and it's not trivial to adopt the torture tests
>   to the new. Given the little coverage these tests
>   have it's even more wasted time.
> - Importing new KDC code (with hidden behavior changes)
>   always brings the risk of breaking the AD DC case
>   with Windows clients (and other external clients).
>
> Recently Samba got a new framework for testing
> kerberos using python's pyasn1 and some crypto libraries.
> This enabled very exact tests for almost every
> bit in the protocol. The 'master-krb5-testing' branch
> already contains replacements for some of the smbtorture
> tests. These tests are developed against Windows KDCs
> and they reveal exactly the differences between Windows,
> Heimdal and MIT KDCs.
>
> Spending time on these new tests removes the
> blockers in two ways:
> - We no longer rely on send_to_kdc internals
> - We have more confidence to avoid hidden regressions
>   by updating the new KDC code.

Yeah, replacing the smbtorture tests with the new framework, is
definitely the way forward (and it also gives us the same level of
testing for MIT).

> [Task#03] Add S4U2Self protocol tests
>
> Given the new pyasn1 based kerberos testing infrastructure,
> we should develop tests, which are able to talk to multiple
> trusted domains. These tests should be able to decrypt
> all packets in the complex request chain to get an
> S4USelf ticket via trusted domain boundaries.
> It also needs to work out the behavior differences
> between the old PA_FOR_USER and the new PA_FOR_X509_USER
> versions of S4U2Self. The interaction with enterprise principals
> is also a very important aspect to test.

I think PA_FOR_X509_USER isn't a must, the only real advantage of
PA_FOR_X509_USER is that is uses the checksum of the tgt, instead of
hardcoded hmac-md5 (which is what heimdal does with PA_FOR_USER
incorrectly anyway, and gets along with it).

BTW we shouldn't implement PA_FOR_X509_USER for old enctypes in
Heimdal at all, we should use PA_FOR_USER only in that case, as
Windows clients do.

The PA_FOR_USER also works fine with enterprise principals, it
triggers client-referrals to locate its realm (although, names aren't
canonicalized either way).

> Together with a bit of research how Windows clients do
> S4U2Self, we should have enough information in order to
> implement the missing C code in the upstream Heimdal and
> MIT libraries.
>
> Windows 2012 and higher have an "Attempt S4U2Self o optain claim
> information" setting, maybe that can be used together with NTLMSSP
> to trigger S4U2Self from Windows.

The simplest is with powershell:
 `[Security.Principal/WindowsIdentity]::new('username at REALM.COM')`

I also wrote a tool once to test with certificate:
https://github.com/iboukris/S4U/blob/master/win/lsa.cpp

> [Task#04] Disable transited checking in gss_accept_sec_context()
> https://github.com/krb5/krb5/pull/1005
> https://github.com/heimdal/heimdal/pull/656
>
> When dealing with trusted active directory domains,
> it's currently needed that the user of gss_accept_sec_context(),
> which would also be used for S4U2Self in winbindd (via gensec_gssapi.c),
> would have the full trust topology defines in the [capaths] section
> of the used krb5.conf, because Windows KDCs don't set the
> transited-policy-checked flag, while they already checked
> policies and verified the ticket can be trusted.
> Also domain members servers in active directory are not
> supposed to know the topology, they should just trust
> the KDC of the primary domain.
> In order to accept kerberos authentication from trusted domain
> via S4U2Self (but also any other protocol), we need a way to
> disable the check in gss_accept_sec_context()
>
> The referenced pull requests for upstream MIT and Heimdal,
> contain working patches, which already come with testcases.
>
> But as these patches instrument the legacy gss_set_cred_option()
> call for the acceptor credentials passed to gss_accept_sec_context(),
> the changes are rejected for upstream inclusion to Heimdal.
>
> There's no agreed solution available for what to use
> instead of gss_set_cred_option().
>
> We should have the same interface for both Heimdal and MIT
> in order to avoid #ifdef's in Samba.
>
> There is most likely quite some time required to
> resolve the discussion.

Not sure it helps, but maybe we can try to suggest a simpler approach
for the time being, like a krb5.conf option..

> [Task#05] Implementing the missing S4U2Self features in upstream MIT
> https://github.com/krb5/krb5/pull/1014 (stepwise S4U interface)
> https://github.com/krb5/krb5/pull/1005 (NO_TRANSIT_CHECK)
>
> As outlined before Samba wants to use the krb5_{init,tkt}_creds_step()
> APIs, but in MIT (up to krb5-1.18) S4U2Self is not supported via
> these APIs. PR 1014 already has some of this implemented,
> but we should better wait for the outcome of the S4U2Self protocol tests
> in order to judge if this is feature complete and does everything
> Samba requires. It be very bad if we would need to handle even more
> combinations of half implemented features in Samba.

Actually S4U2Self was never supported in stepwise, what changed in
krb5-1.18 was that i broke the S4U2Proxy stepwise interface (for
RBCD). The hope is to get both fixed with PR 1014.

Thanks!