your s3-auth branch

Mon Aug 16 01:14:14 MDT 2010

Am 16.08.2010 01:29, schrieb 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.

I think that we should have our own api here, over rpc or over the
winbind pipe (or both).

I think we should have a gensec module that just forwards blobs over a
protocol
to the auth server, it would then also specifc if it needs a nt token
and/or an unix token.
and if local group memberships should be expanded or not. The file
server would need both tokens,
while a webserver would need no token. And a registry server would only
need the nttoken.

Which gensec modules are used should be selected by the server
credential handle
and the gensec_start_server() function should take the credential handle
instead
of globaly configured backends.

Then the file server would have a different server credential handle
than the auth server
(which would use the current modules).

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

I think it would be much better if gensec would be the only interface,
and the auth interface would be hidden to the callers. We can easily write
new gensec backends which tunnel things like plaintext auth and other
things.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100816/4860b87f/attachment.pgp>