How to (re)enable TLS/STARTTLS in Nethserver AD

[yummiweb]

NethServer Version: NethServer release 7.9.2009 (final)
Module: samba DC version 4.9.18

How can i (re)enable TLS/STARTTLS in Nethserver AD?
I think this was enabled some Times ago but if i try to connect an FreePBX to the Nethserver AD (nethserver-freepbx or external FreePBX) i found that this is only possible without TLS/STARTTLS.

I know, that i have disabled the auth-strong setting in the smb config of AD some time ago (because testing anything).
And i can see, that in the DB the sssd StartTls is marked as disabled.

I have tried to reenabled this via changing the db entry to “enabled”, reconfigure with /etc/e-smith/events/actions/system-adjust, renew the Letsencryp cert and restart.
But after then some connections wasn’t more possible to services (SOGo).
(the Nethserver connection itself to the Ad seems to be correct)

Is the “StartTls” flag enabled in general while new Nethserver/AD installations? Or was this disabled before in older installations? (i think i installed the Nethserver AD at Nethserver 7.5)

I’d like to connect a freepbx to the Nethserver AD but in a secure way.
Which is the best way to re-enable this without loosing AD informations?

Regards
yummiweb

[mark_nl (Mark Verlinde)]

@yummiweb

Is the “StartTls” flag enabled in general while new Nethserver/AD installations? Or was this disabled before in older installations? (i think i installed the Nethserver AD at Nethserver 7.5)

Can not remember a setting to disable SSL/StartTls for the local installed AD.

@yummiweb

in the DB the sssd StartTls is marked as disabled.

AFAIK It is only used / set if you bind a nethserver to an external (non NS) AD.

What does config show sssd show ? (here my anonymized output)

sssd=service
    AdDns=10.0.y.xxx
    BindDN=ldapservice@AD.DOMAIN.NL
    BindPassword=xxxxxxx
    DiscoverDcType=ldapuri
    LdapURI=ldaps://nsdc-server.ad.domain.nl
    Provider=ad
    Realm=AD.DOAMIN.NL
    ShellOverrideStatus=disabled
    Workgroup=DOMAIN
    status=enabled

It is recomened to use config setprop sssd PROPERTY VALUE
then run signal-event nethserver-sssd-update

[yummiweb]

My sssd config is mostly the same:

sssd=service
AdDns=192.168.88.3
BaseDN=dc=ad,dc=mydomain,dc=org
BindDN=ldapservice@AD.MYDOMAIN.ORG
BindPassword=***************
DiscoverDcType=ldapuri
GroupDN=dc=ad,dc=mydomain,dc=org
LdapURI=ldaps://nsdc-myservername.ad.mydomain.org
Provider=ad
Realm=AD.MYDOMAIN.ORG
ShellOverrideStatus=enabled
StartTls=disabled
UserDN=dc=ad,dc=mydomain,dc=org
Workgroup=MYDOMAIN
status=enabled

Before i try it again, there is a question:
This db settings are for the connection from Nethserver itself to an internal/external AD Provider, right?
So changing this settings to StartTls=enabled will only work if the Nethserver AD itself (machines/ndsc) can connect via StartTLS/SSL, or?
How can i check to see that the AD Provider itself is TLS enabled?

[mark_nl (Mark Verlinde)]

@yummiweb

This db settings are for the connection from Nethserver itself to an internal/external AD Provider, right?

Sure looks that way.

Do I understand correctly this is the config on the Server acting as DC?

@yummiweb

How can i check to see that the AD Provider itself is TLS enabled?

do not know other than trying to bind something to it as said AFIAK it is always enabled.

And if I remember correctly it worked like this:

ldap://… port 389 no encryption (unsafe)
ldaps://… port 389 StartTLS
ldaps://… port 636 SSL

[mrmarkuz (Markus Neuberger)]

@mark_nl

AFIAK it is always enabled.

That’s true.

@mark_nl

ldap s ://… port 389 StartTLS

With StartTLS it’s just ldap:// too,

@yummiweb

How can i check to see that the AD Provider itself is TLS enabled?

To test starttls:

ldapsearch -Z -D CN=admin,CN=Users,DC=ad,DC=domain,DC=tld -w <PASSWORD> -b CN=Users,DC=ad,DC=domain,DC=tld -h <NSDC IP>

To test ssl:

ldapsearch -D CN=admin,CN=Users,DC=ad,DC=domain,DC=tld -w <PASSWORD> -b CN=Users,DC=ad,DC=domain,DC=tld -H ldaps://ad.domain.tld

[yummiweb]

Thank you for helping.
I have tried now both of your (adjusted) commands from three different local machines (debian, macos and nethserver itself) with unclear results:

