LDAP Auth not invoked

[fraxx]

I’ve updated my post above, so people wont make mistakes

[maverickws]

Hi @fraxx and OP @emanuele

I’m the author of the topic Unable to login after 8.4.2 update - have you guys put this to work.
Because I had a working configuration, update broke it, and apparently SuiteCRM is clueless about what is going on. So have you figured a fix?

If not, I also invite you to participate on the GitHub Issue about this.
It’s surreal to me that an error introduced by an update is persisting through two versions.

[fraxx]

if your suitecrm is in linux, and the LDAP server is openldap, then we have the same setup: I remember I did all the debugging by using the linux

ldapsearch  -x -H ldaps://ldap.example.com:636

where I still do not understand if that tool (yum install openldap-clients) is even necessary (I mean, used by PHP: maybe not): but you need the anyhow to install openldap which gives you the file /etc/openldap/ldap.conf that is sure read by PHP.

We have a note in our internal documentation about this:

So, it is clear the issue (LDAP in suitecrm not working) was not related to SuiteCRM and Symfony: it is evidently the php-ldap code that uses somehow (fortunately) the content of the o.s. file /etc/openldap/ldap.conf to get the CA certificate

indeed in our /etc/openldap/ldap.conf in the suitecrm server we have

TLS_CACERT    /etc/openldap/our-ca-certificates.crt

which is the same CA file we have in our ldap server with which we’ve created the certificate for LDAP.

Btw: since now our CA have expired, the LDAP login in suitecrm stopped working, so we’ve temporary set

LDAP_ENCRYPTION=none

to be able to usa LDAP: this is not good, of course, and now I have to regenerate the certificate (we’ll try with letsencrypt, so not to be able to distribute that custom CA certificate to all clients that needs to connect with TLS to LDAP): this means I will have to come back to this context so maybe be more precise on it

[emanuele]

I am using Ubuntu 22.04 and there is no package called “openldap-clients”. The package for the ldap client is called “ldap-utils” and the file “/etc/openldap/ldap.conf” does not exist. Also, in my case I’m trying to connect to the ldap server without encryption (“LDAP_ENCRYPTION=none”) and I’m sure the join to the corporate AD server works with other tools I’ve already tested.

Thanks @maverickws I read your post and - encryption aside - I am in the same situation mentioned by user ‘rmendes-13’ in his comment.

[pgr]

@rmendes-13 on GitHub @maverickws on SuiteCRM Forums

[fraxx]

yes, I see in Ubuntu you have ldap-utils providing ldapsearch and also

/etc/ldap/ldap.conf

installed by libldap-common

# dpkg -S /etc/ldap/ldap.conf
libldap-common: /etc/ldap/ldap.conf

and check out

man ldap.conf

