I am trying to take advantage of the localSSF option in OpenLDAP 2.4. This system will only allow one user to login and I like to leave a door for me to get back in if I forget the admin password.
My goal is to get the local socket running with no security and require anyone using a TCP connection to use TLS with at least a 3DES cypher. I would prefer updates happen over a higher grade encyption, but eh....
In doing so I have put the following in my slapd.conf
.....
localSSF 0 sasl-secprops noplain,noanonymous,minssf=112 security ssf=112 update_ssf=128 simple_bind=112 tls=112
####################################################################### # Specific Backend Directives for hdb: # Backend specific directives apply to this backend until another # 'backend' directive occurs backend hdb
......
It seems I have done something a great deal wrong. The system is now enforcing strong authentication over ldapi:/// this is the exact opposite of my plan.
What on earth did I do wrong?
Pat
Debian Etch, packages from sid.
My bad, read the doc backwards....
Thanks!
Pat
On Thu, 2008-01-31 at 18:11 +0100, Hallvard B Furuseth wrote:
Pat Riehecky writes:
localSSF 0
This says ldapi:/// connections receive security factor 0. You need localSSF 128 or better, to match your highest ssf:
sasl-secprops noplain,noanonymous,minssf=112 security ssf=112 update_ssf=128 simple_bind=112 tls=112
Pat Riehecky prieheck@iwu.edu writes:
I am trying to take advantage of the localSSF option in OpenLDAP 2.4. This system will only allow one user to login and I like to leave a door for me to get back in if I forget the admin password.
My goal is to get the local socket running with no security and require anyone using a TCP connection to use TLS with at least a 3DES cypher. I would prefer updates happen over a higher grade encyption, but eh....
In doing so I have put the following in my slapd.conf
.....
localSSF 0
default localssf is 71. [...]
-Dieter
openldap-software@openldap.org
-
Dieter Kluenter -
Hallvard B Furuseth -
Pat Riehecky