your s3-auth branch
abartlet at samba.org
Thu Aug 12 18:15:23 MDT 2010
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
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
Size: 190 bytes
Desc: This is a digitally signed message part
More information about the samba-technical