One way trusts...

[Stefan (metze) Metzmacher]

Am 18.12.2014 um 22:53 schrieb Andrew Bartlett:
> On Tue, 2014-12-16 at 12:05 +0100, Stefan (metze) Metzmacher wrote:
>> Am 16.12.2014 um 12:03 schrieb Andreas Schneider:
>>> On Tuesday 16 December 2014 10:53:03 Stefan  Metzmacher wrote:
>>>> Hi Andrew,
>>>>
>>>> I'm currently testing our winbindd code (in v4-2-test/master)
>>>> with one way trusts. From our point the trust is outgoing only.
>>>> So we have a trust account S4xDOM$ in domain W2012R2-L4.BASE in the
>>>> other domain.
>>>>
>>>> The Samba DC is called ub1204-161 (we also have ub1204-160).
>>>> The Windows DC is called w2012r2-183.
>>>>
>>>> The current bahavior is that we just fail to get the cross-realm
>>>> TGT, see s4xdom-161-v4-2-w2012r2-l4-one-way-krb5-machine-fail-01.pcap.gz
>>>> frames 68/69.
>>>>
>>>> With the following hack:
>>>>
>>>> --- a/source3/winbindd/winbindd_cm.c
>>>> +++ b/source3/winbindd/winbindd_cm.c
>>>> @@ -905,6 +905,10 @@ static NTSTATUS get_trust_credentials(struct
>>>> winbindd_domain *domain,
>>>>
>>>>         /* If we are a DC and this is not our own domain */
>>>>
>>>> +       if (domain->active_directory) {
>>>> +       netlogon = true;
>>>> +       }
>>>> +
>>>>         if (IS_DC && netlogon) {
>>>>                 creds_domain = domain;
>>>>         } else {
>>>>
>>>> we get a TGT as S4xDOM$@W2012R2-L4.BASE and everything works fine,
>>>> see s4xdom-161-v4-2-w2012r2-l4-one-way-krb5-trust-ok-01.pcap.gz
>>>> frames 42/43 and 57/58 followed by a SMB2 session setup in 64/66.
>>>>
>>>> With the following addtitional hack to force ntlmssp:
>>>>
>>>> @@ -934,6 +938,8 @@ static NTSTATUS get_trust_credentials(struct
>>>> winbindd_domain *domain,
>>>>                 cli_credentials_set_kerberos_state(creds,
>>>>                                                    CRED_DONT_USE_KERBEROS);
>>>>         }
>>>> +             cli_credentials_set_kerberos_state(creds,
>>>> +                                                CRED_DONT_USE_KERBEROS);
>>>>
>>>>         if (creds_domain != domain) {
>>>>                 /*
>>>>
>>>> we fail in the session setup, which is the case you want to avoid by using
>>>> the machine account instead of the trust account.
>>>> See s4xdom-161-v4-2-w2012r2-l4-one-way-ntlmssp-trust-fail-01.pcap.gz in
>>>> frame 24.
>>>>
>>>> I think for active directory domains we should always use krb5 with the
>>>> trust account
>>>> and for non ad domains we use the machine account if the trust is also
>>>> incoming
>>>> otherwise use fallback to anonymous.
>>>
>>> Is this also related to https://bugzilla.samba.org/show_bug.cgi?id=8630
>>
>> Not completely, that is about one-way trusts while we're a domain member.
>> The above comments are for the case where we're a DC ourself.
> 
> Some of the work needed to do the correct handling of authoritative == 0
> (one part of the problem for one way trusts on the member server) I have
> in 
> https://git.samba.org/?p=abartlet/samba.git/.git;a=commitdiff;h=44eb64205a79681fc64e9430d78875842eeaee7c
> https://git.samba.org/?p=abartlet/samba.git/.git;a=commitdiff;h=c915d2ae81bad3304992148399564c32dbf66a00
> as part of
> https://git.samba.org/?p=abartlet/samba.git/.git;a=shortlog;h=refs/heads/subdomain-wip4
> 
> This is currently only for the DC, but the same logic should be re-used
> in the s3 auth code.

I may have a look at this in the next days...

Thanks!
metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20141219/477d8306/attachment.pgp>