Reasoning for auth_samba4.c

[Andrew Bartlett]

On Fri, 2013-11-29 at 18:20 +0100, Volker Lendecke wrote:
> On Sat, Nov 30, 2013 at 06:04:56AM +1300, Andrew Bartlett wrote:
> > On Fri, 2013-11-29 at 10:01 +0100, Volker Lendecke wrote:
> > > Hi, Andrew!
> > 
> > > In the past I've put
> > > quite significant effort to get rid of procid_self. I would
> > > like to completely remove this and always go via
> > > messaging_server_id. Via new_server_id_task we acquired a
> > > new call to procid_self, which is a new stumbling block for
> > > removal of that routine. So I would like to know about the
> > > reasons why this is strictly necessary in the current setup.
> > 
> > It provides a deterministic client-side address for the imessaging
> > library to use, rather than the previous approach of selecting a random
> > number.
> 
> True. But this does not really answer my question: If we did
> this via a NETLOGON call over a unix domain socket, wouldn't
> that also work? 

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.

For completeness, as you are probably aware, the prepare_gensec operates
similarly, but additionally also initialises gensec in the same way that
the rest of the AD DC operates.  (I'm hopeful that with continued merged
effort, this call can be eliminated, leaving just
make_auth_context_s4). 

In both cases, the key requirement here is for consistency, that is that
the same code is used to accept a NTLM or Kerberos login no matter if we
are in the CIFS, SAMR or LDAP server, and the exact same processing
always applies.  

Finally, please do not be confused by the unused check_samba4_security()
call.  This code is unused, except for a testsuite, but remains in the
tree to assist in the migration to use winbindd (it appears to be at the
right layer of abstraction for that future use case). 

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

> The question was -- what does the gensec call via imessaging
> gain us in this particular place? Don't get me wrong, I
> kindof got over my objections against gensec. It might have
> its place, and we will use it more and more. It's the
> particular use of it in auth_samba4 that I would like to
> understand the reasoning for.

The NTLM authentication code calls use imessaging for the 'please fetch
the password for this RODC' hook and talking to winbind for NTLM
authentication (the member server case, used by openchange).  The
generic authentication code (also called for Kerberos logins) also uses
this to contact winbind4 for idmap results. 

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.  

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.

I hope this clarifies things,

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba