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

[Christof Schmitt]

Christian Ambach <ambi at samba.org> wrote on 09/25/2012 11:30:40 PM:
> On 09/25/2012 10:25 PM, Stefan (metze) Metzmacher wrote:
> > I have problems with the 3rd patch, because we can't hold a tdb lock
> > while doing network operations! This needs to be avoided because we 
need to
> > avoid deadlocks.
> 
> You are right. That was the reason why g_lock was implemented in such a 
> clumsy way: we should never hold a lock on a record while performing 
> operations that might potentially time out. Otherwise CTDB recoveries 
> might run into timeouts because CTDB cannot lock the complete database.
> 
> > I think we need a model like we have for some file server tdbs
> > where we store the server_id of the process which "locks" the record,
> > and use the new dbwrap_watch_record_send/recv api to wait to get the 
lock.
> 
> Yes, dbwrap_watch might be what we need here.

I am all for doing the change the direct way, but this sounds much
more involved than my previous attempts. Can someone explain how
dbwrap_watch works and what is the best way to guarantee exclusive
access to the credentials record?

> But I think ideally we would also have to convert 
> cm_prepare_connection() (and all the steps it takes) and other functions 

> like cm_connect_netlogon() to be asynchronous. I think this would help 
> with dealing with timeouts and where to put in appropriate mutexes. What 

> do you think?

Is this a requirement for exclusive access to the credentials record
during the schannel authentication, or is this another
improvement/simplification?

> > Also for the netr_Authenticator credential chain the logic is much 
more
> > complex
> > for the clients, it's not enough to mutex the setup of the
> > netlogon_creds_CredentialState,
> 
> In my initial tests of the patches with a Samba member joined against a 
> Win2003 DC, the patch already helped: there were no more spurious access 

> denied messages when issueing a large amount of parallel connection 
> requests. So we are on the right track here.
> 
> > we also need to mutex the netlogon_creds_CredentialState->sequence 
etc.
> > And on the client we typically need to mutex arround network/ipc 
operations,
> > which should not be mutexed by a tdb lock.
> 
> In which cases (e.g. against which DC versions) is that mechanism used? 
> When certain RPC calls or validationlevels are not available? I am not 
> very deep into the schannel / authentication pieces, so I (and maybe 
> others) could use some coaching here.

I would also need some advice how to proceed here: The sequence number
seems to get updated in libcli/auth/credentials.c. Would this require
locking the record, and updating it for every sequence number update?
This might become complicated since we need to open the tdb in winbind
and then pass the tdb handle to the correct place for those updates.

Regards,

Christof Schmitt || IBM || SONAS System Development || Tucson, AZ
christof.schmitt at us.ibm.com  ||  +1-520-799-2469  (T/L: 321-2469)