Enable LDAP/LDAPS Auth on Green Interface

NethServer Version: 7.2009
Module: ns-directory

Greetings,

Trying to connect a remote PHP script that’s on the same Green network as Nethserver, to allow for LDAP authentication for an internal self service portal. The script is using AdLDAP2 (GitHub - Adldap2/Adldap2: A PHP LDAP Package for humans.).

I can’t get it to connect to Nethserver regardless of any changes I make. I’m trying to do this in a way without decreasing the amount of security on the Nethserver system as it’s used as a mail system/gateway, therefore has a direct connection to the internet.

Is there a way to allow this connection between the two servers or would it be more secure to create a lookup script to be hosted on the Nethserver system and have our script access that to provide look up and authorization?

Half the reason I am asking is that the main goal of this portal is to provide the users a place to go, and update their own Address, Phone Numbers, etc that are associated with their Active Directory accounts, that way we can generate “rosters” when needed.

I know this question is kind of middle of the road, half PHP support, half Nethserver support, but any insight would be greatly appreciated.

Hi @bradjtrammell

As you’re using AD (Not really LDAP), and you have a Mailserver running there:

Are you using LetsEncrypt?
Does your AD use LetsEncrypt?

Why I’m asking:

Most PHP and JAVA stuff using AD require a valid, working SSL cert.

LetsEncrypt allows aliases names.
Add your AD name to the LE alias and make sure it’s resolvable from external & internal DNS.
(Note AD itself does NOT need to be externally accessible, just the name and some website!).

If true, this will work:

Install LetsEncrypt SSL in AD

Create the needed script in the right directory:

nano /etc/e-smith/events/certificate-update/S80push2ad

Contents:

#!/bin/bash
cp -f -p /etc/pki/tls/certs/localhost.crt /var/lib/machines/nsdc/var/lib/samba/private/tls/cert.pem 
cp -f -p /etc/pki/tls/private/localhost.key /var/lib/machines/nsdc/var/lib/samba/private/tls/key.pem 
chmod 600 /var/lib/machines/nsdc/var/lib/samba/private/tls/key.pem 
chmod 644 /var/lib/machines/nsdc/var/lib/samba/private/tls/cert.pem 
systemctl -M nsdc restart samba

Exit with CTRL-x , save with y .

Set executable permissions on the script:

chmod 750 /etc/e-smith/events/certificate-update/S80push2ad

Then run the script at least once:

This will get you a working LE ssl cert on your AD (The same as your NethServer is using).
It will automatically update, whenever the LE script runs.

cd / 
/etc/e-smith/events/certificate-update/S80push2ad

My 2 cents
Andy

I wasn’t aware that AD could use a LE cert. I guess my question is, if my NS hostname is network.domain.com, and my AD domain is ad.domain.com, do I need a new cert specifically for ad.domain.com? If so, I do need to make that externally resolvable to get the LE cert, don’t I?

Additionally, will this affect the SOGo, Nextcloud, and Jabber configurations as they all link back to NS AD. Is this done over 389 with no TLS? Does the cert not matter for those services?

Nextcloud actually uses LDAPs/636…
I don’t use Jabber or SoGo, but I do use:

  • Zabbix
  • Roundcube
  • Guacamole
  • MeshCentral

AFAIK, the last two, Guacamole and MeshCentral, actually require this, to work correctly with AD…

All the above work with this…
Existing localhost or without SSL connections will continue working, only now also ssl connections will work!

My 2 cents
Andy

PS: Certain commercial products, like EcoDMS, also need this to work with AD.

Does the certificate need to be for the servers hostname, or the AD’s domain name?

No, NethServer only uses a single ssl cert, but you can use Aliases on this cert…
The AD name does need to be externally resolveable, but the AD itself does not need to be reachable.

My home NethServer:

Perfect. I will give that a shot. Thanks again Andy for your quick responses!

1 Like

@bradjtrammell

A last note: don’t forget to use the valid dns name on server2 to access the AD, and not use the IP, which does NOT have a valid LE ssl cert!