LDAP Login Fails ("did not successfully bind") but ldapsearch from server works perfectly

[bzdelka]

Hello Snipe-IT Team,

I'm having an issue with LDAP login on a fresh installation. The initial "Test LDAP Connection" is successful, but when I try the "Test LDAP Login" with a valid user's credentials, it fails with the error: Login Failed. did not successfully bind to LDAP.

The strange part is that all my credentials and paths are correct, which I have verified using ldapsearch directly from the Snipe-IT server's command line.

Environment:

Snipe-IT Version: Laravel Framework 11.44.1 (get with php artisan --version)

OS: Ubuntu 24.04

Web Server: Apache/2.4.58

PHP Version: PHP 8.3.6 (cli) (built: Mar 19 2025 10:08:38) (NTS) (get with php -v)

Database: MySQL 8.0.42

Installation type: Manual install from Git

Error Message from "Test LDAP Login":
Login Failed. did not successfully bind to LDAP.

What I've already tried (Diagnostics):

ldapsearch from the server CLI works perfectly. I used the exact same credentials, server IP, Base DN, and filter as in my .env file, and it successfully finds and returns the user's data.

Bash

This command succeeds:

ldapsearch -x -H ldap://YOUR_SERVER_IP -D "YOUR_BIND_DN" -W -b "YOUR_BASE_DN" "(sAMAccountName=testuser)"
PHP LDAP Extension is installed and active. The command php -m | grep ldap returns ldap.

Database connection is working. php artisan db:show returns the correct database info and tables.

Tried both encrypted and unencrypted connections. The error is the same with ldap:// (port 389) and ldaps:// (port 636, with LDAP_USE_TLS=true).

Set the Active Directory Flag. The error persists even with LDAP_AD_FLAG=true in the .env file.

Cleared all caches multiple times after every change to .env (config:clear, route:clear, view:clear, cache:clear).

File permissions are correct for the storage and bootstrap/cache directories.

Given that ldapsearch works, this seems to be an issue within Snipe-IT's specific bind implementation rather than a credential or connectivity problem.

Could you provide any insights on what else might be causing the user bind to fail only within the application?

Thank you for your help!

[snipe]

Hi there - can you upgrade to latest (v8.3.1) and try the LDAP Troubleshooter?

[snuggles4553]

Our Snipe-IT LDAP sync broke after upgrading to v8.3.1.

This command prints an ldapsearch command:

snipeit@snipeit:/var/www/snipeit$ php artisan ldap:troubleshoot --ldap-search

Example output:

 WARNING: This command will display your LDAP password on your terminal. Are you sure this is ok? (yes/no) [no]:
 > yes

# Adding LDAP Client Certificate and Key


LDAPTLS_CERT=storage/ldap_client_tls.cert \
LDAPTLS_KEY=storage/ldap_client_tls.key \
ldapsearch \
-H ldaps://ldap.google.com \
-x \
-b 'dc=example,dc=tld' \
-D 'USERNAME_WILL_BE_SHOWN_HERE' \
-w 'PASSWORD_WILL_BE_SHOWN_HERE' \
'(&(cn=*))' \
-v

When we run that ldapsearch command, it prints users from the LDAP directory just fine, no problem.

However, the problem is, the Snipe-IT LDAP sync is broken:

$ /usr/bin/php /var/www/snipeit/artisan snipeit:ldap-sync --json_summary
{"error":true,"error_message":"Could not bind to LDAP: Invalid credentials","summary":[]}

I run this Snipe-IT version:

$ git branch
* (HEAD detached at v8.3.1)
  master

In the web UI, the LDAP sync works fine too. It's just that the php artisan snipeit:ldap-sync cron job is broken.

[snipe]

@snuggles4553 what version were you upgrading from?

[snuggles4553]

@snuggles4553 what version were you upgrading from?

Hi @snipe,

the git log command reveals the following:

