your s3-auth branch
idra at samba.org
idra at samba.org
Wed Aug 11 02:53:54 MDT 2010
On Wed, Aug 11, 2010 at 09:23:24AM +1000, Andrew Bartlett wrote:
> On Thu, 2010-07-29 at 18:03 +1000, Andrew Bartlett wrote:
> > On Thu, 2010-07-29 at 08:46 +0200, Andreas Schneider wrote:
> > > On Wednesday 28 July 2010 23:48:36 simo wrote:
> > > > > This decision is a bit
> > > difficult to make without seeing the
> > > > > code changes that are blocked by
> > > it. While it works and does
> > > > > not conflict with anything else, I would say
> > > keep it. If you
> > > > > have something in the pipeline that would become
> > > > >
> > > significantly easier if it was dropped, I think we should
> > > > > look more
> > > closely at the benefits of having either.
> > > > >
> > > > > Does that sound
> > > reasonable?
> > > >
> > > > Yes, absolutely.
> > > >
> > > > I will let Andreas comment on that
> > > though.
> > >
> > > I know that there are old clients, but this code is that a password
> > > gets automatically migrated to a hashed password during login. If someone
> > > wants to have this migrated, I think he probably did it in the past 9
> > > years.
> > Indeed.
> > > Well the plan is to change the auth code to use samr/lsa/netlogon
> > > instead of directly accessing passdb.
> > I know this is the current fashion to migrate everything to IDL
> > interfaces, and I've seen great benefits in doing so, I'll note that
> > there is also a particular cost.
> > Some auth modules allow the challenge to be specified (this is something
> > that security=server does, and which modules like apple's open directory
> > plugin uses, as I understand it). The netlogon API does not provide
> > this ability.
> > I will be a little harder to get hold over the next little while, but I
> > would appreciate it if I could be consulted on plans to change the
> > structure of the auth subsystem.
> 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).
> Rather than have me jump to conclusions about what you are trying to
> achieve, I wonder if you might outline your plans?
> I would rather work with you early to get this right than object after
> you have put in great efforts here.
> Passdb may not be the world's best API, but I think that some of the
> efforts currently going into forcing everything via SAMR and LSA are
> similarly misguided. Why shoehorn all our code into just another legacy
> API, when we are trying to move to being an AD DC (where these are
> simply a front-end to another DB).
Because the AD DC case is not the only case we need to support, there is the NT4 style DC,
the member server, the standalone server and probably more.
The RPC interfaces are set in stone and we always need to get them right anyway, so using
them allows us much more flexibility. We can use a samr daemon/implementation in the AD DC
case and another one in the member server case. And I plan to use yet another implementation
or something based on the current ldapsam in S3 for my trust-rel work in IPA.
RPC interfaces makes any of this *much*, *much* simpler, and avoid layering leaks and
shortcuts that made our code such a mess in the past and we are still fighting to clean
Simo Sorce idra at samba.org
Samba Team http://www.samba.org
More information about the samba-technical