I think it is ontopic for the list.

----- excerpts from message from Ivan Popov <pin_at_medic.chalmers.se> -----

... using LDAP as a trusted database and let client hosts to check
if a supplied password is the same as in the database.

You could write (or convince myself to :) a Coda clog authentication module
for the client and a corresponding one as a server.
The LDAP part could be totally encapsulated by pam_ldap on the server,
but the module would have to establish a protected link between the client
and the server, as the passwords are used in the clear.

The difference compared to using LDAP-stored passwords for host login
is that the passwords have to be checked not on the client host,
but on a Coda authentication server.

> ... do the same with coda.

You can reuse the same password, if you like - but as I am trying to describe,
it would imply creating some tools which are missing.

The reason it is not yet implemented is that we don't like cleartext passwords.
You get all the issues concerning the authenticity of the authentication server
itself, have to either trust the IP number or use some kind of certificates.

Note that this "troublesome" business is totally unrelated to LDAP,
it has to be there for any use of cleartext passwords.

I do not see any technical hinders to implement the missing parts,
though I would rather suggest moving away from the technology, not from LDAP
as naming service, but from using cleartext (or hash which is equivalent
in that context) passwords.

Otherwise the best way to ensure the cleartext password authentication
(protected of course) is available for Coda is to fund the effort.
If there is a use for this feature, why not?

Best regards,
--
Ivan

----- End forwarded message -----