passdb lookups directly in winbindd? [was Re: winbind on PDC for trusted domains]

[Gerald (Jerry) Carter]

-----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.

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.
  *)  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. 

> > 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. 

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.





cheers, jerry
 ----------------------------------------------------------------------
 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/

iD8DBQE+/eVlIR7qMdg1EfYRAkyZAKCSSmid0q9HF2PYqxL0SPtJaErzGACfXyTh
UKa40yEt5A7JqPHjZuyNUfU=
=WVzm
-----END PGP SIGNATURE-----