[PATCH] fix Samba3 LSA CreateTrustedDomainsEx2

[Stefan (metze) Metzmacher]

Am 09.03.2012 10:18, schrieb 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 don't think reauth changes the session key.

But what we need here is the transport layer session key and not the one
from
the session info.

(We need a better separation of all the keys,
not that with smb 2.2 there's an "Application Key", which is supposed to be
used by the rpc layer).

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20120309/73a44066/attachment.pgp>