[SCM] Samba Shared Repository - branch master updated -release-4-0-0alpha6-1045-gfc02c3b0

Steven Danneman steven.danneman at isilon.com
Sun Feb 22 22:28:41 MST 2009

> On Sun, Feb 22, 2009 at 11:54:21AM -0800, Steven Danneman wrote:
> > > >     This new backend is custom tailored to onefs unique
> requirements:
> > > >     1) No fallback logic
> > > >     2) Does not validate the domain of the user
> > > >     3) Handles unencrypted passwords
> > >
> > > What about these is onefs specific? Why did you put "onefs"
> > > into the names?
> >
> > Hey Jeremy, Volker,
> >
> > No compelling reason to put onefs in the names other than the
> behavior
> > specifically matches the central authority provider that we have
> setup
> > in our system.  However, all the programming interfaces are through
> > wbclient.
> >
> > What do you think of "pdb_wbc_sam", and "auth_wbc"?  Ill make the
> > distinction in the code and comment that the difference between
> > auth_wbc and auth_winbind is that the first doesnt filter out local
> > user, but instead expects the backend to handle them.
> Ok, "auth_wbc" looks a hell lot like "auth_winbind". Looking at the
> code the only difference between both is the fact that the current
> onefs module handles plain text. Is that really used? Don't we handle
> plain text at a higher level??
> If yes, why not use auth_winbind without fallback?
> And, thinking about it a bit more -- what problem do you want to solve
> by passdb_onefs (or passdb_wbc...)? Passdb is supposed to be the local
> sam of the system. Why do you want to redirect this to winbind at all?
> Volker

Hi Volker,

You're correct, auth_wbc.c is a pretty direct copy of auth_winbind.c
with the three differences being noted in the commit message.  We
thought it was cleaner to create a new auth backend, rather than add
parameters to auth_winbind to conditionally change its behavior.

The overall goal of both patches is to defer all authorization and
account information storage, including local users, local groups, plain
text passwords, etc to a central daemon accessed through the wbclient

In this way we have a single path for all auth requests on our system.
Regardless of how the actual auth data is stored (files, smbpasswd,
ldap, nis, AD) they are accessed and managed by a single provider.  So
pdb_wbc_sam is asking the wbclient compatable daemon for local SAM
information.  This design is somewhat similar to the Local Security
Authority and corresponding Lsass.exe service on a Windows system.


More information about the samba-technical mailing list