Bug 12554 - The kerberos client should not only rely on automatic cross-realm referrals
The kerberos client should not only rely on automatic cross-realm referrals
Status: RESOLVED FIXED
Product: Samba 4.1 and newer
Classification: Unclassified
Component: Winbind
4.6.0rc1
All All
: P5 normal
: 4.6
Assigned To: Karolin Seeger
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-02-01 16:01 UTC by Stefan Metzmacher
Modified: 2017-03-23 11:15 UTC (History)
6 users (show)

See Also:


Attachments
patch for 4.6 (58.51 KB, patch)
2017-03-14 08:57 UTC, Andreas Schneider
metze: review-
Details
patch for 4.6 v2 (57.44 KB, patch)
2017-03-14 09:57 UTC, Andreas Schneider
metze: review+
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Metzmacher 2017-02-01 16:01:48 UTC
This is the client side of bug #12553.

We may need to fallback to
cifs/dc.otherdomain.com@OTHERDOMAIN.COM if
our KDC returns PRINCIPAL_UNKNOWN for
cifs/dc.otherdomain.com@MYDOMAIN.COM.

In winbindd we should use the trust information of
netr_LogonGetDomainInfo().
Comment 1 Stefan Metzmacher 2017-03-02 14:29:04 UTC
It seems that the users of source3/librpc/crypto/gse.c handle this fine,
if heimdal is used. In that case smb_krb5_get_principal_from_service_hostname()
selects the target realm based on the host's dnsname by removing the hostname
part.

Internally _krb5_get_cred_kdc_any() tries get_cred_kdc_referral()
first, which replaces the realm with the realm of the client principal
in order to get automatic forest trust referrals. If that fails
(typically with S_PRINCIPAL_UNKNOWN, if it's an external trust)
it falls back to get_cred_kdc_capath() which tries the original
dnshostname based realm and asks for an explicit referral ticket
from the clients kdc.

With MIT smb_krb5_get_principal_from_service_hostname() uses
the passed default realm (the one from the client principal)
unless a [domain_realm] is explicitly configured in krb5.conf.

Internally MIT only tries the given target principal and returns
without a possible fallback. For all cases except the winbindd use case
this behavior hasn't changed since 4.5, but for the winbindd case
we now fallback to NTLMSSP, when accessing a dc of an external trust.
Comment 2 Stefan Metzmacher 2017-03-02 14:31:16 UTC
(In reply to Stefan Metzmacher from comment #1)

I guess the best approach would be to get the credentials with
raw krb5 functions before calling gss_init_sec_context(),
so that we can control possible fallbacks in our code.
Comment 3 Karolin Seeger 2017-03-06 08:27:25 UTC
Is this a blocker for 4.6.0?
Comment 4 Andreas Schneider 2017-03-06 09:42:17 UTC
Ask metze, patches for master are here (including tests): https://git.samba.org/?p=asn/samba.git;a=shortlog;h=refs/heads/master-trusts
Comment 5 Stefan Metzmacher 2017-03-06 14:38:43 UTC
(In reply to Karolin Seeger from comment #3)

As the behavior change is only happens if all of the following statements are true:

- use within winbindd
- only external (non-forest) trusts to AD domain
- only with MIT krb5

and we do a proper fallback to NTLMSSP in that case.

I don't think it's still a blocker.

We can think about a possible fix for the first
4.6 maintenance release.
Comment 6 Andreas Schneider 2017-03-14 08:57:50 UTC
Created attachment 13052 [details]
patch for 4.6
Comment 7 Andreas Schneider 2017-03-14 08:59:29 UTC
I need the first patch to be able to compile source3/lib/system.c ...
Comment 8 Stefan Metzmacher 2017-03-14 09:39:04 UTC
Comment on attachment 13052 [details]
patch for 4.6

I think we should have a separate bug report for the libreplace patch,
so people can find the bug report.
Comment 9 Andreas Schneider 2017-03-14 09:57:48 UTC
Created attachment 13054 [details]
patch for 4.6 v2
Comment 10 Andreas Schneider 2017-03-14 09:58:19 UTC
#12686 is the bug for the build issue.
Comment 11 Karolin Seeger 2017-03-14 11:19:15 UTC
Pushed to autobuild-v4-6-test.
Comment 12 Karolin Seeger 2017-03-23 11:15:08 UTC
Pushed to v4-6-test.
Closing out bug report.

Thanks!