Page 1 of 1

[SOLVED] LdapS authentication issue

Published: July 2, 2020 - 10:18 AM
by Houg
Hello everyone.
For the switch to wapt enterprise, I am currently configuring our new server (on debian).
All that's left for me is console authentication with LdapS.
And that's where I'm stuck… I followed the instructions exactly…

Authentication with local session: OK
LDAP authentication (non-S): OK (the connection request is clearly visible in the AD server)
LDAP authentication: not working => however, there is no connection request in the AD server.
However, on AD, the certificate is correctly installed with a known authority.
Just to be sure, I added this authority to the WAPT server. No changes…:

Code: Select all

sudo cp TERENACA.crt /usr/local/share/ca-certificates
sudo update-ca-certificates
A telnet connection on port 636 (ldapS) from my wapt server to my AD server is functional.
(By the way, this reminds me that the documentation states that the default LdapS port is 646, whereas it's actually 636) :D )

Here is my waptserver.ini (anonymized):
[options]
waptwua_folder = /var/www/waptwua
server_uuid = XXXXXXXXXXX
clients_signing_key = XXXXXXXXXXX
clients_signing_certificate = XXXXXXXXXXX
wapt_password = XXXXXXXXXXX
allow_unauthenticated_connect = False
secret_key = XXXXXXXXXXX
use_kerberos = True
wapt_huey_db = /opt/wapt/db/waptservertasks.sqlite

wapt_admin_group_dn=CN=group,CN=Users,DC=mydomain,DC=fr
ldap_auth_server=myserver.mydomain.fr
ldap_auth_base_dn=OU=mygroup,DC=mydomain,DC=fr
ldap_auth_ssl_enabled=True


Here is the result of /opt/wapt/runwaptserver.sh -ldebug during identification:
2020-07-02 10:08:45,001 [waptserver ] DEBUG (3174) accepted ('127.0.0.1', 59294)
2020-07-02 10:08:45,002 [root ] DEBUG Using monserver.mondomaine.fr as authentication ldap server
2020-07-02 10:08:45,003 [root ] DEBUG Using OU=mongroup,DC=mondomaine,DC=fr as base DN
2020-07-02 10:08:45,003 [root ] DEBUG using dc monserver.mondomaine.fr for authentication, with base DN OU=mongroup,DC=mondomaine,DC=fr and bind username monlogin@mondomaine.fr
2020-07-02 10:08:45,003 [root ] DEBUG Using ldaps for authentication
2020-07-02 10:08:45,012 [waptserver ] INFO ip.de.mon.AD,127.0.0.1 - - [02/Jul/2020 10:08:45] "POST /api/v3/login HTTP/1.0" 401 324 0.009679
2020-07-02 10:08:47,625 [waptserver ] INFO wsgi exiting
2020-07-02 10:08:47,625 [waptserver ] INFO (3174) wsgi exited, is_accepting=True
2020-07-02 10:08:47,625 [waptserver ] INFO Waptserver stopped
Well... I'm not exactly an expert on logs, but in this case, I don't see...
The console won't connect

Thanks in advance !!

Re: LdapS authentication problem

Published: July 2, 2020 - 5:10 PM
by sfonteneau
You can do a test like this:

Code: Select all

apt install ldap-utils
ldapsearch -x -H ldap://srvads.mydomain.lan -Z -D sfonteneau@mydomain.lan -b dc=mydomain,dc=lan -W
This allows you to perform a test without going through wapt

After the order

Code: Select all

sudo update-ca-certificates
Your certificate should be located in /etc/ssl/certs

Re: LdapS authentication problem

Published: July 3, 2020 - 8:32 AM
by Houg
Good morning,

As described in the post, the LDAP connection is working... I tested different ldapsearch parameters before posting on the forum (I forgot to mention that)
So this line is functional (a slight variation to clearly show the indicated port):
ldapsearch -x -h srvads.mydomain.lan -Z -D sfonteneau@mydomain.lan -p 389 -b dc=mydomain,dc=lan -W
Enter LDAP Password:
[...]
# search result
search: 3
result: 4 Size limit exceeded
[...]

But, if I specify port 636, it is no longer the same.
ldapsearch -x -h srvads.mydomain.lan -Z -D sfonteneau@mydomain.lan -p 636 -b dc=mydomain,dc=lan -W
ldap_start_tls: Can't contact LDAP server (-1)
Enter LDAP Password:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
I should point out that LdapS is functional on AD => telnet on port 636 is functional + the ldp.exe tool from Microsoft (via another server) also works.

Regarding the certificate, yes, it is indeed available in /etc/ssl/certs. Furthermore, it's a public certificate authority, which is therefore already present by default.



EDIT: Problem solved, or rather bypassed => I specified a different AD and it works....