[PATCHSET] Add MIT KDC kdb driver for Samba
Stefan Metzmacher
metze at samba.org
Thu Feb 4 15:26:22 UTC 2016
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.
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/20160204/0233e13d/signature.sig>
More information about the samba-technical
mailing list