[PATCH] s3-winbindd: Store schannel credentials in secrets.tdb
abartlet at samba.org
Tue Sep 18 23:21:30 MDT 2012
On Tue, 2012-09-18 at 18:43 -0700, Christian Ambach wrote:
> On 08/01/2012 10:19 AM, Christof Schmitt wrote:
> > Andrew Bartlett <abartlet at samba.org> wrote on 07/31/2012 04:37:40 PM:
> >>> The patch stores the netlogon credentials per domain controller in
> >>> secrets.tdb. If there are already credentials before establishing a
> >>> netlogon session, those credentials are reused. If the reused
> >>> credentials are no longer valid, they are deleted and the netlogon
> >>> session is established with new credentials.
> >> This seems to duplicate the code in libcli/auth/schannel_state_tdb.c
> >> which is used for the same task on the server side.
> >> I know it might mean sorting this out to be dbwrap aware, but I would
> >> really like to reduce the duplication in this area.
> > Ok, i will work on an updated patch to reuse the code in
> > schannel_state_tdb.c.
> The bad thing about that proposal is that this will require to move
> dbwrap_open (and the whole CTDB connection code connected to that) to
> common code as this needs to work cluster-wide, so the credentials need
> to be stored in a CTDB-managed tdb. As recently discussed, it is not a
> good idea to put a dependency from / code into source?, it should only
> be the other way around.
> Using the existing secrets.tdb has the beauty of the code avoiding that
> move, but otherwise it is also the wrong location as this information
> should not live in a persistent database, but in a volatile one.
> I'll have to see how to move dbwrap_open to lib/dbwrap without too many
> intrusive changes.
There are a few ways some of this can be managed. The bulk of the code
can be handed a already-open handle (for example) so we don't need to
deal with the ctdb open.
Also, we really need to work past this 'top level code', 'source3' and
'source4' split. Instead, it is more useful to think about things in
terms of difficult dependencies, such as the lp_() functions, because
these are technical issues we can resolve. Specifically we have a
workaround involving using the lpcfg_() functions and passing in a
loadparm context of the correct type.
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
More information about the samba-technical