One winbindd: Some thoughts

[Andrew Bartlett]

I've been meaning to write to the list for a while about the task of
moving to a single winbindd implementation. 

First, I want to clear some air about the source4/winbind code, because
there has been some over-statements here in the past, and a good degree
of mystique about it.

The most magic thing about the s4 winbind code is that it actually works
at all, particularly when paired up on a real-world server with smbd.  

The biggest issue with it is that there are no caches, and so every
query is pushed to the local smbd, which by it's nature will likely make
winbindd calls to establish the session.  I certainly wish we had the
resources to overhaul both parts in the race for 4.0, but we didn't, and
so I didn't take my earlier design forward in the 's3fs' effort.

(As a historical note, the ill-fated s3compat effort actually included
the s3 winbindd being loaded inside the winbind task of the samba
deamon, just as smbd was being loaded in a task). 

In any case, we can't just swap them over right now, but I don't think
there is an incredible amount of work required to do this, and do it
right:

IDMAP_BOTH - This I list mostly because at the time of the sprint to 4.0
this was one of the larger tasks overhauling the idmap system in smbd,
but which I didn't complete at the time in winbindd (because it wasn't
in the critical path).  I understand Michael Adam and others have been
beavering away at this, and it is now implemented. 

Add IRPC - I would like to have the new common winbind available over
IRPC, so we can incorporate the code in winbindd that uses that
interface.  We have done much to bring the messaging systems into
common, and we could either finish that work, or simply allow winbind to
register with both systems.  Implementing this would allow us to switch
back and forward between the two implementations by simply starting or
stopping the appropriate tasks.

Implement IRPC calls: SamLogon, DsrUpdateReadOnlyServerDnsRecords,
WINBIND_GET_IDMAP.  

sam.ldb backend - I would like to either revive the winbindd_passdb
backend (and go via pdb_dsdb) or add a new winbindd_dsdb backend.  This
would specifically address the needs of the AD DC, by direct read access
to the database, avoiding blocking on a remote or inter-process server.
As we gain multiple domain support, this will 

idmap.ldb - for the AD DC by default, at least as a compatibility
measure, we will need to continue to use the current mechanism, no
matter the major issues.  But I look forward to a unified configuration
syntax here.  

rfc2307: (not actually a blocker, but a relevant point) I do regret not
pushing harder for 'idmap_ldb:use rfc2307' to be the default in the AD
DC, because I think that for all Samba modes, absent another overriding
configuration, that if the directory as uidNumber and gidNumber values,
we should use them.  So many of our users are frutrated that this
doesn't 'just work' when it does with nss_ldap et al. 

rfc2307 IDMAP_BOTH schema extension: We should also work out an
optionally loaded schema extension to on a per-record basis indicate
that a uidNumber is also a gidNumber, so we can support having a
gidNumber assigned to the important domain admins group, which needs to
be IDMAP_BOTH to own files.  

Refactor winbindd_dual_auth_passdb - This code needs to be reworked to
use the auth subsystem, perhaps with some special flags, so that we call
the AD DC auth code in the AD DC case, based on the loaded auth modules.
(This will hook into the check_samba4_security code in auth_samba4)

Launch winbindd like we do smbd in the AD DC - I would like to minimise
disruption for our users, and once this is finished just replace the
winbind task with a wrapper like the one in file_server/

There is probably much more that also needs to be done, but I wanted to
take the step of outlining some concrete tasks that would go a long way
to addressing this.  

As we start to deal with parent-child trusts and multiple domains in a
forest, there may well be aspects of winbindd's design that don't work
out, but I'm much more confident of dealing with those in the source3/
winbindd code than adding all the required work in the source4/ code.
It will be worthwhile for some part of winbindd, dealing with cracknames
in particular, to have an overall view of the global catalog. 

I hope this helps stir some discussion, and even some further
implementation.

Thanks,

Andrew Bartlett
-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org