Integrating LDAP for User-Authentication fails

I need little assistance on integrating LDAP-Authentication to SuiteCRM 8.2 b2 running on Debian 11. ActiveDirectory is provided by Samba.

Configuration of LDAP-Provider seems fine as Network Trace shows authenticated ldap_bind with following ldap-search for the User-Object trying to log on in Browser. Search successfully returns exactly one LDAP-Object.

Thereafter, Network Trace shows another ldap_bind (this time without authentication) and some searches (for Example to Context “Configuration”) - all failing because of the missing ldap authentication.

In my understanding, in second step SuiteCRM should ldap_bind authenticated as LDAP_SEARCH_DN / LDAP_SEARCH_PASSWORD, search for LDAP_QUERY_STRING beginning in LDAP_DN_STRING. Exactly one LDAP-Object should be found which is used to do another ldap_bind using the Password given from User in Browser.

It is not an Option to me to allow unauthenticated ldap_search. For Debug only, I changed from LDAPS to LDAP.

Maybe I missunderstood the LDAP Configuration Params? They are as follows:

###> AUTH_TYPE ###
###< AUTH_TYPE ###

###> LDAP CONFIG ###
###< LDAP CONFIG ###


May somebody push me to the right direction? Any hint appreciated!


Tried it also without success (8.2). Docu is a bit cryptic… Basically it is the configuration for the underlying Symfony and the nomenclatur is from there. We have a Samba AD which works very well with a bunch of other applications. Would be interested in a success story.

Did you find a way to debug? Logfile?

Debug Log is not a Problem … but is not helpful.

From my point, it is now necessary to find the reason why simphony does ldap_bind without authentication on second turn (after successful searching username of user that is trying to log on).

No new findings so far…

First Search, authenticated, succesful:

How do you debug the LDAP connection?

Tracing comm with tcpdump/ wireshark with temporarily allowed unencrypted LDAP on the DC.
DC itself gives no helpful debug info on ldap (or i don’t know any better).
SuiteCRM also gives no helpful info.

So, with my config on first, SuiteCRM connects to LDAP with authentication and does a successful search for {username}. Only one Result returns.

Thereafter, SuiteCRM should ldap_bind second time with firstly found DN and User-Provided Password.
Instead SuiteCRM does an ldap_bind unauthenticated for further searching that is not permitted by config of DC.

But your case may be different.


Second search, unauthenticated:

we are having issues with LDAP and SuiteCRM v. 8, too

no way to backup from within (symfony or suitecrm)

omg, LDAP works fine if I set


so, the caching was the issue (and changing APP_ENV had the effect to have clean caches)

so, to have LDAP working for us was just a matter of removing the cache dir

we were doing it, before, with

./bin/console cache:pool:clear cache.global_clearer

but apparently only removing the cache dir solved

Sorry, can not confirm in my environment.
Second Bind to LDAP while trying to log in is further unauthenticated … so following search fails.

Does your LDAP allow for unauthenticated searching?

yes, our setup allows for unauthenticated searching, but we do have anyhow to use the SEARCH_DN and SEARCH_PASSWORD or else it does not work (it could be because in our setup the username is translated into users’ email, which is what we use to login).

Btw: even with a (quick, must admit) help from a Symfony developer we where not able to allow proper log debugging for LDAP auth, so the only debug we could do is from the log of our LDAP server as you did

here my suggestions:

  • try to enable logs in symfony (if you make it tell us how, please :slight_smile:
  • skip the AUTO_CREATE until you are done with basic login (so you need to have first created a user in SuiteCRM, the change its flag in SuiteCrm admin GUI to allow the LDAP login for it)

the very easiest way to debug LDAP auth is to replace




where SpecificUserCn point to a user in SuiteCrm: this way the base LDAP search return only one user: then login with that user: this should work (it works for us)

Where would we change the flag in the admin GUI to allow the LDAP login for a specific user?

@fraxx, tried to go the way you described. Disabled AUTO_CREATE Option (changed only this single Option - all the rest remains unchanged), drained Cache-Directory. Restart php-fpm.

Now SuiteCRM does no longer any conversation with LDAP-Server regardless if user record is manually created or not. The locally saved password also no longer works as soon as AUTH_TYPE is changed from native to ldap.

So failing conversation seems to be fully related to LDAP_PROVIDER not Authentication.

go to admin, users, select the users and you see the option (or else go directly in the database: in the users table)


maybe try to setup a basic (and plain) ldap service, even in the same server and test it.

ah, remember that the LDAP in the new SuiteCRM 8 is handled by symfony, and there I guess many application use ldap

In the admin GUI I could not and cannot find any option to allow LDAP login for a user. Is it the field “external_auth_only” in the users table of the database?

Strange, i use version 8.2 You too?

Can confirm. v8.2 … there is no Option to switch user to LDAP.

Maybe my installation is not fully migrated?

But there are LDAP settings in .env.

Also, there is PHP Exception in prod.log of my Instance:

[2022-11-11 07:44:34] request.CRITICAL: Uncaught PHP Exception ErrorException: “Warning: get_class() expects parameter 1 to be object, string given” at /opt/SuiteCRM/ line 75 {“exception”:"[object] (ErrorException(code: 0): Warning: get_class() expects parameter 1 to be object, string given at /opt/SuiteCRM/"} []

Further captured the SQL to find user record in database from prod.log and executed manually. User record is found properly.

We’ve solved our startTLS LDAP configuration today as reported in LDAP is working but not with TLS - #4 by fraxx

hope it will help others