winbindd, samba DC, and trusts

simo idra at
Tue Jan 29 20:24:32 GMT 2008

On Tue, 2008-01-29 at 21:15 +0100, Volker Lendecke wrote:
> On Tue, Jan 29, 2008 at 02:20:58PM -0500, simo wrote:
> > The problem is that if you shut down completely winbindd in smbd then I
> > guess auth will fail for any trusted domain user.
> No, in the trusted domain case winbind would have to connect
> to the foreign dc itself anyway. I thought we're talking
> about the PDC case here.

Right, forget this, I mixed the 2 cases indeed.

> > BUT, I came out with a much simpler idea that seem to be working in my
> > initial tests.
> > 
> > Our problem is that we do try to authenticate against smbd in the main
> > winbindd daemon, this is a loop problem but also a waste because none
> > (that I've checked so far) of the operations we need to perform against
> > our own DC really are done in the main daemon.
> > 
> > All user/group enumeration is normally turned of in the IS_DC case and
> > in the Samba DC case what we really care about is pam/ntlm_auth
> > authentication anyway, and this is performed in the winbind domain
> > child.
> Hmmm. Sounds a bit fishy, but it might solve that one
> particular problem. I'd much rather see that winbind does
> not connect the local smbd at all if possible. To avoid
> doing the check_ntlm_auth thing for passdb users (i.e. our
> own domain) in winbind, I'd still like to see at least an
> initial attempt at the fork thing.

This is for 3.0.x, I don;t want to put too much new code there, I agree
we can think of a broader approach for 3.2.x

> I know this comment is moot, because I'm not doing it
> myself, but I think what is needed is a picture and/or table
> of all cases that we have. I think one of the main problems
> in winbind is that there are just way too many situations
> that are just way too easy to break. If we had a list, one
> might at least go and test all of them.

I agree we should do this, will see if I have the time to get to compose
this list.


Simo Sorce
Samba Team GPL Compliance Officer <simo at>
Senior Software Engineer at Red Hat Inc. <ssorce at>

More information about the samba-technical mailing list