your s3-auth branch

[Andrew Bartlett]

On Thu, 2010-08-12 at 15:51 +0200, Andreas Schneider wrote:
> On Wednesday 11 August 2010 01:23:24 Andrew Bartlett wrote:
> > Andreas,
> 
> Hi Andrew,
>  
> > After gd mentioned your work on IRC, I took a look at
> > http://gitweb.samba.org/?p=asn/samba.git;a=shortlog;h=refs/heads/s3-auth ,
> > and I have to say I'm a little confused (as is to be expected with a work
> > in progress).
> 
> I've started working on it and then got sidetracked by other stuff. When I got 
> back to work on it again more problems arised. The initialization of 
> structures and services inside of smbd showed some problems. So I had to test 
> and reoder some stuff to actually be able to access the rpc services in the 
> auth code.
> 
> > Rather than have me jump to conclusions about what you are trying to
> > achieve, I wonder if you might outline your plans?
> 
> The plans for the next days/weeks for gd and me are:
> 
> * implement NullSecureChannel and MsvApSecureChannel netlogon seruce channel
>   types.
> * migrate auth_sam to samr/netlogon

What is the benifit to having the auth subsystem call netlogon, to have
it call the auth subsystem again?  I could understand (if not agree
with) moving it from passdb calls to samr lookup calls, but why force
this via netlogon, with the limitations that imposes?

I am concerned that the double-pass via the auth subsystem will
introduce issues around the username mapping, for example. 

That said, if you want to have it call netlogon, isn't auth_netlogond
already written?

Remember, the auth interface is richer than netlogon.  I remember
wanting to do this very thing (following the TNG design) when I first
joined the team.  I even made grand proposals along the same lines, with
the same motivations.  The current scheme isn't perfect, but it wasn't
selected out of ignorance. 

My concerns about trying to shoehorn everything via Netlogon is that you
cannot do anything Microsoft didn't think of:  In particular, you can't
check IP address lists for example.  Now we don't do this at the moment,
but once we rework all the code, we will have to live with those
restrictions. 

Authentication is an important central part of Samba, and an area where
folks have looked for Samba to provide more, not less flexibility than
the Microsoft equivalent.  For example, Apple was able to write an auth
module to completely abstract the challenge/response handling, and some
sites still rely on the horrid 'security=server'.    

> * replace 'struct samu' with 'struct netr_SamInfo3'

Isn't this largely complete for the auth subsystem?  Or do you mean in
the passdb layer?

For auth, I would not really want to see it go much further - there are
other details that are important to track here, that are not in this
very particular structure, as the previous rewrite found. 

For passdb, it was originally started with the idea that all we would
ever need is the userinfo21 structure.  It became the current structure
out of need and flexibility. 

> * check if there is other stuff that can be migrated to use dcerpc.

I see great value in the use of IDL structures, particularly where
wrapped in Samba-specific structures that provide the additional
information or flexibility that we may need at any point (as the auth
system uses for the struct server_supplied info).

Perhaps it's hard to see the benefits without running code, but I would
caution you that I disagree with the approach, both in principal for the
reasons outlines, and because as I feel it may be contrary to the work
I'm trying to peruse to merge the authentication stacks.  I would ask
that you work with me to merge these before they diverge further apart. 

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100813/31799870/attachment.pgp>