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

Andrew Bartlett abartlet at samba.org
Fri Mar 22 17:26:55 MDT 2013


On Fri, 2013-03-22 at 13:24 +0100, Stefan (metze) Metzmacher wrote:
> 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...

I'm happy to help out on this if you would like the assistance. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org




More information about the samba-technical mailing list