Integrating LDAP for User-Authentication fails

christian.exner · 11 October 2022 11:36

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:

.env.local
###> AUTH_TYPE ###
#AUTH_TYPE=native
AUTH_TYPE=ldap
###< AUTH_TYPE ###

###> LDAP CONFIG ###
LDAP_HOST=‘192.168.xxx.11’
LDAP_PORT=389
LDAP_ENCRYPTION=‘none’
LDAP_PROTOCOL_VERSION=3
LDAP_REFERRALS=false
LDAP_DN_STRING=‘dc=ad,dc=xxxxxxxxxxxxx,dc=de’
LDAP_QUERY_STRING=‘(sAMAccountName={username})’
LDAP_SEARCH_DN=‘CN=xxxxxxxxxxxxxx,dc=ad,dc=xxxxxxxxxxxxx,dc=de’
LDAP_SEARCH_PASSWORD=‘xxxxxxxxxxxx’
###< LDAP CONFIG ###

###> LDAP AUTO CREATE CONFIG ###
LDAP_AUTO_CREATE=enabled
LDAP_PROVIDER_BASE_DN=‘dc=ad,dc=xxxxxxxxxxxxx,dc=de’
LDAP_PROVIDER_SEARCH_DN=‘CN=xxxxxxxxxxxxxx,dc=ad,dc=xxxxxxxxxxxxx,dc=de’
LDAP_PROVIDER_SEARCH_PASSWORD=‘xxxxxxxxxxxx’
LDAP_PROVIDER_DEFAULT_ROLES=ROLE_USER
LDAP_PROVIDER_UID_KEY=‘sAMAccountName’
LDAP_PROVIDER_FILTER=‘(&(sAMAccountName={username})(objectcategory=person)(objectclass=user))’
###< LDAP AUTO CREATE CONFIG ##

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

Regards…
Chris

kingfisher77 · 12 October 2022 20:18

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.

kingfisher77 · 13 October 2022 07:56

Did you find a way to debug? Logfile?

christian.exner · 13 October 2022 15:44

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:

kingfisher77 · 13 October 2022 18:10

How do you debug the LDAP connection?

christian.exner · 13 October 2022 18:40

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.

Chris

Second search, unauthenticated:

fraxx · 26 October 2022 12:13

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

no way to backup from within (symfony or suitecrm)

fraxx · 26 October 2022 12:30

omg, LDAP works fine if I set

APP_ENV=qa

fraxx · 26 October 2022 12:38

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

christian.exner · 27 October 2022 05:52

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?

fraxx · 27 October 2022 11:45

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
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

LDAP_DN_STRING=‘dc=ad,dc=xxxxxxxxxxxxx,dc=de’

with

LDAP_DN_STRING=‘cn=SpecificUserCn,dc=ad,dc=xxxxxxxxxxxxx,dc=de’

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)

kingfisher77 · 10 November 2022 07:10

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

christian.exner · 10 November 2022 18:25

@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.

fraxx · 10 November 2022 18:41

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

fraxx · 10 November 2022 18:43

ah…
understand.

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

kingfisher77 · 10 November 2022 19:56

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?

christian.exner · 10 November 2022 20:00

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/v8.int/vendor/symfony/ldap/Security/CheckLdapCredentialsListener.php line 75 {“exception”:“[object] (ErrorException(code: 0): Warning: get_class() expects parameter 1 to be object, string given at /opt/SuiteCRM/v8.int/vendor/symfony/ldap/Security/CheckLdapCredentialsListener.php:75)”}

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

fraxx · 4 July 2023 18:00

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