To release Samba 4.0 'as is'

[Andrew Tridgell]

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.

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.

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.

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.

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.

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

Cheers, Tridge