Application Delivery Management
Application Modernization & Connectivity
CyberRes
IT Operations Management
How to secure/encrypt communications between MFDS and an OpenLDAP repository using SSL.
OpenLDAP needs to be configured to work with SSL certificates so it can establish communications over an SSL connection.
Once OpenLDAP is configured for SSL, MDFS needs to be setup to connect to OpenLDAP using the SSL port.
This article explains how to setup openLDAP for SSL to allow an SSL connection from an External Security Manager (for MFDS or ES).
Once OpenLDAP is configured for SSL, MDFS can be setup to connect to the OpenLDAP SSL port so that communications between MFDS and OpenLDAP will be encrypted.
OpenLDAP can be installed on both Unix or Windows and ES/MFDS can be running on Unix or Windows. Both OSs are taken into account.
Note that the certificate examples used here are those generated by the DemoCA utility.
OpenLDAP can be configured to work with SSL certificates and hence can be setup for SSL communication.
The SSL communication will take place over the SSL port. 636 is the default SSL port which is set at install time.
# slapd server certificate file:
TLSCertificateFile ./secure/certs/srvcert.pem
# File that contains the private key matching the certificate stored in TLSCertificateFile:
TLSCertificateKeyFile ./secure/certs/srvkey.pem
# Certificate file for the CA that signed the server certificate (the PEM-format file containing certificates for the CA's that slapd will trust):
TLSCACertificateFile ./secure/certs/CARootcert.pem
If slapd is currently running it should be terminated.
To listen on SSL (as well as the non-SSL port) run the following command.
slapd -d 1 -f slapd.conf -h "ldaps:/// ldap:///"
When slapd starts, it will read the certificate and key files and will prompt for the key/password (srvrootpwd) – it will only continue to start successfully if this is entered correctly.
(See Appendix A for running ‘OpenLDAP-slapd’ in the background when configured for SSL)
It is necessary that the LDAP provider used by MFDS ‘trusts’ the certificates used by openLDAP. Thus the Certificate Signing Authority that signed the certificates in use by OpenLDAP (DemoCA in this case) must be known to the ldap provider library. For this to happen, the correct CA Root Certificate needs to be made available to the ldap provider.
The usual way to configure TLS (SSL) for the OpenLDAP client library on Unix is to create or edit the user's ~/.ldaprc file. That has various TLS-related settings. For example:
TLS_CACERT /path/to/CA-certificate.pem
Other settings are available. See the OpenLDAP documentation for more information.
Once the certificates are setup correctly, mfds should be restarted.
It should now be possible to “Secure MFDS with SSL to OpenLDAP” (see below).
For windows, the Trusted Root Certificate must be added to the Windows Certificate store for the account that is running MFDS (as this is the context in which the loaded mldap provider will be running in).
For the default situation of MFDS running as a service under the Local System Account, it is necessary to add the root certificate to the ‘computer account’ in the Windows certificate store. See Appendix B for the procedure to do this.
Alternatively, if MFDS is run from the command line (e.g. for testing), Internet Explorer can be used to add the Trusted Root Certificate (CARootCert.pem) to its Trusted Root Certificate store – this certificate will be then available to the current user. When MFDS is then restarted under this current user’s account, it should have access to the Trusted Root Certificate.
MFDS should then be stopped (whether it’s currently running from the command line or as a service) and then started from the command line:
Start mfds [–d]
Where ‘-d’ would provide additional debug information.
It should now be possible to “Secure MFDS with SSL to OpenLDAP” (see below).
Once the Root certificate has been made available to the mfds process, the ldap provider client library should be able to access this root certificate when it needs to validate SSL requests/certificates.
MFDS should now be setup to use an OpenLDAP SSL ESM definition to connect to the OpenLDAP repository using SSL.
The SSL ESM definition contains almost the same information as a non-SSL ESM definition setup (including the ‘provider=’ line if MFDS is on Unix) except the ‘Connection Path’ which is now adjusted to use ‘ldaps://’ (instead of ldap://) and additionally specifies the SSL port that openLDAP repository has been configured to listen on (636 by default):
Name: openLDAP
Module: mldap_esm
Connection Path: ldaps://<OpenLDAP_Machine_Name>:636
Authorized ID: cn=Manager,dc=my-domain,dc=com
Password: ****************
Configuration Information:
[LDAP]
Provider=/lib/libldap_r-2.4.so.2
BASE=CN=Micro Focus,dc=my-domain,dc=com
user class=microfocus-MFDS-User
user container=CN=Enterprise Server Users
group container=CN=Enterprise Server User Groups
resource container=CN=Enterprise Server Resources
bind=simple
[Verify]
Mode=MF-hash
Note: The ‘Provider=…’ line is only required for Unix (where it should point to a valid LDAP provider client library for the machine that mfds is running on). On Windows this line should be removed or the ESM will fail to initialize (removing this line allows MFDS to load the default Windows mldap provider library, which is the desired behavior).
From the ‘MF Directory Server’ tab:
If there is an error instead of the ‘Initialized OK’ message, 1st verify that MFDS can be initialized using a non-SSL ESM configuration to the same repository. This would use the non-SSL port, by default 389, and would have ‘ldap://’ instead of ‘ldaps://’ for the connection path. This would verify that all the parameters in the ESM config, along with the Authorized ID and password, are correct (as it will be using/accessing exactly the same OpenLDAP repository partition).
If the SSL-ESM doesn’t initialize correctly, the relevant certificates should be checked to ensure they are in the correct location and that they contain the information that is relevant to the machine on which they are being used.
When the slapd daemon process was run as above, it will have been running interactively under the user’s account. When started automatically it will run non-interactively in the background.
Since openLDAP is configured for SSL it currently requires a password for the keyfile on startup. However when running non-interactively it is not possible to enter the password interactively. One way to allow the slapd daemon process to startup non-interactively is to remove the password from the keyfile which will prevent the prompt for the password on startup. This is explained below.
openssl rsa -in srvkey.pem -out srvkeyNoPWD.pem
[Provide keyfile password (one last time!) when prompted]
Modify the following line in slapd.conf:
TLSCertificateKeyFile ./secure/certs/srvkeyNoPwd.pem
It should now be possible to start openLDAP to listen on SSL without any prompt for the keyfile password.
slapd -d 1 -f slapd.conf -h "ldaps:/// ldap:///"
There should be no prompt for a password when slapd starts up.
Log back onto MFDS (which will have been logged off with the error: “HS3408E Database error” when OpenLDAP was stopped) to verify that MFDS can still connect to this repository via the SSL ESM connection.
This is required to allow MFDS on Windows to run under the local system account.
The certificate should now appear in the list of certificates under the ‘Trusted Root Certification Authorities’ for this ‘local computer’.
The MFDS service should now be stopped and re-started after which it should be able to ‘trust’ the certificates that openLDAP sends.
It should now be possible to “Secure MFDS using the SSL ESM definition”.