STARTTLS debian:

ldap_start_tls: Connect error (-11)
additional info: (unknown error code)
ldap_result: Can’t contact LDAP server (-1)

STARTTLS macos:

ldap_start_tls: Connect error (-11)
additional info: SSLHandshake() failed: misc. bad certificate (-9825)
ldap_result: Can’t contact LDAP server (-1)

This last result seems to be an certificate problem.

SSL debian:

ldap_sasl_bind(SIMPLE): Can’t contact LDAP server (-1)

SSL macos:

ldap_sasl_bind(SIMPLE): Can’t contact LDAP server (-1)

But the same procederes in Nethserver (which is joined to this AD sucessfull)

STARTTLS:

ldap_bind: Invalid credentials (49)
additional info: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1

SSL:

ldap_bind: Invalid credentials (49)
additional info: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1

I don’t understand this “invalid Credentials” lack because the used password is the same as shown in in Nethserver Cockpit > Account Provider.

I have also done a portscan again the account provider which shows the relevant ports are open:

Open TCP Port: 53 domain
Open TCP Port: 88 kerberos
Open TCP Port: 135 epmap
Open TCP Port: 139 netbios-ssn
Open TCP Port: 389 ldap
Open TCP Port: 445 microsoft-ds
Open TCP Port: 464 kpasswd
Open TCP Port: 636 ldaps
Open TCP Port: 3268 msft-gc
Open TCP Port: 3269 msft-gc-ssl
Open TCP Port: 49152
Open TCP Port: 49153
Open TCP Port: 49154

Any suggestions?

Regards yummiweb

[yummiweb]

@mark_nl

Do I understand correctly this is the config on the Server acting as DC?

Yes, exactly.

[mrmarkuz (Markus Neuberger)]

@yummiweb

This last result seems to be an certificate problem.

Right, I’m using a letsencrypt cert…

@yummiweb

I don’t understand this “invalid Credentials” lack because the used password is the same as shown in in Nethserver Cockpit > Account Provider.

The password shown there is for the ldapservice user.

ldapsearch -D CN=ldapservice,CN=Users,DC=ad,DC=domain,DC=tld -w <pass> -b CN=Users,DC=ad,DC=domain,DC=tld -H ldaps://ad.domain.tld

[yummiweb]

Addition:

If i try this on all machine without starttls like:

ldapsearch -D CN=admin,CN=Users,DC=ad,DC=domain,DC=tld -w -b CN=Users,DC=ad,DC=domain,DC=tld -H ldap://ad.domain.tld

the result is also an “invalid Credentials”, hä?
Something bad in my Syntax?

I have adopt your example with my “domain”," tld", “IPv4” and “” changed to my Bind password in line all without quotes, right?

[yummiweb]

@mrmarkuz

ldapsearch -D CN=ldapservice,CN=Users,DC=ad,DC=domain,DC=tld -w -b CN=Users,DC=ad,DC=domain,DC=tld -H ldaps://ad.domain.tld

Now i see the different: admin / ldapservice

[yummiweb]

O.k. the wrong username was the initial* problem with “Invalis Credentials”.
I have used the “ldapservice” user now.

So i can now connect from the Nethserver itself via:

ldapsearch -D CN=ldapservice,CN=Users,DC=ad,DC=domain,DC=tld -w -b CN=Users,DC=ad,DC=domain,DC=tld -H ldaps://ad.domain.tld

*But it don’t works with the -ZZ option (Start TLS request (-ZZ to require successful response)):

ldapsearch -D -ZZ CN=ldapservice,CN=Users,DC=ad,DC=domain,DC=tld -w -b CN=Users,DC=ad,DC=domain,DC=tld -H ldaps://ad.domain.tld

In this case the result is also a kind of an “Invalid Credentials” Error:

ldap_bind: Invalid credentials (49)
additional info: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1

So i am not sure the connection is really STARTTLS.
If try to connect from other machines the result is like before:

ldap_sasl_bind(SIMPLE): Can’t contact LDAP server (-1)

[mrmarkuz (Markus Neuberger)]

@yummiweb

So i can now connect from the Nethserver itself via:

Very good, so SSL is working.

@yummiweb

So i am not sure the connection is really STARTTLS.

@yummiweb

ldapsearch -D -ZZ CN=ldapservice,CN=Users,DC=ad,DC=domain,DC=tld -w -b CN=Users,DC=ad,DC=domain,DC=tld -H ldaps://ad.domain.tld

For starttls you need -H ldap://ad.domain.tld, not ldaps. It’s port 389.

[yummiweb]

@mrmarkuz

For starttls you need -H ldap://ad.domain.tld , not ldaps. It’s port 389.

