passdb lookups directly in winbindd? [was Re: winbind on PDC
for trusted domains]
Andrew Bartlett
abartlet at samba.org
Sun Jun 29 03:13:05 GMT 2003
On Sun, 2003-06-29 at 04:58, Gerald (Jerry) Carter wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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
> not.
I just re-read your patch. What bothers me most is that I just don't
trust random bits of libraries (PAM, etc) not to do invalid username
lookups etc - anything that might trigger a winbind client call.
It's certainly much simpler given that we deal only with the guest
account - but what if a winbind user were specified with 'wbinfo -A'.
Then we could be in much more difficulty.
Also, I don't think we work back in the file-server configuration as the
patch currently stands (it always contacts the trusted domain).
That said, we are much closer than I originally thought - your patch
does not contact smbd for authentication, but contacts the trusted
domain directly. So the only issue is what modifications we need to
make to the 'passdb' backend that we already have.
Why did we need to change smbd at all? Which part contacts smbd? (I'm
happy to leave the issue of winbind authenticating users in *our* domain
until we have this patch in).
> 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
> looks like:
>
> passwd: files ldap winbind
> group: files ldap winbind
>
> User lookups are fine. No looping. First match wins and the search
> stops.
>
> 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.
It already does that, and it looks like pam_winbind itself isn't an
issue here, except in the case of logins to the PDC itself. (Which I'll
deal with later).
> *) 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
> down.
Yes - it used to be *much* worse. We have all worked very hard, and I'm
quite pleased with the simplicity of your patch.
If I understand correctly - given that we are using the guest username,
the main issue is if smbd calls something like idmap - which in turn
contacts winbindd (if it's backed onto ldap, for example).
> > > 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
> winbind.
We don't support idmap without winbind (jra's recent change, which I
support). This means that we don't support NT4 migrations onto LDAP
without winbind. (This is because the LDAP backend is a 'remote'
backend).
Also, we can't do sensible sid->name translations (even more important
in a trusted domains situation) without winbind.
> 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.
The biggest issue with the module is the lack of a connection cache,
which as we must run winbind anyway seems a bad idea.
The trustdomain auth module was a quick hack, from back before I
introduced the 'winbind' auth moudle. The winbind module has shown
itself to be the far supriour method of communication.
I don't mind it being kept if sites *really* want to fall back to it (in
the same way we fall back to ntdomain), but I see no reason to rely on
it.
Anyway, I'm going to test out the various patches today, and see if I
can both better understand what it being proposed, and how to solve it.
Andrew Bartlett
--
Andrew Bartlett abartlet at pcug.org.au
Manager, Authentication Subsystems, Samba Team abartlet at samba.org
Student Network Administrator, Hawker College abartlet at hawkerc.net
http://samba.org http://build.samba.org http://hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20030629/ca4b780d/attachment.bin
More information about the samba-technical
mailing list