To release Samba 4.0 'as is'

[Gémes Géza]

2011-11-29 12:45 keltezéssel, Matthieu Patou írta:
> 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.
>
Hi,

IMHO it means that Samba4 is ready for a multi DC domain if (either one
of them, in order of feature-fullness):
1. Implement FRS
2. All the DCs are Samba4 there is a handmade (e.g. inotify/rsync based)
replication solution built up and the UIDs GIDs NTACLs are somehow
synchronized.
3. Forget about GPOs logonscripts (I wouldn't call that version suitable
for 4.0 because the big selling point is GPO)

If FRS cannot be implemented in a timely manner a standard solution for
variant 2 should be recommended for users.

Just my 2c.

Cheers

Geza