$ git log
commit 28abb8d8cc269af554f562bac639124e3cf5bc3d (HEAD -> master, origin/master, origin/HEAD)
Author: snipe <snipe@snipe.net>
Date:   Thu Aug 1 12:30:35 2024 +0100

    Hotfix for 405 update asset
    
    Signed-off-by: snipe <snipe@snipe.net>

commit fcea564afa4eb2856e6a7c58e0cc04edb7aa9a0a
Author: snipe <snipe@snipe.net>
Date:   Wed Jul 31 21:44:27 2024 +0100

    Fixed button label
    
    Signed-off-by: snipe <snipe@snipe.net>

commit 39727820330d4abe434b1491ffe55fc1a6308146 (tag: v7.0.10)
Merge: c2bcc2e2d 33b86057d
Author: snipe <snipe@snipe.net>
Date:   Mon Jul 29 18:27:56 2024 +0100

    Merge remote-tracking branch 'origin/develop'
    
    Signed-off-by: snipe <snipe@snipe.net>
    
    # Conflicts:
    #       config/version.php

Further notes:

Note, I've tried debugging ./app/Models/Ldap.php a little bit, and in the bindAdminToLdap function it does seem that the correct username and password are passed to ldap_bind, despite the Invalid credentials error. The credentials are identical to the ones that we are printed when we ask Snipe-IT to generate the ldapsearch command via php artisan ldap:troubleshoot --ldap-search, and indeed when I run that command (as shown earlier), those exact same credentials do actually work.

I also tried swapping line endings in the LDAP certificate (.crt) and key (.key) files, from DOS to Unix, and vice versa, but that didn't make a difference, and it didn't matter to the ldapsearch command either, as ldapsearch kept working fine regardless.

Partial output from echo '<?php phpinfo();' | php:

phpinfo()
PHP Version => 8.4.11

System => Linux snipeit 6.1.0-38-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.147-1 (2025-08-02) x86_64
Build Date => Aug  3 2025 07:32:21
Build System => Linux
Build Provider => Debian
Server API => Command Line Interface

...
...
...

ldap

LDAP Support => enabled
Total Links => 0/unlimited
API Version => 3001
Vendor Name => OpenLDAP
Vendor Version => 20610
SASL Support => Enabled

Besides the LDAP sync problem, Snipe-IT otherwise functions properly.

[uberbrady]

@snuggles4553 Is it possible that /usr/bin/php is a different version of php than what's running on your webserver? I've seen that one before.

As for @bzdelka , do you have the checkbox checked for 'allow invalid certificates' checked? It's possible that CLI PHP has a different concept of what certificates are valid than what PHP might think.

[uberbrady]

Another thing to try - php artisan ldap:troubleshoot without the --ldap-search flag - that should try some raw PHP attempts to log in to your LDAP server. It's (in the past month or so) been upgraded a little bit, so it might help diagnose what's going wrong here.

[snuggles4553]

@snuggles4553 Is it possible that /usr/bin/php is a different version of php than what's running on your webserver? I've seen that one before.

It's the same version that the web server is using. The same version that I showed earlier (8.4).

Another thing to try - php artisan ldap:troubleshoot without the --ldap-search flag - that should try some raw PHP attempts to log in to your LDAP server. It's (in the past month or so) been upgraded a little bit, so it might help diagnose what's going wrong here.

