passdb lookups directly in winbindd? [was Re: winbind on PDC for
Gerald (Jerry) Carter
jerry at samba.org
Sat Jun 28 18:58:42 GMT 2003
-----BEGIN PGP SIGNED MESSAGE-----
On 28 Jun 2003, Andrew Bartlett wrote:
> We are already heading for this - winbind has a passdb backend already
> (not operational), and it is intended that winbind should provide these
> services for direct NT migrations.
> (Ie, you suck down an NT PDC into passdb, and winbind handles the rest).
> I agree that it seems to be feature creep - if we really do feel that
> way, then creating a seperate 'samba-authd' might be appropriate.
> However, given the circumstances I think it's suitable.
Nope. Given how much time I've had to spend with issues with winbind,
i don't trust this. Makes the code to fat with too many "do this unless
we under these cirsumstances, then do that." It's not winbindd's job.
You "feelings" are going to convince me when there are alternative paths
that make the code cleaner and easier to debug and maintain.
> > The patch at http://samba.org/~jerry/winbind_on_pdc_v1.patch
> > works with the minor detail that I still have to code up the trustdomain
> > and winbind auth methods to produce a SAM_ACCOUNT. This patch has been
> > tested a fair amount. I know basic SMB connection works.
> Avoiding winbind calls in smbd is a loosing game - it's much easier to
> control what winbind contacts. Too many things call nsswitch - and for
> 'winbind use default domain' it's not possible to tell at all.
2 points. I have a working login as a trusted user on a Samba domain
member (2k client). So saying it is a loosing game is not valid
reasoning. I've got working code. I'll continue to work on it some more
today and if I head a dead wall, then I'll back down. Until then, I'm
Secondly, you are going to have to back you claims up here. The only
problem I have been able to find is in the call to initialise_groups()
because NSS is looking for secondary groups. /etc/nsswitch.conf
passwd: files ldap winbind
group: files ldap winbind
User lookups are fine. No looping. First match wins and the search
The only arguement you've given me so far is that "winbind use default
domain" is useful at your site and my proposal wouldn't work with
pam_winbind.so. So looked at the code for this.
*) pam_winbind contacts winbind directly, bypassing smbd altogether
except for authentication. No problem here.
*) all the code I can find in smbd that checks for
lp_winbind_use_default_domain() immediately sets the domain
to lp_workgroup() if the former option is enabled so
a user still appears as DOMAIN\user. In order for
initialise_groups() to ever be called the user must be
a) a local user found in the passdb, or
b) a winbind user whose username is returned in the
net_sam_logon reply and therefore guantanteed to be
in the form DOMAIN\users.
You've done a good job is providing an clean infrastructure. That
is why it has been so easy to get this to work so far.
If you think my code won't work (which it is right now), you're
going to have to give me a specific example where it breaks
> > Also note that there is a server mutex deadlock in the cvs code right
> > when using "auth methods = guest sam trustdomain" and trying to run
> > winbindd. We should really only use "guest sam winbind" if winbindd is
> > running and leave the trustdomain auth method for situations where the
> > usernames already match.
> I would suggest an alternative approach, for the following reasons:
> - smbd is unsuitable for contacting trusted domains:
> - It cannot cache connections
> - For applications like Squid (even on a domain member) we can get a
> *lot* of authentication requests. Creating a new connection for each
> authentication will hit us hard.
> - It cannot use the winbind negative connection cache
> - It requires yet another item in the chain for trusted
> I would like to see the trustdomain auth module die. We have seen the
> problems that the 'ntdomain' module has, and the caching of connections
> via winbind significantly enhances performance.
> Winbindd already contacts each trusted DC for LSA, SAMR etc - I don't
> see an issue contacting it for the NETLOGON pipe too.
Except we've already a decision to support domain member security w/o
winbind (as in 2.2). You are saying that even if an admin manually
creates accounts for trusted users, we shouldn't support domain trusts w/o
Now I'm not a huge fan of the trustdomain auth module either and
would love to see it die, but this same decision caused problems
with domain mode security in 3.0beta1. Truthfully, I don't trust
either of us to make this decision. People will have to speak up
and if they want it as a reasonable feature and it is currently working,
I see no reason to remove it.
Hewlett-Packard ------------------------- http://www.hp.com
SAMBA Team ---------------------- http://www.samba.org
GnuPG Key ---- http://www.plainjoe.org/gpg_public.asc
"You can never go home again, Oatman, but I guess you can shop there."
--John Cusack - "Grosse Point Blank" (1997)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
Comment: For info see http://quantumlab.net/pine_privacy_guard/
-----END PGP SIGNATURE-----
More information about the samba-technical