[PR PATCH] [Updated] samba-tool domain trust: fix trust compatibility to Windows Server 1709 and FreeIPA

[Stefan Metzmacher]

Am 01.03.2018 um 22:48 schrieb Alexander Bokovoy via samba-technical:
> On to, 01 maalis 2018, Alexander Bokovoy via samba-technical wrote:
>> On to, 01 maalis 2018, Stefan Metzmacher via samba-technical wrote:
>>> Am 01.03.2018 um 10:41 schrieb Alexander Bokovoy:
>>>> On to, 01 maalis 2018, Stefan Metzmacher via samba-technical wrote:
>>>>> Am 01.03.2018 um 08:54 schrieb Alexander Bokovoy via samba-technical:
>>>>>> On to, 01 maalis 2018, Stefan Metzmacher via samba-technical wrote:
>>>>>>> Hi Alexander,
>>>>>>>
>>>>>>>>> As we only use remote_netlogon_info.dc_unc can we
>>>>>>>>> add get_netlogon_dc_unc() that falls back to netr_GetDcName()
>>>>>>>>> against the remote dc.
>>>>>>>>>
>>>>>>>>> That would also help if we try to implement trusts against
>>>>>>>>> an NT4 style domain.
>>>>>>>> Makes sense. Updated patches attached.
>>>>>>>
>>>>>>> Thanks much better:-)!
>>>>>>> Is that tested against FreeIPA?
>>>>>> Not yet, in my plans for today as I'm trying to figure out what else we
>>>>>> are missing in TDO salt principals.
>>>>>
>>>>> The salt principal for the BLA$ user object is wrong.
>>>>>
>>>>> dn: CN=bla.base,CN=System,DC=w4edom-l4,DC=base
>>>>> securityIdentifier: S-1-5-21-4053568372-2049667917-3384589010
>>>>> trustDirection: 3
>>>>> trustPartner: bla.base
>>>>> trustPosixOffset: -2147483648
>>>>> trustType: 2
>>>>> trustAttributes: 8
>>>>> flatName: BLA
>>>>>
>>>>> dn: CN=BLA$,CN=Users,DC=w4edom-l4,DC=base
>>>>> userAccountControl: 2080
>>>>> primaryGroupID: 513
>>>>> objectSid: S-1-5-21-278041429-3399921908-1452754838-1597
>>>>> accountExpires: 9223372036854775807
>>>>> sAMAccountName: BLA$
>>>>> sAMAccountType: 805306370
>>>>> pwdLastSet: 131485652467995000
>>>>>
>>>>> The salt stored by Windows in the package_PrimaryKerberosBlob
>>>>> (within supplementalCredentials) seems to be
>>>>> 'W4EDOM-L4.BASEkrbtgtBLA' for the above trust
>>>>> and Samba stores 'W4EDOM-L4.BASEBLA$'.
>>>> Yes, exactly. It doesn't affect Samba AD DC trying to contact Windows AD
>>>> DC because KDC advertises salt and Samba always generates the key on the
>>>> fly. However, it does affect SSSD on FreeIPA masters because in IPA case
>>>> KDC has all keys pregenerated at the time Kerberos principals are
>>>> created when trust is added and SSSD uses a keytab to authenticate as
>>>> TDO.
>>>>
>>>> I have a patch that passes userAccountControl to
>>>> smb_krb5_salt_principal() and it should fix the problem. The patch is
>>>> against 4.7.
>>>
>>> That looks good, can you prepare this for master and
>>> add a test to demonstrate the SSSD behavior, so we don't
>>> regress on this in future. I guess it's just using
>>> BLA$@W4EDOM-L4.BASE as client and/or server principal?
>> It does use BLA$@W4EDOM-L4.BASE as an initiator to talk to LDAP (i.e.
>> ldap/dc.w4edom-l4.base) but the salt to obtain TGT is negotiated with
>> KDC.
>>
>> I'll look at making a test.
> Full patchset is attached. It includes all patches discussed plus a test
> for retrieving a keytab for TDO and using kinit from keytab.

Using the term TDO is confusing here, it typically refers to
the trustedDomain object not to the related user account.

And the bug happens with the user account not the TDO.
Maybe something like TDA (for trusted domain account) would be
better.

> Below is a sample output from a test run when I enabled explicit logging
> of KRB5 tracing. As you can see, the salt is now a correct one.

Can you split the last patch and demonstrate the the test passes with
a temporary file in selftest/knownfail.d/ and then gets fixed with the
changes. From reading the test I guess it won't fail as the bug happens
in two places.

Thanks!
metze



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20180301/269c1f01/signature.sig>