I had tried the LDAP troubleshooter before (didn't mention that). But the LDAP connection in the web UI works, so that means that there's no change in LDAP settings on the server-side. And indeed, every combination that the LDAP troubleshooter tried failed with the same invalid credentials message, even when I enter the correct credentials (the same ones that worked when we used ldapsearch).

[uberbrady]

@snuggles4553 Weird, very weird. I wonder if you have two installs running here, and one is pointing to a wrong database?

Here's a check you can run -

php artisan tinker
Psy Shell v0.12.9 (PHP 8.3.24 — cli) by Justin Hileman
> Crypt::decrypt(Setting::getSettings()->ldap_pword)
[!] Aliasing 'Setting' to 'App\Models\Setting' for this Tinker session.
= "REDACTED_PASSWORD"

Does that show up with the password you expect? you can also (from within Tinker) run Setting::getSettings() and you should see all of your LDAP settings - do they show up right?

What's bending my brain on this one is that the troubleshoot with the ldap-search option is gving you results that give you the right output, but the actual snipeit:ldap-sync is somehow not working - the web 'button-push' LDAP sync is just a thin wrapper around snipeit:ldap-sync, so there shouldn't be much (if any) of a difference.

[snuggles4553]

@snipe

I have reproduced the problem in a small test case.

<?php

$USERNAME = 'example';
$PASSWORD = 'example';

$ldap_version = 3;

$connection = ldap_connect('ldaps://ldap.google.com');

ldap_set_option($connection, LDAP_OPT_PROTOCOL_VERSION, $ldap_version);

ldap_set_option(null, LDAP_OPT_X_TLS_CERTFILE, 'ldap-google.crt');
ldap_set_option(null, LDAP_OPT_X_TLS_KEYFILE, 'ldap-google.key');

$result = ldap_bind($connection, $USERNAME, $PASSWORD);

var_dump($result);

var_dump($connection);

This worked. No errors.

Then, I tried upgrading the Linux system. Afterwards, the script showed the same LDAP error that Snipe-IT was showing.

Here's the output after upgrading from Debian 12 (uses PHP 8.2) to Debian 13 (uses PHP 8.4):

PHP Warning:  ldap_bind(): Unable to bind to server: Invalid credentials in /root/test.php on line 15
bool(false)
object(LDAP\Connection)#1 (0) {
}

In other words, the Snipe-IT LDAP sync broke after the PHP version was changed from 8.2 to 8.4 which happened automatically after upgrading Debian.

However, the Snipe-IT requirements say that PHP 8.4 should be supported, quote from the docs: PHP >= 8.2.0

@uberbrady See my earlier posts. I mentioned that the password is correct.

[snuggles4553]

Here is a workaround for anyone stumbling upon the issue that I encountered (a broken LDAP sync in Snipe-IT after upgrading to Debian 13):

systemctl stop apache2
systemctl stop mariadb
a2dismod php8.4
apt install libapache2-mod-php8.2 php8.2 php8.2-bcmath php8.2-cli php8.2-common php8.2-curl php8.2-gd php8.2-ldap php8.2-mbstring php8.2-mysql php8.2-opcache php8.2-readline php8.2-xml php8.2-zip
update-alternatives --set php /usr/bin/php8.2
a2enmod php8.2
systemctl start mariadb
systemctl start apache2

This workaround installs PHP 8.2 and sets it as the default PHP version for both the system and the Apache web server. For me, that fixed the LDAP sync in Snipe-IT v8.3.1. Before applying this workaround, I was using PHP 8.4 which is the default in Debian 13, and that was the only version I had installed.

For this workaround, I first enabled the excellent deb.sury.org repository on Debian 13. So we're now running Debian 13 with PHP 8.2 instead of PHP 8.4, and Snipe-IT works properly again, including the LDAP synchronization! 🥳

@snipe Hopefully this confirmation along with my earlier troubleshooting info helps you pinpoint the problem. Cheers 🙂

[snipe]

@snuggles4553 - thanks so much for digging in a little more. What's sort of weird is that 8.4 didn't (AFAIK) introduce anything that should have changed that behavior.

I use 8.4 for local development and testing (and we should definitely be able to support it since we say we do), and I can't reproduce this on 8.4, but this additional context definitely feels like it gets us closer to a longer-term solve.

This is great info - not sure exactly what to do with it yet, since that's just a mid-release of PHP and shouldn't cause this sort of regression, but at least we can help advise people in a similar situation while we try to figure out WTF.

I still need to find that smoking gun (and the code patch that handles it properly for all versions of PHP that we claim to support) but this is a lot more than we had before. Very much appreciated!