your s3-auth branch

[idra at samba.org]

On Fri, Aug 13, 2010 at 02:22:52PM +1000, tridge at samba.org wrote:
> Hi Simo,
> 
>  > It offers the flexibility of a stable API, meaning anyone can do
>  > long term investment in code without everything changing
>  > underneath.
> 
> This is not flexibility, it's API stability.

OK, it really depends on the pov, but we can agree on calling it thois way.

> It also completely ignores all the other problems inherent with SAMR
> and LSA. Yes, they are stable APIs, but they are also terrible APIs!

Oh I know, but the point is that we have to implement them anyway, so it
doesn't really matter much,

> A simple example of where they are bad is locking. In the rework in
> the s3-auth code the new code commonly makes multiple
> SAMR/LSA/NETLOGON calls for a single logical operation. There is no
> locking at all between these, yet there are likely to be security
> consequences if a property of the user changes while one of these
> operations is happening.

The same happen for any member server or client using them, I am not aware
of any critical problem, but I understand the worry.

> It gets even worse when SAMR/LSA is used for operations where Samba
> needs to change something in its database. Then we need
> read/modify/write type operations, and with SAMR/LSA we have no way of
> doing that safely.
> 
>  > Look at our passdb interface. We used to have external modules maintained, but ultimately
>  > they disappeared because the interfaces kept changing.
> 
> look at what Microsoft has done with SAMR and LSA. It is now a mess of
> dozens of info levels and call varients. 

Again my point is that we have to implement them anyway, so it does not change
our work, but it does increase our code coverage and testing if we use them
internally.

> Then have a look at what Microsoft has been doing recently with domain
> join. They are starting to abandon these RPC interfaces in favor of
> LDAP. In a couple of years I would not be surprised if a join had no
> SAMR/LSA/NETLOGON RPC calls at all.
> 
> Why are they abandoning these interfaces? I think it is precisely
> because they are inflexible. With a LDAP style interface when you need
> a new attribute on a user you can add that attribute without impacting
> existing users at all. In the server you don't need two code paths,
> one for old users and one for new users. In the client you can make
> use of the new attribute or not, as you wish. If you do want to use
> the new attribute you can also easily tell if the server implements
> it without having to do the "try this varient, doesn't work, try that
> varient, doesn't work, try another variant etc etc" approach that is
> the hallmark of RPC.

LDAP has advantages but also great weaknesses. When problems are confined I ultimately
think an RPC mechanism is safer. With LDAP you can be very lazy and generally get
away with it, but when you need very rich interactions the price you pay is that
you start killing the very flexibility of LDAP. We already see that MS prevents
removing schema, and the tree is fixed in stone forever. The more we go on the more
this interface will be full of defunct attributes you need to keep around or in sync
because there may be clients around using it. With RPC you can at least mark some
calls as obsolete and simply return an error when they are called.

But my preference here matters very little, although DC joins will keep going the LDAP
way, there are still a ton of RPC interfaces to deal with NTLM authentication, trusts,
and other things that will hardly go away, given they are the means through which
windows machines resolve stuff internally as they completely abstract out what is the
information provider. Only the lsass and netlogon daemons have to care aboutb the
details.

>  > 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 you advocate moving to a fixed API (in fact 3 APIs, SAMR, LSA and
> NETLOGON) because of its stability, but already need to add new APIs
> because it can't handle all the pieces we need.

Yes, I tend to be pragmatic :)

>  > The AD DC case is completely different and that one can always use LDAP at any
>  > given time.
> 
> which means these changes may end up making our current effort of
> unifying codebases harder.

Actually I think it will make our efforts much simpler. Once the file server and
printer server code use RPCs, then using S4 lsa and samr pipes will be a matter
of flipping a switch. S4 implement those intercafes already so the file server
will simply be able to use them directly as the API is the same and guaranteed
to be so by the fact we have to make it right for the Windows clients too.
This means file server and printer server development can keep going on their
own with little interaction with other parts of the code and rest assured they
are not broken by sudden changes in interfaces in other parts of the code.
Last ans not least it will make super simple to completely shutdown and even
compile off parts of samba because we can make each daemon much more contained,
this is one of the features OEM keep begging us for.

I see this as a win win win strategy to handle all our contrasting needs.

The need for S4 development on the DC side to go on with lax rules as it is still
struggling to implement a lot of missing DC functionality w/o impacting the
stability of the pure file server. The ned for the simple member server to keep
being stable for the current users. The need for OEMs to include only the deamons
and functionality they really need, and compile off anythinbg else. Etc...

>  > > 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.
> 
> why? You've given lots of reasons why you like SAMR, and while I don't
> agree with them at least they involve some thought about the
> problem. Can you explain why LDAP like interfaces are worse?

The DC, and by that I mean LDAP server, KDC server, repliacation engines, etc.
Do need more flexibility. A pure member server does not, it's not a point of LDAP
being better/worse, read above my reasons to pursue this strategy,

Simo.

-- 
Simo Sorce       idra at samba.org
-------------------------------
Samba Team http://www.samba.org