You’re right, but the “forced” starttls via -ZZ option results in the same “Invalid Credentials” Error.
Correction:
My -ZZ option was on the wrong place. (it is definitely to late today…)
On Nethserver it works with -ZZ option to “-H ldap://ad.domain.tld” and to “-h IPv4 -p 389”.
But it didn’t works on port 636.

Meanwhile i have “successful” enabled the Nethserver connection to its own AD. I have enabled TLS this in the db and then run signal-event nethserver-sssd-update (and a restart). After that, the AD connection seemst to be “ok”, the user and group section shows users and groups and the connection from services like sogo runs normal without password problems (like yesterday).

But i am still not sure, that the connection between Nethserver and the AD is secured by TLS.
Alls tests from other machines works only via IP (the -h option) and to port 389 (without -ZZ option).

The FreePBX “Directory” Connection also only works without SSL or STARTTLS.

My Mac shows:

ldap_start_tls: Connect error (-11)
additional info: SSLHandshake() failed: misc. bad certificate (-9825)

[mrmarkuz (Markus Neuberger)]

@yummiweb

But i am still not sure, that the connection between Nethserver and the AD is secured by TLS.
Alls tests from other machines works only via IP (the -h option) and to port 389 (without -ZZ option).
The FreePBX “Directory” Connection also only works without SSL or STARTTLS.

Hm, I can connect to my NethServer AD with StartTLS option -ZZ from another NethServer but I use a valid cert for the samba AD server.

ldapsearch -ZZ -D CN=ldapservice,CN=Users,DC=ad,DC=domain,DC=tld -w <pass> -b CN=Users,DC=ad,DC=domain,DC=tld -H ldap://ad.domain.tld

[yummiweb]

@mrmarkuz

Right, I’m using a letsencrypt cert…

You use a Letsencrypt certificate on the AD Provider (the nsdc container)?

[mrmarkuz (Markus Neuberger)]

Yes, it’s explained here:

@planet_jeroen

touch /etc/e-smith/events/certificate-update/nsdc-cert
vi /etc/e-smith/events/certificate-update/nsdc-cert

Copy (that is, type) this in:

#!/bin/bash
cp -f /etc/pki/tls/private/localhost.key /var/lib/machines/nsdc/var/lib/samba/private/tls/key.pem
cp -f /etc/pki/tls/certs/localhost.crt /var/lib/machines/nsdc/var/lib/samba/private/tls/cert.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

Save the file and enter the last command:

chmod ug+x /etc/e-smith/events/certificate-update/nsdc-cert

[yummiweb]

Thank you very much for lead me to this guide.
But i am not sure to have an fqdn for my AD provider which can be resolved via an external dns.

After read this guide i unterstand my certificate error as (please correct me),
that a “untrusted” cert on my AD provider ist the reason for my problems with connecting external clients or apps?

Maybe this is an “Newbee” question, but can i manual “trust” this “untrusted” AD certificate on the client machines (for Example an FreePBX)?

[mrmarkuz (Markus Neuberger)]

@yummiweb

After read this guide i unterstand my certificate error as (please correct me),
that a “untrusted” cert on my AD provider ist the reason for my problems with connecting external clients or apps?

It could be for some NAS or Java apps, from my experience.

Another way would be to disable strong auth. Just for testing if your clients can connect without encryption to exclude other issues. From the wiki (go to AD section):

Edit /var/lib/machines/nsdc/etc/samba/smb.conf and add following line to [global] section:

ldap server require strong auth = no

Restart samba (AD):

systemctl -M nsdc restart samba

@yummiweb

Maybe this is an “Newbee” question, but can i manual “trust” this “untrusted” AD certificate on the client machines (for Example an FreePBX)?

Some implementations provide an option to allow self signed certs, I don’t know how freepbx handles it but I don’t think it’s needed for freepbx, I’m going to check when I find time.

[yummiweb]

@mrmarkuz

Another way would be to disable strong auth. Just for testing if your clients can connect without encryption to exclude other issues. From the wiki (go to AD section):

Edit /var/lib/machines/nsdc/etc/samba/smb.conf and add following line to [global] section:

ldap server require strong auth = no

Restart samba (AD):

systemctl -M nsdc restart samba

“Strong Auth” ist already disabled in the nsdc container, this is over from some radius, mattermost, whatever experiments.

Is there a “typical” way to “renew” the cert/password pair of the nsdc container? Is this manual needed in cases like expiration, changes in strengt or tls versions or something? As i can see, the AD cert expired in some months.

[mrmarkuz (Markus Neuberger)]

I think the samba AD uses the self-signed cert from Neth by default, so it should be renewed if you edit the self-signed cert.
There’s no official way yet, only the script for LE certs that get renewed automatically.