I know this is a necro-bump but I am looking for testers. I have modified the Directory Server app to allow access to port 389 as well as 636 through the webconfig. Please see the screenshot attached. If you would like to test, please do:

yum update app-openldap-core --disablerepo=* --enablerepo-clearos-updates-testing

All I know is from a little digging and google.

Perhaps setting the immutable bit on prestart.sh (chattr +i prestart.sh) will need to be done to stop changes being overwritten but that carries its own dangers.

hi Peter,

Initially that's where I had set the URLs, in /etc/sysconfig/slapd, after restarting slapd service, port 389 was still only open to localhost.

Hi all,

@ Nick - you know waaaay too much about ClearOS :-)

The prestart.sh file will get overwritten on the next OpenLDAP update from upstream, so another option is to set the URLs in /etc/sysconfig/slapd. The documentation in the file has the details.

# Where the server will run (-h option)

# - ldapi:/// is required for on-the-fly configuration using client tools

#   (use SASL with EXTERNAL mechanism for authentication)

# - default: ldapi:/// ldap:///

# - example: ldapi:/// ldap://127.0.0.1/ ldap://10.0.0.1:1389/ ldaps:///

# IMPORTANT: see BIND_POLICY below

SLAPD_URLS="ldap://127.0.0.1/ ldaps://192.168.55.208/ ldap://192.168.55.208/"



# ClearOS - In order to provide sane support for network card roles,

# the BIND_POLICY parameter auto-configures the SLAPD_URLS parameter.

# For example, BIND_POLICY="lan" will set SLAP_URLS to all the LAN

# IPs (nothing listens on DMZs or WANs).  If you would like to avoid

# SLAPD_URLS auto-configuration, set BIND_POLICY="custom".

BIND_POLICY=custom

One word of caution: if you ever change the IP address configured for the LDAP server (192.168.55.208 in the example configuration above), you will need to update this file. LDAP will refuse to start up if it can't bind to the configured IP addresses. This is a common gotcha when doing a configuration restore on another machine or in a VM.

hi Nick,

Just tested editing that file and it works...

if anyone sets the bind_policy to all or localhost instead of lan then should edit the urls under those policies. Hard coding your static ip address of your server instead of 127.0.0.1 will also work but will mean you'll have to edit the file again if you ever change your ip.

Thanks again for your help!

The advantage of leaving ldap on 636 is that you can have more flexibility - you can support self signed certs and SSL with commercial certs, but on 389 you only have one connection choice.

hi Nick and Duncan,

Thanks for your suggestions.

Duncan - yes when I tell Zimbra to ignore the untrusted cert then connection is accepted and the Zimbra accounts are authenticated using ClearOS.

Nick - I'll also try your suggestion to see whether port 389 will be open to Local LAN. Though it works by forcing Zimbra to accept the certs, for my own peace of mind and curiosity I still want to try the suggestion, plus get to learn where ClearOS 7 now stores these files

Thanks again to both of you..

Hi Pascal

As security is not essential can't you tell Zimbra to ignore the untrusted SSL cert, then you can use a self signed cert (from ClearOS)

su - zimbra
zmlocalconfig -e ssl_allow_accept_untrusted_certs=true
zmlocalconfig -e ssl_allow_untrusted_certs=true

This is from link below

https://wiki.zimbra.com/wiki/Self-Signed-CA-SSL-CRT

ClearOS7 uses system now rather than the init daemon to start and stop programs so the start up scripts are different and elsewhere. I'm not at my system, so, from the command line do a "service slapd restart". You will see some sort of message referring to the systemd start up and it will give a clue to the systemd init file equivalent. Track this file down with the "locate" command and that is probably where you'll need to apply Tim's hack.

hi Duncan,

That option would be the last resort. They would rather have any changes done on ClearOS since it's a new server as opposed to the mail server i.e. Zimbra Network Edition 8.6, which will require certificates from ClearOS to be imported into Zimbra otherwise it'll throw an error when connecting to port 636 due to untrusted ssl certificate. I've installed both servers on my virtual environment to test that way I don't mess around with the production servers till am sure the connection will work either on port 389 or 636.

Thanks.

Hi Pascal

Would it not be easier to get the client application to use LDAPS on port 636?