[PATCH] fix Samba3 LSA CreateTrustedDomainsEx2

[Andrew Bartlett]

On Fri, 2012-03-09 at 10:49 +0200, Alexander Bokovoy wrote:
> On Fri, Mar 9, 2012 at 10:34, Andrew Bartlett <abartlet at samba.org> wrote:
> >> 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.
> Yes, we discussed this yesterday with Simo as well and would like to
> have auth_session_info fully opaque for this reason, with function
> pointer-based accessors. I'll make sure there is a room in my work
> queue for that as a next step.

I don't quite get why auth_session_info needs to be opaque, but I agree
about dealing with the session key separately.  (There may be additional
reasons in SMB2 re-authentication as hinted at in the paragraph above.
That is, perhaps the session key could change!)

> I think we can push this patch as it would enable us to proceed with
> trusts management code on FreeIPA v3 side without relying on hacked
> samba builds.

Please do.  

Andrew Bartlett
-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org