[PATCHSET] Add MIT KDC kdb driver for Samba

[Alexander Bokovoy]

On Thu, 04 Feb 2016, Stefan Metzmacher wrote:
> Hi Andreas,
> 
> > From 94e373510e7146517f0ff965f0fd677dd9e58050 Mon Sep 17 00:00:00 2001
> > From: Simo Sorce <idra at samba.org>
> > Date: Thu, 3 Dec 2015 11:02:23 -0500
> > Subject: [PATCH 01/29] s4-ldb: Use correct salting for interdomain trust
> >  accounts
> > 
> > Interdomain trusts use a salt of krbtgt/OTHER_REALMFLATNAME at OUR.REALM
> > 
> > Signed-off-by: Simo Sorce <idra at samba.org>
> > Reviewed-by: Andreas Schneider <asn at samba.org>
> > Reviewed-by: Sumit Bose <sbose at redhat.com>
> 
> I've thought about this a bit more.
> 
> I'm wondering why this is needed. Do you had a problem
> with trusts while using the MIT kdc?
> 
> If so then the bug should be fixed (at least partly) differently.
> 
> For trust principals we need to get the keys from the 'trustedDomain'
> object and not from the 'user' object. The KDC should never see the 'user'
> object.
> 
> It's still possible that the patch if correct, but we'd have to
> replicate the user object of a trust from a Windows dc and
> calculate the aes keys ourself from the plaintext password
> and our knowledge of the salt.
> 
> Note the KDC always generates the aes keys on demand as we only
> store the plaintext.
> 
> BTW: looking at MS-KILE 3.1.1.2 Cryptographic Material and 3.3.5.6.1
> Referrals
> Indicates that our userPrincipalName handling is useless and we should
> always
> use the sAMAccountName for user accounts.
> For trusts we should use krbtgt/OTHER.REALM.DNS at OUR.REALM.DNS
> instead of krbtgt/OTHER at OUR.REALM.DNS and that's what we're using
> in samba_kdc_trust_message2entry().
> 
> Where do you get the krbtgt/OTHER at OUR.REALM.DNS from?
> This might still be the correct thing, but only for the 'user' object,
> but it's never used... So I just want to understand why this is correct.
"User" part of TDO is used to lookup data in the AD LDAP and AD GC from
a trusted realm. We use it, for example, by SSSD in FreeIPA when you
have one-way trust to AD established. In this setup you cannot use
host/fqdn at IPA.REALM to authenticate to ldap/fqdn1 at AD.REALM because there
is no trust path in this direction. As result, SSSD has to use the
account from AD.REALM to do searches and it is 'user' object part of TDO
that is used here, NAME$@AD.REALM which used here, and NAME$ has to be
based on the NetBIOS name of the forest root domain. This works well. It
will not work if the salt is derived from IPA.REALM$@AD.REALM.

-- 
/ Alexander Bokovoy