your s3-auth branch

[Andrew Bartlett]

On Fri, 2010-08-13 at 00:51 -0600, idra at samba.org wrote:
> 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 isn't the same as a member server, as no member server uses SAMR to
obtain passwords.  

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

As I will elaborate below, this assumes that the APIs are sufficient for
our needs.  I disagree that they are, and disagree that we should wed
ourselves to them, particularly in authentication. 

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

I really don't see how this is any different on any protocol, but on RPC
the situation is actually worse:  The SAMR API does not allow clients to
specify what attributes it actually wants, but instead returns a fixed
set - meaningful or not, complete or not.  

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

Unfortunately this is only the case if we wish to do exactly what
windows does, as well or as poorly as windows does it.  Our users have
come to expect something different, for better or worse.  For example,
should we tell a high-security company that wishes to restrict users by
IP address, or redirect their login attempts to a Heimdal KDC that not
only do we not support that now, but we decided that we wouldn't do
anything that Microsoft hasn't done first. 

Imagine we decided we couldn't do the unix extensions until Microsoft
got around to inventing them?

I'm not even confident that SAMR provides all the data we need for
authentication anyway - for example, my tests have shown that old
passwords are valid after a password change, but the password history is
not exposed in SAMR.  I've not yet implemented this scary concept, but I
would hesitate to create barriers to doing so in the future. 

> >  > 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 :)

Why is it pragmatic to create a mix of standard and non-standard APIs
that can't work together?  why not just implement coherent APIs that we
actually need - over an RPC mechanism if so required.

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

This then implies that we will maintain two distinct copies of quite a
large body of complex code, with layered interfaces.   

I certainly agree that the file and printer servers should meet the auth
subsystem at a simple, agreed interface.  That interface is the auth
interface. 

As regards other users, such as winbindd, I'm equally unsure that the
change to use RPCs was the right thing to do, as the SAMR API has always
been a poor match for some of our important calls, such as getpwent().
I'm currently investigating if the changes made to have winbindd
introduced a regression in the calculation of the primary group ID. 

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

Sadly is is not, and that is why I object to this approach.  

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

I'm sorry, I don't see how this is relevant at all.  I've already
demonstrated that the DC can provide an authentication module that does
not disturb the existing member server behaviour. 

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

This might be a reasonable strategy, except that is is proposed that the
'member server' code provide key elements of the domain controller.  As
such we cannot simply make decisions that are 'good enough' for a member
server, and then say that the AD DC has to make do with unsatisfactory
APIs. 

The idea that the RPC interfaces solve all our problems assume two
things:  That Microsoft solves their problems exactly this way, and that
we wish to solve only the same problems that Microsoft has solved, in
the way that they have solved them.  

We should move to common APIs that avoid layering leaks, and this I
believe is a hallmark of the work that I've done in the auth subsystem
and in things such as GENSEC, and I look forward to continuing to
advance work in this area.

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/20100816/70dfcbbe/attachment.pgp>