[PATCH] fix Samba3 LSA CreateTrustedDomainsEx2

[Alexander Bokovoy]

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 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.

> (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).
Yep.

-- 
/ Alexander Bokovoy