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

Alexander Bokovoy ab at samba.org
Thu Mar 1 22:12:25 UTC 2018


On to, 01 maalis 2018, Stefan Metzmacher wrote:
> 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.
Yes, there is associated confusion between the object and a user
account.

> 
> > 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.
Thing is, it will not fail for wrong salt too because we are running
against the same code that uses the same method to generate salt
principal. So before the patch we've got 'EXAMPLE.COMFOO$' as a salt,
after the patch we'd get 'EXAMPLE.COMkrbtgtFOO' but in both cases both
client and KDC would be operating with the same salt because we retrieve
this keytab from the same KDC.

I wonder if we can retrieve it from a different KDC and store under
the proper principal but current code for keytab retrieval in libnet
doesn't handle that because it has no way to specify a different
principal name when writing keys to a keytab (we want to retrieve
FOO$@EXAMPLE.COM as EXAMPLE$@FOO.COM and then try to auth against
FOO.COM KDC).

With my parallel patches (in works) to FreeIPA and SSSD, I get Samba AD
DC properly trusted by FreeIPA and FreeIPA properly trusted by Samba AD
DC when trust is driven from FreeIPA side. So salt fixes helped, for
cases when TDA is used for authentication by both sides. There
is a remaining need to fix cross-realm TGT on FreeIPA side to allow
FreeIPA -> Samba AD leg to work with cross-realm referral issuance.
Samba AD -> FreeIPA leg works already.

-- 
/ Alexander Bokovoy



More information about the samba-technical mailing list