RE: RE: Authentication Methods for LDAP - last call

[John Haxby <jch@pwd.hp.com>]

Alan Lloyd wrote:
[snip]
I also think that those who pronounce that 200,000 users on 1 LDAP
server should get a bit of reality into their argument. Does anyone on
this list that:
a) a 200,000 staff company running a commercial business will use 1 LDAP
server - that size of organisation will be distributed around - will
require redundant backups and will require connectivity to other
organisation's (trading partner) directory systems.

b) this company wants to have a server system say 5 or 6 of them where
they have to replicate everything in one to everything in another - and
also with their trading partners.
eg. Please buy 5 LDAP servers and then get 5 people to keep them in
sync. 



(jch) There is a deployed instance of OpenMail supporting 220,000 users 
across 10-20 servers (I foget the exact number, sorry).  Each server 
has a copy of the directory and the replication mechanism is such that 
it effectively forbids changes to directory entries not owned by the 
local server.  In this instance CRAM-MD5 would scale remarkably well.

There's talk of setting up virtual private networks to share 
information across enterprises (of which the directory is just a small 
part) and of making certificates available between the enterprises for 
the purposes of gluing together a PKI.  You don't need distributed 
authentication to make this work, authentication is usually only needed 
for changes to the data held locally on a server, not for retrieving 
public keys and whatnot.

CRAM-MD5 or something similar, is likely to work remarkably well in 
many environments.  Specifically, it will work well in an environment 
where authentication is only necessary or useful to modify locally held 
data.  In the less common complex distributed environments where access 
to certain data is controlled by authentication, then there is a clear 
need for a better, distributed authentication mechanism.

If a simple authentication mechanism is mandated for the common, simple 
installation then that is just fine.  The less common, complex 
installations are likely to need something better and would probably 
want to disable the simpler, non-scalable authentication mechanisms.  
But there is still a place for those simple mechanisms ...