[PATCH] fix Samba3 LSA CreateTrustedDomainsEx2
Stefan (metze) Metzmacher
metze at samba.org
Fri Mar 9 03:29:01 MST 2012
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
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 262 bytes
Desc: OpenPGP digital signature
More information about the samba-technical