Hi Philip,
Thank you for your elaborate feedback. Comments inline.
On 02/19/2013 03:42 AM, Philip Guenther wrote: [snip]
"We need to protect corporate data in LDAP from being modified or even accessed by untrusted resources.
Yes.
[snip]
"Because some of the applications cannot be configured to bind non-anonymously but they all (except for that one) _can_ be configured to always use StartTLS and provide a client certificate, we want to require that all ldap:// connections use the StartTLS operation with a client cert before performing any LDAP operations that access or modify data.
Yes. Client certificate authentication is used everywhere where possible (for things like corporate web access, email, VPN).
(That's a complete guess and probably not your real reason. Client certs are just another form of secret which are, IMO, a bigger pain to generate and manage.)
Thankfully the security overlords who came up with this one are also the ones who have to generate and manage the certs :-)
[snip]
Well, for starters, the peername.ip="127.0.0.1" clause does *NOT* match ldapi:// connections. It matches ldap://127.0.0.1/ and ldaps://127.0.0.1/ connections.
I did not try to use ldapi with this setup. I used ldap on 127.0.0.1. Sorry if that was not clear.
[snip]
In what way is an ldapi:// connection insecure? It's a UNIX domain socket for which the data never goes over a physical net and that therefore cannot be snooped. That's *MORE* secure than a TCP connection secured with TLS! You can even authenticate it via the uid and gid of the process that opened the connection!
Agreed. The authentication via uid/gid is a nice one I did not know was possible. Will look into that.
Anyway, if you want to permit only a) read-only ldapi:// connections and b) ldap:// connections using TLS w/client certs
then *I think* you can do that with three options in the config:
# require clients that clients that do TLS provide a client cert olcTLSVerifyClient: demand # treat ldapi:// connections as at least as secure as a 256bit cipher olcLocalSSF: 256 # require connections to be at least as secure as a 256bit cipher to do # anything at all (the "ssf=256") clause, and specifically require that # they be using TLS (and not just ldapi) with 256bit cipher to do updates olcSecurity: ssf=256 update_tls=256
Your example had me stumped. Upon reading the olcLocalSSF section again I realized I made a mistake. Although it says "Specifies the Security Strength Factor (SSF) to be *given* local LDAP sessions" my mind munched it into "Specifies the Security Strength Factor (SSF) to *require* for local LDAP sessions". Obviously setting it to 0 did not help... Staring at the screen too long I guess. So thanks for making me read the man page again :-)
But I haven't tested it.
Works like a charm.
[snip]
Yes, an unconditional "require blah" should be taken to be unconditional.
Duly noted.
Thank you very much for all your help and enlightening comments. Much appreciated.
Regards, Patrick