[Bug]: "ldap_search(): Search: Bad search filter" after successful login

[flacco]

Is there an existing issue for this?

• I have searched the existing issues

Environment

- OS: openSUSE Leap 16.0
- PHP: 8.4.16
- LDAP Server: samba 4.23.7 as an AD Domain Controller

PLA Code

Github release download

PLA Version

2.3.10

Current Behavior

After installation and successful testing the LDAP Connection with artisan ldap:test phpldapadmin shows Error 500.

In debug mode it shows the real error: ldap_search(): Search: Bad search filter

In an earlier installation about 4 week ago it worked fine.

Trace-File:
phpldapadmin-trace.txt

Expected Behavior

Show the LDAP-tree

Steps To Reproduce

1. Just login after successfull setup

Relevant log output

Anything else?

No response

[flacco]

Additional info:

ldapsearch -H ldap://invis.xxxxxxxx.lan:389 -x -D "cn=Admin LDAP,CN=Users,dc=xxxxxxxxx,dc=lan" -W -b "DC=xxxxxxxxx,DC=lan" -ZZ -x -s sub

works without problems.

[leenooks]

Please provide the log in the logs/ dir.
https://github.com/leenooks/phpLDAPadmin/wiki/FAQ#my-issues-are-not-covered-below-how-can-i-debug-whats-going-on

[flacco]

The logfile

laravel-2026-05-14.log

[flacco]

On the LDAP-site I can see the successfully login. After this nothing else happens and the connection terminates.

[leenooks]

Do you have LDAP_GUIDKEY=objectGUID set in your .env file?

[flacco]

Yes

APP_NAME=Laravel
APP_ENV=production
APP_KEY=base64:4ecgW7YOCAQkHKMm3eVHjXsMOfFrOJLDDS/qlLaT+RM=
APP_DEBUG=true

LOG_CHANNEL=daily

CACHE_DRIVER=file
QUEUE_CONNECTION=sync
SESSION_DRIVER=file
SESSION_LIFETIME=120

LDAP_GUIDKEY=objectGUID
LDAP_LOGIN_ATTR=sAMAccountName
LDAP_CONNECTION=starttls
LDAP_HOST=invis.kisslinger.lan
LDAP_BASE_DN="DC=kisslinger,DC=lan"
LDAP_USERNAME="CN=Admin LDAP,CN=Users,DC=kisslinger,DC=lan"
LDAP_PASSWORD=supersecret
LDAP_CACHE=false
LDAP_ALERT_ROOTDN=true

[leenooks]

OK your log file and details provide dont indicate what the problem is. You might need to up your debug level and also look at your LDAP server's debug output to see what is going on.

The error indicates that the value for objectGUID might be blank (or containing an invalid values) that the query to the LDAP server doesnt like) and thus triggering the exception. You'll need to make sure that any ACLs are not prohibiting the logged in user from retrieving that value.

[flacco]

I've increased the log level on ldap-server-site. It shows the same as before:

Auth: [LDAP,simple bind/TLS] user [KISSLINGER][CN=Administrator,CN=Users,DC=kisslinger,DC=lan] at [Thu, 14 May 2026 12:21:06.166041 CEST] with [Plaintext] status [NT_STATUS_OK] workstation [INVIS] remote host [ipv4:172.30.0.10:47010] became [KISSLINGER][Administrator] [S-1-5-21-3774100689-2645920692-1782845634-500]. local host [ipv4:172.30.0.10:389]
{"timestamp": "2026-05-14T12:21:06.166065+0200", "type": "Authentication", "Authentication": {"version": {"major": 1, "minor": 3}, "eventId": 4624, "logonId": "0", "logonType": 8, "status": "NT_STATUS_OK", "localAddress": "ipv4:172.30.0.10:389", "remoteAddress": "ipv4:172.30.0.10:47010", "serviceDescription": "LDAP", "authDescription": "simple bind/TLS", "clientDomain": "KISSLINGER", "clientAccount": "CN=Administrator,CN=Users,DC=kisslinger,DC=lan", "workstation": "INVIS", "becameAccount": "Administrator", "becameDomain": "KISSLINGER", "becameSid": "S-1-5-21-3774100689-2645920692-1782845634-500", "mappedAccount": "Administrator", "mappedDomain": "KISSLINGER", "netlogonComputer": null, "netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null, "passwordType": "Plaintext", "clientPolicyAccessCheck": null, "serverPolicyAccessCheck": null, "duration": 1361}}
[2026/05/14 12:21:06.167125, 5] ../../source4/dsdb/common/util.c:5520(dsdb_search_dn)
dsdb_search_dn: flags=0x00000010 <SID=S-1-5-11> -> Duplicate base-DN matches found for '<SID=S-1-5-11>' (No such object)
[2026/05/14 12:21:06.167614, 3] ../../lib/ldb-samba/ldb_wrap.c:340(ldb_wrap_connect)
ldb_wrap open of privilege.ldb
[2026/05/14 12:21:06.167709, 4] ../../auth/auth_log.c:969(log_successful_authz_event_human_readable)
Successful AuthZ: [LDAP,simple bind] user [KISSLINGER][Administrator] [S-1-5-21-3774100689-2645920692-1782845634-500] at [Thu, 14 May 2026 12:21:06.167706 CEST] Remote host [ipv4:172.30.0.10:47010] local host [ipv4:172.30.0.10:389]
{"timestamp": "2026-05-14T12:21:06.167717+0200", "type": "Authorization", "Authorization": {"version": {"major": 1, "minor": 2}, "localAddress": "ipv4:172.30.0.10:389", "remoteAddress": "ipv4:172.30.0.10:47010", "serviceDescription": "LDAP", "authType": "simple bind", "domain": "KISSLINGER", "account": "Administrator", "sid": "S-1-5-21-3774100689-2645920692-1782845634-500", "sessionId": "16c6a8ac-7355-42fb-8d2a-9dde4b05f4e6", "logonServer": "INVIS", "transportProtection": "TLS", "accountFlags": "0x00000010", "clientPolicyAccessCheck": null, "serverPolicyAccessCheck": null}}
[2026/05/14 12:21:06.168380, 5] ../../source4/ldap_server/ldap_backend.c:836(ldapsrv_SearchRequest)
ldapsrv_SearchRequest: ldb_request BASE dn= filter=(objectclass=)
[2026/05/14 12:21:06.168704, 5] ../../source4/ldap_server/ldap_backend.c:1049(ldapsrv_SearchRequest)
ldapsrv_SearchRequest: LDAP Query: Duration was 0.00s, SearchRequest by S-1-5-21-3774100689-2645920692-1782845634-500 from ipv4:172.30.0.10:47010 filter: [(objectclass=)] basedn: [] scope: [BASE] result: Success
[2026/05/14 12:21:06.242562, 3] ../../source4/samba/service_stream.c:67(stream_terminate_connection)
stream_terminate_connection: Terminating connection - 'ldapsrv_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_RESET'

It says that the login was successfully and then nearly nothing.

The only interesting point is: "filter: [(objectclass=*)] basedn: [] scope: [BASE] result: Success". It seems that the baseDN is empty.

[flacco]

I am not a software developer, but I found something strange.

The first LDAP-Search after login stops at "public function findByGuid($guid): ?Model" in "app/Ldap/LdapUserRepository.php", but there is no guidKey defined in model "ActiveDirectory". So the function findByGuid could not work with AD.
Am I wrong? Where is the model to use defined? If phpldapadmin uses the wrong LDAP-Model, it could not work.