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)
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.ā
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.
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.
# 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.
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, 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ā¦
Hereās the steps to install and setup dev mode (APP_ENV=dev) properly:
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.
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.
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).