LDAPS Authentication Problems Zabbix 4.0.14 - Cannot bind to LDAP server

[KarlPokorny]

Dear Community,

I am currently working on setting up LDAP Auth for a new domain and run into some strage behaviour of zabbix.

I'd like to enable the LDAP Auth and have configured my frontend as follows:
------------------------------------------------------------------------------------------------
LDAP Host = ldaps://dnsfordc.mycompany.com
Port = 636
BasDN = DC=mycompany,DC=com
searchAttribute = sAMAccountName
BindDN = CN=myuser,OU=SystemUser,OU=Tier1,OU=ADMIN
case sensitive login = unchecked
Bind Password = pwd
-----------------------------------------------------------------------------------------------
Zabbix Server Version = 4.0.14
OS = CentOS 7

already tried LDAP Host with IP; ldap://IP; and ldap://dnsfordc.mycompany.com - none of them worked


my ldap.conf looks like
-----------------------------------------------------------------------------------------------
BASE dc=mycompany,dc=com
URI ldaps://dnsfordc.mycompany.com
TLS_REQCERT never
TLS_CACERT /etc/openldap/certs/rootcacert.pem
# Turning this off breaks GSSAPI used with krb5 when rdns = false
SASL_NOCANON on
----------------------------------------------------------------------------------------------

already tried TLS_REQCERT allow (as it was recommended by the zabbix doc and several forums)

The rootCA cert is provided what seems to be the right format and seems legit on manual recheck

funny enough my ldapsearch request works just fine:

ldapsearch -x -LLL -ZZ -h dnsfordc.mycompany.com -D myuser -w'pwd' -b"CN=myuser,OU=SystemUser,OU=Tier1,OU=ADMIN,DC=myc ompany,DC=com"


Do you guys know any problems and issues that I might have overlooked?
Is there a certain log file where I could turn to?

So far I didn't figure out where to look, or might have overlooked something in the regular log files of zabbix.


I am glad for any help available. In case more info might help, please just let me know.

[LenR]

Try adding the port to the url (add :636) and leave the port blank (or 0 if it is a required field)

[KarlPokorny]

thank you for the hint, unfortunately that didn't change anything

[Markku]

Hi, is the -ZZ (StartTLS) same as connecting to 636/tcp? I'd first try ldapsearch with the exact same URL ("ldaps://...") to confirm the reachability to 636.

Firewall logs would also be worth checking, or capturing traffic, to confirm that the LDAPS request is actually working.

Markku

[KarlPokorny]

Markku you were right, the ldapsearch was not correct and the -ZZ didn't automatically went for port 636

I updated the ldap.conf and added a TLS_CACERTDIR and adapted the ldapsearch command

ldapsearch -x -H ldaps://dnsfordc.mycompany.com:636 -LLL -D "CN=myuser,OU=SystemUser,OU=Tier1,OU=ADMIN,DC=myco mpany,DC=com" -w'pwd' -s sub -b "OU=SystemUser,OU=Tier1,OU=ADMIN,DC=mycompany,DC=c om" "cn=*"

this works fine, however the problem at the zabbix server was not resolved. Do I need to provide a separate Cert for the server as well, or is the root CA cert sufficient for ldaps?

Firewallrules are checked, no limitations on the zabbix servers whatsoever.

[gofree]

selinux ? enabled ? try to disable it and check - I had weird moments with it

[KarlPokorny]

I have currently selinux set on permissive, to at least get these error sources out of my feet for now

also set the sebools for the point in time when I take the step to get selinux back into enforcing mode again

[Markku]

My working LDAPS authentication setup on Debian 9 Stretch is:

Zabbix (4.0.x and now 4.4.4):
LDAP host = ldaps://my-dc-dns-name
Port = 636
BaseDN = dc=my,dc=domain,dc=name
Search attribute = sAMAccountName
Bind DN = CN=username,OU=xxx,OU=yyy,OU=zzz,DC=my,DC=domain,D C=name

/etc/ldap/ldap.conf:
TLS_CACERT /etc/ssl/certs/ca-certificates.crt (this contains our internal root CA certificate as well)
TLS_REQCERT allow


Markku

[KarlPokorny]

did you provide the whole cert chain in ca-certificates.crt or just the root CA cert?

[Markku]

I checked with

awk -v cmd='openssl x509 -noout -subject' '/BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt

that I only have the root there.

Markku

[KarlPokorny]

alright, thank you for the info, I configured it the same way. It's a shame that no logging is available in this regard

[KarlPokorny]

As it turns out it was no problem with Zabbix at all, with our Domain Admin I figured the problem out. We excluded the serviceuser for mail sending with zabbix from MFA in Azure AD, somehow this did not work as intended. Workaround with an apppassword was established, now it works fine. Thank you guys for your input!

[Markku]

My working LDAPS authentication setup on Debian 9 Stretch is:

Zabbix (4.0.x and now 4.4.4):
LDAP host = ldaps://my-dc-dns-name
Port = 636
BaseDN = dc=my,dc=domain,dc=name
Search attribute = sAMAccountName
Bind DN = CN=username,OU=xxx,OU=yyy,OU=zzz,DC=my,DC=domain,D C=name

/etc/ldap/ldap.conf:
TLS_CACERT /etc/ssl/certs/ca-certificates.crt (this contains our internal root CA certificate as well)
TLS_REQCERT allow


Markku

A small update on this: For a new Debian 10 Buster server I did this:

- copy the internal root CA in /usr/local/share/ca-certificates (filename must end .crt)
- run update-ca-certificates
- no editing of /etc/ldap/ldap.conf was required (the only enabled line is TLS_CACERT /etc/ssl/certs/ca-certificates.crt).

Markku