[PATCH] fix Samba3 LSA CreateTrustedDomainsEx2
Andrew Bartlett
abartlet at samba.org
Fri Mar 9 01:34:19 MST 2012
On Thu, 2012-03-08 at 23:04 +0200, Alexander Bokovoy wrote:
> Hi,
>
> On Fri, Mar 2, 2012 at 23:30, Andrew Bartlett <abartlet at samba.org> wrote:
> > On Fri, 2012-03-02 at 21:53 +0200, Alexander Bokovoy wrote:
> >> Hi,
> >>
> >> I found out when using samba4 python bindings that the same code to
> >> establish trusts works against Windows 2008 R2 DC but doesn't work
> >> against Samba3. On deeper inspection it appeared that LSA
> >> CreateTrustedDomainsEx2 implementation in Samba 3 ignores the fact
> >> that only up to 16 bytes of session key are used for encryption of
> >> authentication blob. Samba 4 code does automatically limit session key
> >> to 16 bytes when attempting to encrypt/decrypt the authentication
> >> blob, thus is working well.
> >>
> >> Attached patch fixes the issue and makes sure we re-use common code to
> >> extract the parts of the authentication blob. With it I'm now able to
> >> successfully establish cross-forest trust between Windows 2008 R2 and
> >> Samba 3 with FreeIPA 3 backend (in development).
> >>
> >> I'll make sure there is torture test to cover the situation, however,
> >> it would require parallel use of two DCs, how should this be done with
> >> autobuild in mind?
> >
> > Yes, the selftest environment can run quite complex things. You can
> > join s3dc or a new env to one of the Samba4 domains if you want. We
> > already join a s3 AD domain member to 'dc' as s3member, and that might
> > be a good guide. I'm very happy to either review, guide or assist in
> > any reasonable way as you navigate our selftest system.
> >
> > On the patch, I suspect the layer at which the session key is being
> > truncated is incorrect - we should be truncating it when it is imported
> > into the dce/rpc stack, otherwise this will just fail on another call,
> > like SAMR password setting.
> Andreas and I have looked into various specifications (MS-SMB,
> MS-LSAD, MS-NRPC, MS-SAMR, etc) and it seems that this fact that
> session key could be trimmed to 16 bytes is an SMB pipe property.
> There could be pipes which require full session key but at least LSA
> and SAMR require 16 bytes ones. We decided to follow the Samba4 suite
> and introduce a helper to extract session key. The only difference is
> to allow the caller to specify intent to use of the session key, thus
> forcing us to remember this knowledge at the place where it is used.
>
> MS-LSAD's 5.1 section also states that
> ----
> The session key for sections 5.1.1 and 5.1.2 is obtained from the SMB
> transport, as specified in section 2.1. The session key is obtained
> from the SMB transport every time a message that needs encryption is
> to be sent or a message that needs decryption is to be received.
> ----
>
> Thus, we cannot truncate it once and forever.
> Attached patch implements the change for LSA and SAMR.
This is certainly a very good start. There are sadly a few more
oddities, which is why the Samba4 approach is a function pointer on the
equivalent of the pipes_struct. The first is that when you authenticate
at the SMB pipe level (ie for TCP, or pipe level sign/seal), you either
get a session key of SystemLibraryDTC (Win2003) or
NT_STATUS_NO_SESSION_KEY (Win2008), unless you are authenticating on
DRSUAPI (you get the original key, not truncated)
As such, I think the best approach is to take the best of both. I would
like this to retain the intent argument, but have this be a function
pointer that the dce/rpc server layer can replace depending on the
authentication state.
(This may also help a side-project I'm still considering, which is to
have source4/rpc_server able to host 'Samba3' rpc_servers by creating a
fake pipes_struct and using function pointers for things like this).
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
More information about the samba-technical
mailing list