To release Samba 4.0 'as is'

Tue Nov 29 04:45:52 MST 2011

Hi tridge,

Sorry for the late jump on this thread I was partially sick.

On 23/11/2011 23:15, 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.
It would have been great that you exposed this problems to other team 
members as well.

>
> 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.
The thing is that for the moment "s4's winbind" is really really limited 
and it's huge problem/pain in production. You have only the random 
attribution of UID/GID, it's far from being optimal especially if you 
have more than 1 DC and you try to replicate sysvol/netlogon not with 
FRS (as we don't have it yet).
Administrators (at least me when I was AD administrator) likes to have 
the same UID/GID accross different servers.
Then nsswitch lib (libnss_winbind) is not working in a satisfactory way, 
in my 30 users domain (way before I had 15000+ contacts) the server just 
hanged when I enable libnss_winbind, doing a ls on one directory with AD 
users file is just dawn slow, so the administrator is left with just 
UID/GID no nice names that makes life so much easier.
I'm not speaking of pam_winbind ....

Before trying to address the correctness of RODC I think it's 100 times 
more important to fix this, because to my mind RODC is rarely used in 
simple setup and non simple setup involve multidomain forest that we 
don't reliably support so far. So if there is a security risk with RODC 
I think it's a 2 hours job to desactivate pam_winbind for RODC, I pretty 
sure that it will impact nearly 0 running production and mostly nobody 
in those who will join after a stable version of Samba AD is released.

In my memory I had a talk with andrew that acknowledged that the current 
s4's winbind is not enough and we'd better use the s3's winbind.

So if you release a stable release without a better way to allocate 
UID/GID and reasonable performance (or latency) for the libnss_winbind 
you are not offering a descent user experience of Samba AD to users, you 
have to think that people with simple Samba "NT domain" setup that will 
upgrade to Samba "AD domain" will be a bit disappointed to realize it.

> Cheers, Tridge

Matthieu.

-- 
Matthieu Patou
Samba Team
http://samba.org