On Thu, 9 Aug 2001, Devdas Bhagat wrote:
> On Thu, 09 Aug 2001, Marco Colombo spewed into the ether:
> <snip>
> > BTW, if really OpenLDAP 2 is build on SASL, you can't really get rid
> > of it. You'll have an IMAPD -> LDAP -> SASL (for authentication of
> > the LDAP client to the LDAP server) solution.
> This is what I'm asking for. Quite a few people are looking for
> something like this, from the traffic about LDAP.
> <Plain Text>
> The current implementation of SASL does not support remote
> connectivity.
[for password retrival / validation, you mean - it's true, that's
PAM or the pwcheck daemon job]
Of course SASL *implements* remote connectivity.
Even OpenLDAP supports remote connectivity *by means* of SASL.
> What most people are looking for is a way to connect to a remote SASL
> database with minimal configuration.
> The problem with the current design of imapd is that it assumes that
> SASL will be available locally in some form, ignoring that it may not
> be available there.
Uh? SASL knows nothing of where passwords are stored. It's an API for
client/server application to perform authentication over the network.
The client declares itself as a SASL client, the server as SASL server,
and the authentication happens in a transparent (modular, runtime
configurable) way. How an auth method validates the passwords the SASL
engine doesn't know/care.
> Do the pwcheck daemons provide support for this? The SASL database is
> not directly available locally, so a client-server type of application
> is required which can access SASL. If yes, I'll go with pwcheck or
> similar, else either a server has to be hacked into SASL and a client
> in the implementation (not what I like, I would be using kerberos if
> that was ok), or change imapd so that hooks for other methods can be
> easily added in.
Why change imapd? Why change SASL? Just write a pwcheck daemon that
speaks LDAP. First, it's much easier. Second, all SASL applications
will (automagically) use it, even OpenLDAP itself. If you change IMAPd,
I'll need to change sendmail, because I share the passwords between
the two. SASL is *precisely* an API to isolate applications from
authentication methods details, and you're proposing to hack imapd
to implement "hooks for other methods can be easily added in", which
is *exacly* what SASL does. IMAPd already has those hooks, the SASL
API.
Complaining that the default mechs provided with SASL are too naive
for you its just like complaining that the example html pages included
into the apache distribution do not fit your needs. SASL allows you
to write your own auth mech as a plug-in, and add it to all SASL
applications (IMAPd, sendmail, OpenLDAP, whatever), without even
recompiling them. The default mechs support naive /etc/sasldb,
system getpwent(), PAM, a simple pwcheck daemon as password validation
systems. Thru PAM you can authenticate over the network (NIS, LDAP,
other directory systems). If PAM isn't enough, link the pwcheck
daemon against whatever library you like. The default one uses
getpwent() system libraries, and on some systems it can be used to query
an LDAP server, too.
> </Plain Text>
> I cannot make it simpler than the above.
Me neither.
> <snip>
> > Or they can be "clients" of a simple local /etc/sasldb database.
> > The point being that I see no design flaw here.
> My point being that it is not easy to hook these into imapd.
My point being that IMAPd uses SASL hooks. You hook new mechs into SASL,
(place them into the plugin directory) and suddenly all SASL applications
become aware of it. How cat it be better that this?
> <snip>
> > So use/write a pwcheck daemon. Or a PAM module, it that fits better.
> I'll probably have to do one of these things :(.
The PAM module it's already there.
> > Still I see no reasons you should modify all SASL mechs to be LDAP
> > clients instead of using one of the above methods - but you can do it.
> Thats not what is being asked for.
> Let me put this in another way: From my POV SASL is currently like MS
> Access, great for everything on one machine, but not for much else.
SASL is all about client / server dialog.
> What I need is a slightly more featured software, like MS-SQL server,
> which can be contacted from over a network.
You want LDAP, because the passwords are stored on the network, but
you don't realize that LDAP libraries are just a SASL application
in order to perform network authentication. How can you say that
SASL is "everything on one machine" when even the solution you're
advocating uses SASL to implement network connectivity (well, the
initial part of it)?
> Hopefully, someone has already implemented this, else thats yet another
> thing to be done.
You just need the pam_ldap bug being fixed. Probably a SASL bug, possibly
triggered by either IMAPd or OpenLDAP "unexpected" behaviour (unexpected
by the Cyrus SASL library developers, of course). I see no (other) need
to modify IMAPd.
>
> Devdas Bhagat
> --
> Genius is pain.
> -- John Lennon
>
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ [EMAIL PROTECTED]
