To release Samba 4.0 'as is'

[simo]

On Thu, 2011-11-24 at 09:15 +1100, Andrew Tridgell wrote: 
> Hi Volker,
> 
> > What features does the S4 winbind provide in this area that
> > the S3 winbind does not provide?
> 
> At the moment both the s3 winbind and the s4 winbind lack features with
> regard to being an AD DC. The question that Andrew and I have been
> looking at recently is which one provides a better base to build on, and
> whether having a single winbind for both situations (member server vs
> DC) actually makes sense.
> 
> When a server is an AD DC, the methods needed to answer the queries that
> winbind gets are quite different from the methods needed when the server
> is a member server. For example, most AD DCs are global catalogs. That
> means the DC has a local database with the answer to all of the
> non-authentication based queries like "sid to name", regardless of
> whether the sid/name being looked up is in our domain or another domain
> in the forest. So it makes most sense when Samba is a global catalog DC
> for the service that provides the nss lookup functions to go straight to
> that local database.

So why can't both the member and the DC use the same lookup methods ?
on a member it is a call to a different server, on a DC it is a call to
localhost, what's the problem there ?

> The next problem is understanding of all of the principal forms that
> user and group names can take. When you have a string representing a
> user and you want to get some other representation of the user, then the
> correct way to do that in an AD DC context is to use DRS cracknames,
> which is the core method that maps between different representations of
> a user. This is an extremely complex function, because there are so many
> different representations of a user as a string. The s3 winbind code
> assumes just a small range of possible representations.

Why can't you make s3 winbind simply use the crack name service? on a
member it is a call to a different server, on a DC it is a call to
localhost, what's the problem there ?

> Next comes authentication. To work out how to service an authentication
> request, you first need DRS cracknames to work out which domain the user
> is in. This isn't nearly as trivial as it seems at first. After you've
> worked out what domain it is in, you then need to work out what DC can
> service the request. That involves looking at the trust path between the
> current DC and the target domain. Those trust paths can be complex, and
> require you to look through the configuration partition in the SAM to
> work out where the auth request needs to go.

And why would this work be different on a member server or on a DC ?
It looks to me the work to be done is the same, except that the services
you use sometimes (the DC case) are local.

> Then comes the RODC case. When the Samba server is an RODC it needs
> special handling of authentication in the winbind service. In that case
> the local Samba DC is able to handle authentication requests for some
> users and not for others in the local domain. After the cracknames it
> needs to lookup the attributes that indicate if this DC has the
> credentials for the target user. Then if they aren't there, it needs to
> work out if it has the necessary rights to ask a RWDC for those
> credentials, or if needs to forward the request. If it can ask for a
> copy of the credentials it needs to do that and then store the
> credentials locally. If it can't ask for a copy of the credentials then
> it needs to pick the right DC to forward the authentication request to.

It looks clear to me that the problem here is that you are conflating
the LSA service with Winbind.
Extract the LSA service ouot of it and you just have again the same code
just asking different LSA 'backends' one in the surrent smbd the otgher
in the current samba binary as used by a DC.

> To get all of this logic into the s3 winbind would involve a massive
> change in that code and we'd end up with a daemon that is trying to do
> far too many things. The s3 winbind is basically a "cacheing slave". The
> equivalent service for an AD DC is quite different. Putting both in the
> same service would be a huge mess I think.

it needs to be split in different services but the cut should not be
vertical creating 2 competing stack, but horizontal where the caching
front-end speaks to service we already have and present standard
interfaces we use against both samba and windows servers.
And for the few additional objects need by posix we can easily use the
rfc2307 schema extensions that are available also in the AD schema.

> So I think we're better off leaving the s3 winbind alone for now, and
> instead continuing to work on the s4 winbind code for when we are an AD
> DC.

And have yet another split stack vertical. It almost seem like we should
just fork the 2 projects, after all we reimplement everything
differently between the file server components and the DC components
with no intention of sharing common code and cut interfaces were it make
sense in order to achieve that goal ...

> It doesn't have all of the features listed above yet (though it does
> have enough of them to be usable), but I think it will be much easier
> and cleaner to add AD DC specific features in the s4 winbind code than
> attempting to make the s3 winbind code handle all the things that are
> needed.

I don't think we are going anywhere if we continue with this split
system where there are my toys and your toys and everyone keeps theirs
in their walled garden ...

I am honestly quite disappointed by the proposal and by the tone of the
discussion set up by you and Andrew Bartlet.

At every turn it seem to read just: "my way or the highway".
I do not see any willingness to compromise and work toward a solution
that benefits our users instead of our egos.

This is very sad.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>