your s3-auth branch

[tridge at samba.org]

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.

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

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.

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. 

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.

 > 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.

 > 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.

 > > 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?

Cheers, Tridge