(btw, to solve packages’ search I use AI with the free https://www.perplexity.ai or phind.com)

[fraxx]

I would say the first step is to be able to connect with TLS to your LDAP by using ldapsearch
(in the meanwhile best would be you can see the logs in the LDAP server)

[emanuele]

Already done and it works (without encryption ).
From the first post:

“Trying to make an ldapsearch manually (within the server) it works (ldapsearch -x -b “dc=example,dc=local” -H ldap://myhost.example.local -D user -W) but when trying to login with SuiteCRM ui I cannot see any search to ldap server from logs (suitecrm.log) e.g: ldapauth is not invoked.”

[fraxx]

Already done and it works (without encryption ).

exactly, so now have ldapsearch to work with encryption, by changing port (or with the same port but adding -ZZ for StartTLS). I see also ldapsearch have options for debug and verbose.

[maverickws]

Howdy,

So, ldapsearch wasn’t installed as there hasn’t been a need, previous to this update, to have it installed in order for LDAP authentication to work. I’m not sure if that would be the case now.

Anyway, the machine where SuiteCRM is installed is enrolled on the IDM domain. the ldap.conf file exists. I also don’t need to add extra parameters like -H host:port to the command as the server globally knows what its identity server is.

So doing a simple test:

# kinit my-user
Password for my-user@DOMAIN.TLD:

# ldapsearch -x 

# extended LDIF
#
# LDAPv3
# base <dc=domain,dc=tld> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# users, compat, domain.tld
dn: cn=users,cn=compat,dc=domain,dc=tld
objectClass: extensibleObject
cn: users
 
...

I am using port 389 with TLS so the connection is automatically upgraded. For all matters, the IDM server is also the CA authority.

I can contact and run all commands from this server to the IDM server. The certificates are valid. The only problem is whatever crap was made from v 8.4.1 to v8.4.2 that simply broke LDAP.

We use LDAP authentication across a myriad of applications. None has problems.

EDIT:
Some follow-up on the configuration environment of IDM: FreeIPA docs - HowTo - LDAP

Red Hat IDM and FreeIPA are the exact same thing.

[chris001]

These two forum threads contain some thorough investigation and solutions.

Integrating LDAP for User-Authentication fails

omg, LDAP works fine if I set APP_ENV=qa

LDAP is working but not with TLS

oh, I can’t believe I solved it: the issue was caused by the TLS certificate on the ldap server: it was signed by a CA made by us. from the linux (Rocky) server where we have installed SuiteCRM8, I tested the connection to our LDAP (OpenLDAP) server and saw it was not working $ ldapsearch -x -H ldaps://ldap.example.com:636 ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) (where, of course, the ldap.example.com would be the URL of our LDAP server) I’ve installed openldap-clients in th…

Please read the above two forum threads, try their solutions, and report back here with your results.

[maverickws]

# ldapsearch -x -H ldaps://idm1.domain.tld:636

# extended LDIF
#
# LDAPv3
# base <dc=domain,dc=tld> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# users, compat, domain.tld
dn: cn=users,cn=compat,dc=domain,dc=tld
objectClass: extensibleObject
cn: users

...and so on

the same thing. I have no issues connecting using port 636 or 389 with TLS which is what I am using on SuiteCRM.

The ldap.conf file exists and is configured with TLS_CACERT with the correct information. The system is enrolled on a domain and all these configurations are set and working.

Also I am extremely sorry for my bluntness but I don’t see exactly the point of digging over a year old topics, from users having trouble with first time LDAP config, when this is about a SuiteCRM change that broke a working LDAP integration (version 8.4.1) to a non-working LDAP integration (version 8.4.2) on several environments and setups. There were no problems before for various setups, now there are. Certificates haven’t expired over the course of the update.

What more tests do you need, specifically?

• ldap.conf exists and correctly configured
• ldapsearchand other tools work without any issue over TLS
• prior to update, or if I restore to the previous version, LDAP is working.

[chris001]

Can you set APP_ENV=qa, this should provide additional detail, and report back your results?

[maverickws]

# cat .env | grep APP_ENV
#  * .env.$APP_ENV       committed environment-specific defaults
#  * .env.$APP_ENV.local uncommitted environment-specific overrides
APP_ENV=qa

Login credentials incorrect, please try again.

No entries on either logs/prod/prod.log or public/legacy/suitecrm.log

EDIT:
To test I performed the following steps

1. edited .env
2. ran bin/console cache:clear and bin/console cache:pool:clear cache.global_clearer
   tried to login.

I would also like to add that in the course of debugging this situation I have created multiple .env files, such as:

$ ls -la .env*
-rw-r--r--. 1 apache apache 1932 Jan 25 17:54 .env
-rw-r--r--. 1 apache apache  889 Jan 23 17:20 .env.local
-rw-r--r--. 1 apache apache  889 Jan 23 17:27 .env.prod.local
-rw-r--r--. 1 apache apache  889 Jan 23 17:32 .env.qa.local

The locals are all copy of the original .local

[pgr]

I didn’t know about the qa environment, but I do know that the dev environment gives you access to elaborate error messages with full stack traces (I find these most useful for this kind of forum troubleshooting, I can go look at the actual code without having to set up a complex environment and trying to reproduce on my local).

However, the last few people whom I told to change to dev got a broken system with a Doctrine error. I believe this can be solved, I’ve solved it myself, but it was a long time ago and I don’t remember what it was. Maybe installing the dev package to get the dist precompiled folder, maybe running composer to update packages to better match the dev environment, maybe something else. Maybe it’s something as simple as giving the DB credentials in the .dev.env file.

@maverickws it’s up to you if want to try yet another environment, and go through the trouble of getting it to work, but I do think that might provide more information…

[chris001]

It’s several yarn commands + other commands, to get APP_ENV=dev to work and show more detailed error info:

Installing SuiteCRM 8 Development mode

[image] I’m trying to install Suite8 using the developer guide (for dev environment) and I’m getting this error while launching the command : yarn run build-dev:shell Developer Install Guide :: SuiteCRM Documentation

[pgr]

@chris001, but that is to set up the full dev environment that is able to compile the front end. That dev package I mentioned is meant to avoid that by providing a precompiled dist directory and some other bits. We won’t need to compile the front-end, just get Symfony to go trough the dev environment so it provides more detailed output…

[chris001]

Here’s the steps to install and setup dev mode (APP_ENV=dev) properly:

SuiteCRM 8.5 Live server with ng serve

Hey @wiFiriFi, Welcome to the community If you download the base package it doesn’t include the dist folder, which is needed for building the front end. For frontend development they provide a dev package that includes the dist folder, you can find it on the github release: Release 8.5.0 · salesagility/SuiteCRM-Core · GitHub SuiteCRM-8.5.0-dev.zip The dev package = base package + the dist folder. I don’t think ng serve is supported. They recommend using the build command with -…

if you would setup this dev mode as explained in the post above @maverickws and report back your more detailed error messages when the LDAP login fails to login on 8.5.

[maverickws]

I’m sorry I’m not a developer, someone f*cks up and I have to go and install dev releases, setup full development environments and whatever?
How about you install a freeipa server which is quite easy and test yourself? It’s free open source software.

This is not my work, I’ve done plenty of testing already, took hours from my day I should be working for this. Having to setup a full development environment just because this doesn’t generate proper log output is ridiculous.
If the stanza is to leave errors in the app until final users do all the work for you, then I’m just going back to 8.4.1 until I find some other solution for CRM.
As I’ve stated many times before, and I will stress it again, I am not a developer, I was evaluating SuiteCRM for inclusion in projects, and the whole lifecycle of this issue and these requests, make it clear that this is not suitable for anything.

[emanuele]

I’m also testing SuiteCRM as an Open Source alternative to SugarCRM (and unfortunately I don’t have a lot of time 'cause I’m testing the product for my company and can squeeze a few hours out of normal activities).