[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: forcing encryption for external server access while allowing unencrypted localhost connections
Howard Chu wrote:
But what if I'm not accessing any object? What if I'm just doing
a bind (e.g., using LDAP to check credentials - which happens all
the time in real-world deployments)? If, e.g., it's a SASL bind
and the server is set with a bind_ssf, then I believe your ACLs
won't have any effect.
In that case, then it doesn't seem to matter one way or another. If the
SASL bind uses independent credentials (e.g. SASL/GSSAPI or
SASL/EXTERNAL) then the authentication is already encrypted. If the SASL
bind uses secrets that are stored in LDAP, then the ACLs will take
effect.
Sure. But suppose I have an enterprise authentication system based
on, say, Netware, or on a Radius server, etc., and I need to configure
LDAP to use saslauthd, and have saslauthd simply to refer credentials
on to PAM, which will utilize the authentication flavor of the day
(Radius or whatever).
In this case I must allow PLAIN or LOGIN SASL and then simply pass
credentials on as-is. I.e., in this case I'd need to rely on the
security of the connection itself (e.g., whether it's over a Unix
socket, a local interface, or it's encrypted), rather than on any
inherent protections in SASL.
It's not at all far-fetched, I don't think - again, assuming I'm not
misunderstanding.
Also, I believe it would be nice for sysadmins to alter the currently
hardcoded SSF assigned ldapi connections (71). It really should be
up to the local systems and networking people to determine what sorts
of connections (ldapi, local interfaces, etc.) get what baseline SSF
values, because it all depends on the security of the network, the
machine, of particular interfaces, routes, etc.
I think it's pretty clear what you're asking for. But it's not clear
that the alternative spelled out above won't address the need.
I'm trying :-). So is Chris.
--
Richard Goerwitz richard@Goerwitz.COM
tel: 507 645 7015