[PATCH] s3-winbindd: Store schannel credentials in secrets.tdb

[Stefan (metze) Metzmacher]

Am 22.03.2013 13:11, schrieb Andrew Bartlett:
> On Fri, 2012-10-05 at 09:08 +1000, Andrew Bartlett wrote:
>> On Thu, 2012-10-04 at 15:56 -0700, Christof Schmitt wrote:
>>> Andrew Bartlett <abartlet at samba.org> wrote on 10/03/2012 06:46:54 PM:
>>>
>>>> However you do it, you do need to serialise the sequence number updates
>>>> for send, but a restructure may avoid you needing to serialise the whole
>>>> request/reply chain.  Essentially, we both probably need to read up the
>>>> docs, and see if instead we can store an expected reply for a given
>>>> sequence number.  That would avoid needing to lock over the network ops
>>>> waiting for the reply. 
>>>
>>> I started looking into this part and reading MS-NRPC. Using the lock
>>> only for sending the request would mean using the async calls
>>> dcerpc_netr_LogonSamLogon_send() and dcerpc_netr_LogonSamLogon_recv()
>>> instead of the sync one dcerpc_netr_LogonSamLogon().
>>>
>>> netlogon_creds_client_check() is simply a memcmp(), so the client
>>> already has the expected reply for verifying the server response.
>>>
>>> Besides LogonSamLogon, the same changes have to be made for all calls
>>> using the struct netr_Authenticator.
>>>
>>> Looking at the code, source3/rpc_client/cli_netlogon.c might be a good
>>> place to make those changes. Maybe this file would be also a better
>>> place to access the schannel tdb.
>>>
>>> I will continue from here, just let me know in case i am heading in
>>> the wrong direction.
>>
>> Even better would be a set of generic, async wrappers around the
>> dcerpc_netr_LogonSamLogon_send() and dcerpc_netr_LogonSamLogon_recv()
>> (et al) calls that fills in the authenticator on the way out, and check
>> it on the way back. 
>>
>> We are trying to push the async layer up the stack as far as possible,
>> so it would be best if new code didn't make that harder.  (Particularly
>> for crypto code, which few dare to touch once implemented :-)
> 
> Christof,
> 
> I had someone ask me about this recently.  Where did we end up with
> this?

I'm currently working on this...

metze

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