Confirming LDAP authentication

đź’¬ General Discussion
1

How do I know if an user has successfully authenticated against LDAP (I did a stupid thing of using the same LDAP password on SuiteCRM).
But now when I’m looking for an option to change the user password, I don’t see it anywhere.

However looking at suitecrm logs there’s no error nor confirmation of auth.

my .env.local

AUTH_TYPE=ldap

###> LDAP CONFIG ###
LDAP_HOST='idm.domain.tld'
LDAP_PORT=636
LDAP_ENCRYPTION=tls
LDAP_PROTOCOL_VERSION=3
LDAP_REFERRALS=false
LDAP_DN_STRING='dc=domain,dc=tld'
LDAP_QUERY_STRING='memberOf=cn=sales,cn=groups,cn=accounts,dc=domain,dc=tld'
LDAP_SEARCH_DN='uid=bind-user,cn=sysaccounts,cn=etc,dc=domain,dc=tld'
LDAP_SEARCH_PASSWORD='bind-password'
###< LDAP CONFIG ###
###> LDAP AUTO CREATE CONFIG ###
LDAP_AUTO_CREATE=enabled
LDAP_PROVIDER_BASE_DN='cn=accounts,dc=domain,dc=tld'
LDAP_PROVIDER_SEARCH_DN='uid=bind-user,cn=sysaccounts,cn=etc,dc=domain,dc=tld'
LDAP_PROVIDER_SEARCH_PASSWORD='bind-password'
LDAP_PROVIDER_DEFAULT_ROLES=ROLE_USER
LDAP_PROVIDER_UID_KEY='(uid={username})'
LDAP_PROVIDER_FILTER=''
###< LDAP AUTO CREATE CONFIG ###

So from what I understand the LDAP user auto-creation requires both sections, as the auto create config lacks server host, port, encryption, etc. But then some settings overlap, like
LDAP_SEARCH_DN == LDAP_PROVIDER_SEARCH_DN
LDAP_SEARCH_PASSWORD == LDAP_PROVIDER_SEARCH_PASSWORD

Does it make sense to fill both, or remove them from the LDAP CONFIG section?

Also, where LDAP_PROVIDER_DEFAULT_ROLES=ROLE_USER comes from?

Now a question about “LDAP extra fields”
Docs say:

To override the configurations you need to copy the file over to the extensions folder on a path like extensions/<your-package>/config/services/ldap/ldap.yaml

What exactly is “your-package”? just a folder I create? Or are other implications behind the “package” reference?
Thank you

2

look at the domain controller for the incoming ldap authentication it’ll be faster than chasing suite for those details

also change creds on the domain controller to see which user shares the same password - i find doing it this way breaks it faster so i know which to target, or simply leave the ldap password as is and change the user password so they don’t match

<your-package> just refers to a self made folder - don’t modify the default in the config dir - either way once that file exists it will get loaded from the extensions dir

1 Like
3

Hi @dhuntress cheers thanks for your answer, I actually had thought that but when asking here I was thinking “nah there must be a successful log here somewhere” but well guess again :smiley:

I’ll check the DC if I’m getting auth there no need to change passwords just want to know where the user is being validated against, and also for the <your-package> thing clarification.

Cheers!

4 
[16/Oct/2023:16:27:24.465071547 +0100] conn=27528 fd=140 slot=140 SSL connection from src.ip.addr.ess to dst.ip.addr.ess
[16/Oct/2023:16:27:24.847664941 +0100] conn=27528 TLS1.3 128-bit AES-GCM
[16/Oct/2023:16:27:24.848058090 +0100] conn=27528 op=1 BIND dn="uid=bind-user,cn=sysaccounts,cn=etc,dc=domain,dc=tld" method=128 version=3
[16/Oct/2023:16:27:24.848809296 +0100] conn=27528 op=1 RESULT err=0 tag=97 nentries=0 wtime=0.000727460 optime=0.000765515 etime=0.001491052 dn="uid=bind-user,cn=sysaccounts,cn=etc,dc=domain,dc=tld"
[16/Oct/2023:16:27:25.223555264 +0100] conn=27528 op=2 SRCH base="uid=user1,cn=users,cn=accounts,dc=domain,dc=tld" scope=2 filter="(uid=user1)" attrs="memberOf"
[16/Oct/2023:16:27:25.224332194 +0100] conn=27528 op=2 RESULT err=0 tag=101 nentries=1 wtime=0.000223567 optime=0.000784205 etime=0.001005125
[16/Oct/2023:16:27:25.585391172 +0100] conn=27528 op=3 UNBIND
[16/Oct/2023:16:27:25.585441642 +0100] conn=27528 op=3 fd=140 closed error - U1

So this seems a successful authentication, binds, finds the user, and the U1 closed error is server disconnected from the unbind solicitation.

Now I’m just not sure of what to make of this part of the query:
filter="(uid=user1)" attrs="memberOf"
The whole line is
LDAP_QUERY_STRING='memberOf=cn=sales,cn=groups,cn=accounts,dc=domain,dc=tld'

Now the output of a successful login of another app with similar configuration returns a slightly different search base:

SRCH base="dc=domain,dc=tld" scope=2 filter="(&(uid=user1)(memberOf=cn=user1-group,cn=groups,cn=accounts,dc=domain,dc=tld))" attrs=ALL

I am having some doubts regarding the filters, as on the output from the SuiteCRM auth I don’t see the filter being parsed. Any thoughts?