your s3-auth branch

Andrew Bartlett abartlet at
Thu Aug 12 18:15:23 MDT 2010

On Thu, 2010-08-12 at 04:09 -0600, idra at wrote:
> On Thu, Aug 12, 2010 at 04:30:19PM +1000, tridge at 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.


Andrew Bartlett

Andrew Bartlett                      
Authentication Developer, Samba Team 
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: <>

More information about the samba-technical mailing list