winbind on PDC for trusted domains

Andrew Bartlett abartlet at samba.org
Sat Jun 28 10:19:27 GMT 2003


On Sat, 2003-06-28 at 20:03, Andrew Bartlett wrote:
> On Sat, 2003-06-28 at 18:42, Gerald (Jerry) Carter wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On 27 Jun 2003, Andrew Bartlett wrote:
> > 
> > > On Thu, 2003-06-26 at 19:57, Volker Lendecke wrote:
> > > > On Thu, Jun 26, 2003 at 11:55:24AM +0200, Volker Lendecke wrote:
> > > > > As winbindd has considerably changed lately, I had to tweak my little
> > > > > patch to make it work on a PDC a bit. Here is my latest version.
> > > > 
> > > > Ah, just that I'm not misunderstood:
> > > > 
> > > > This is completely work in progress.
> > > 
> > > And this patch is worse...
> > > 
> > > The attached patch attempts to call the auth subsystem from inside
> > > winbind, to prevent it from looping back to smbd (which will lock on
> > > contacting winbind).
> > 
> > Can I suggest that we just disable winbindd lookups for users that 
> > don't have the winbind separator in the name.  I think you guysa re making 
> > this too complicated.  I really don't think winbindd needs to be digging 
> > around in local accounts.  That really makes things messy from 
> > a code maintainance point of view.
> 
> 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.
> 
> > 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.

Also, we need to contact winbind for the idmap operations that a
smbd-based login would entail.  

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

Talking back to smbd would also entail an extra round of PAM checks.

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

Now that I'm finished uni for the semester, I'll try and get the patch
finished.

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/20030628/eda20877/attachment.bin


More information about the samba-technical mailing list