Robert,

please stay on the openldap-software list. Cc:-ed it again.

Robert Henjes wrote:

That's right. Concluding your recommendations and comments:

• ldaps is best choice for a public reachable LDAP server, when secure

transmission is required

IMHO yes. StartTLS is ok too if the number of client configurations is rather low (e.g. services configured by admins) since then problems are sorted out during integration testing. If you have many LDAP clients with normal end-users there's not much you can do.

• client certificates are not recommended for use, when a client (not

always interactive) service has to verify its authentity / authorization to access the ldap service in general.

Yes.

Alternative solutions:

• Using a bind user with shared password

I'd recommend to give each service (e.g. Linux boxes with pam_ldap etc.) a different bind-DN and password. Then if one services is compromised it does not affect the others. It also provides better monitoring.

Because normally such services use simple bind you can store the userPassword value in hashed form in OpenLDAP.

• Limiting client IP addresses by system network services or ACLs
• ... any other mechanisms?

ACLs with IP addresses are not an option if you want to keep network configuration independent of the directory configuration. If you are responsible for both that might work.

...

...

Possible solution: The server only responds to unencrypted requests on the local interface. How can I achieve this?

Start slapd with appropriate parameters for command-line option -h for LDAP on localhost and LDAPS for remote connections.

Tried this, but all instances (different ports) had at least TLS encryption with the enabled TLS feature.

What about this?

slapd -h "ldap://127.0.0.1 ldaps://0.0.0.0"

Ciao, Michael.