your s3-auth branch

[Andrew Bartlett]

On Thu, 2010-08-12 at 04:09 -0600, idra at samba.org wrote:
> On Thu, Aug 12, 2010 at 04:30:19PM +1000, tridge at samba.org wrote:
> > Hi Simo,
> > 
> >  > 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.
> > 
> > yes
> > 
> >  > The RPC interfaces are set in stone and we always need to get them right anyway, so using
> >  > them allows us much more flexibility.
> > 
> > I don't follow that logic. How does a "set in stone" API offer
> > "flexibility" ?
> 
> It offers the flexibility of a stable API, meaning anyone can do long term investment in code
> without everything changing underneath.
> Look at our passdb interface. We used to have external modules maintained, but ultimately
> they disappeared because the interfaces kept changing.

OK, so your argument if for API stability, not 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.
> > 
> > and when the time comes that you want an attribute of the user that is
> > not exposed over SAMR or LSA (there are plenty of those!) then what do
> > you do?
> 
> For a member server or a standalone server or even a NT4 DC there aren't many.
> Only some and mostly related to getting unix attributes for users. We can
> define a unix-rpc pipe with a set in stone interface to get only those
> attributes that we really need.

So, instead of having two interfaces - one internal and one external
layered on top, we now need two anyway, but without a sensible link
between them and with duplication of lookup costs?

> The AD DC case is completely different and that one can always use LDAP at any
> given time.
> 
> >  > 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 up.
> > 
> > yes, the auto-generated nature of RPC with IDL is great, but the fixed
> > nature of SAMR/LSA in a world where the actual attributes of users is
> > changing isn't.
> 
> The attributes we need in a member server really never change, we need an info3
> struct and the additional unix posix attributes.
> 
> > If we want to use an externally defined API and we also want to ensure
> > we can support all the user attributes that we will need into the
> > future then really we need to choose LDAP.
> 
> In general it is a fine choice for an AD DC, not for the other cases IMO.

I'm concerned that just as you feel that the AD interfaces are
over-broad, that limiting ourselves to what Microsoft has chosen to
expose over SAMR and LSA is to limiting.  The example of the missing
primary group in enumdisplayusers is the classic case. 

I would ask that in the area of authentication, that we do not make such
fundamental changes while we are still trying to reconcile the two
authentication stacks.

Thankyou,

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/30311c19/attachment.pgp>