Reasoning for auth_samba4.c

[Volker Lendecke]

On Tue, Dec 03, 2013 at 05:48:25PM +1300, Andrew Bartlett wrote:
> No, it would not.  The key point I've clearly not elaborated on enough
> is that the two new hooks (prepare_gensec and make_auth_context_s4) are
> at a different layer to that which auth_netlogond provided and therefore
> cannot be replaced with such a NETLOGON call.  
> 
> What is replaced here is the entire auth stack, not just one module.
> Rather than just handling an authentication and returning the struct
> auth_serversupplied_info, the make_auth_context_s4 hooks include the
> translation from the info3 all the way to the struct session_info, the
> assignment of local groups, handling of privileges and rights etc.  The
> databases used for these are distinct, and the needs of the file server
> and the AD DC are quite different in this area.

Two implementations of the same concept are not necessarily bad: We as
a Team decided to maintain two complete file servers. For example over
the weekend I spent a significant amount of time trying to reproduce
the inotify linker faults in ntvfs on FreeBSD. I need to do more work
on this though, I'm not the waf expert others are. Doing authentication
and authorization can hardly be of the same size as a complete file
server implementation.

> > For that we also have very elaborate
> > infrastructure available and don't need imessaging in this
> > place.
> 
> Aside from the re-use of code to obtain the current PID and so a unique
> server_id, is there a problem with the imessaging infrastructure that I
> am not aware of?  It is used extensively in the AD DC, and has proved to
> be most helpful.

In the past we have spent significant amounts of work to convert our
legacy code to unify the concept of server id.  With the AD DC code
we have a huge piece of work ahead of us that we now need to take care
of. This is a significant stumbling block on our way to get clustering
better: I would like to improve messaging between smbd and ctdbd. The
different requirements the AD DC has in this respect is something that
makes this job more difficult. That's the reason why I want to tackle
this one layer above.

Probably that will also be the groundwork to get rid of talloc_reference
in loadparm again, which seems impossible given the code merge has
brought the requirement to use talloc_reference. We need to split up
responsibilities again to get cleaner code in the file server.

> To keep everything consistent in AD DC operation, any change would have
> to be done not by using auth_netlogond in source3, but in the source4
> code based around the auth4_context structure.  You should be aware that
> additionally using ncalrpc, SCHANNEL and NETLOGON SamLogon calls here
> wouldn't remove the imessaging use in any case, as irpc isn't used for
> the local SAM case at present.  

Yep, and that's next on my list. I don't think we still have a valid
point with missing LDAP transactions anymore because we don't use the
source3 based samr servers on an AD DC.

> Instead, I suggest a much simpler approach:  That if this module is the
> last user of procid_self(), that we make it static in the same file as
> new_server_id_task(), and if necessary move that to the imessaging code,
> as the generic way to create client server_id addresses across the
> codebase.

Still this keeps two complete messaging systems in the same binary,
which is a major deficiency. Two distinct concepts of server identity
will just cause great confusion. I don't have the capacity to convert
all of the AD DC code to anything new, this is your field of expertise.

> I hope this clarifies things,

Same here.

Volker

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de