s4:rpc_server/dcesrv_auth.c - Fix a RPC issue in conjunction with Windows 2000

[Stefan (metze) Metzmacher]

Am 30.05.2010 15:36, schrieb Andrew Bartlett:
> On Sun, 2010-05-30 at 15:29 +0200, Stefan (metze) Metzmacher wrote:
>> Am 30.05.2010 15:20, schrieb Stefan (metze) Metzmacher:
>>> Hi Matthias,
>>>
>>>> if you are so concerned I don't have another possibility other than to
>>>> revert it. I just would like to bring to attention that the mentioned
>>>> "special" RPC calls work against Windows Server 2008 - so the problem is
>>>> definitely valid.
>>>> Before I pushed this fix I tried also to activate our header-sign
>>>> support ("dcesrv:header sign = yes" in smb.conf) - which would be the
>>>> expected solution. But then the whole schannel interactions with the
>>>> Windows client broke.
>>>
>>> We don't support header signing for all auth types yet, but also don't
>>> have to, as the client won't use it, if the server doesn't indicate
>>> support for it.
>>>
>>>> I revert but I wish that you or metze take care about the issue and see
>>>> what's still missing in our own RPC header-sign implementation. If this
>>>> is fixed then we are done.
>>>
>>> I'm sure we'll fix this problem, but I'm not sure that it's related to
>>> header signing
>>> at all.
>>>
>>> We need a torture test that does the packet sequence as a windows 2000
>>> client
>>> first (with all the same bits set).
>>
>> I think the correct fix should be in
>>
>> schannel_session_info(), there we force auth_anonymous_session_info()
>> which seems to be wrong. We should not provide a session_info at all,
>> to indicate to the dcerpc server code that it should keep the transport
>> related
>> session info.
>>
>> metze
> 
> Yeah, that may be the correct fix.  Fortunately we can tell, as we can
> ask the LSA server for our username, and we can try different
> combinations, once we get the handle via the exact sequence used by
> Windows 2000. 

I just noticed there's a second problem, we only have one global
dcesrv_auth structure per transport connection (dcesrv_connection)
which is wrong. The client can establish multiple auth/security contexts
indentified by a number. And we just overwrite the per connection context,
each time the client tries to establish a new security context.

metze

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/20100531/275f59a0/attachment.pgp>