ldap_search(): Search: Bad search filter

[triple-HA]

Debug mode

• [X] I have enabled debug mode
• [X] I have read checked the Common Issues page

Describe the bug

In v6.0.2 I can sync by LDAP, but I get "ldap_search(): Search: Bad search filter" after testing LDAP login

Reproduction steps

1. Go to the admin/ldap
2. Adding credentials to connect with LDAP server
3. Test it
4. After getting "OK" status I go lower to use "Test LDAP Sync"
5. I put the same credentials in "Test LDAP Login" fields
6. Getting error: ldap_search(): Search: Bad search filter ...

Expected behavior

All users cant loggin in to the service.

Screenshots

Snipe-IT Version

6.0.2

Operating System

Ubuntu

Web Server

Apache

PHP Version

7.4.3

Operating System

Windows

Browser

Google Chrome

Version

101.0.4951.67

Device

No response

Operating System

No response

Browser

No response

Version

No response

Error messages

[10:58:24] LOG.debug: Preparing to test LDAP login
[10:58:24] LOG.debug: Attempting to bind to LDAP for LDAP test
[10:58:24] LOG.debug: Filter query: ((uid=samaccountname*****.*****))
[10:58:24] LOG.debug: LDAP login failed

*****.*****   - name.surnam (user login credentials)

Additional context

upgrade from v5.4.4 to v6.0.2

[welcome[bot]]

👋 Thanks for opening your first issue here! If you're reporting a 🐞 bug, please make sure you include steps to reproduce it. We get a lot of issues on this repo, so please be patient and we will get back to you as soon as we can.

[YannickJaeckle]

We've the same issue in windows server environment (Windows Server 2019 with mariadb) . After updating Snipeit from v5.4.2 to v6.0.0 and v6.0.2 users they changing their active directory password they could not access / login to asset management. Users they don't change their password the login works good as well.

When we sending user an password reset link after the user changing this password the login works. I suppose the password is set localy on the asset mgmt server but no ldap authentication.

Hopefully there is a solution for the ldap password sync so far.

@triple-HA triple-HA Maybe you can try to send your issued user a password reset link as a workaround.

[triple-HA]

@triple-HA triple-HA Maybe you can try to send your issued user a password reset link as a workaround.

We have LDAP password sync turned on. Username and password are Managed via LDAP. Today I created a new AD user and then I synchronized the snipe-it service with it, but after that when I tried to login it unfortunately failed. Even if I uncheck the option to synchronize password in LDAP settings I'm not able to reset the user password - it still shows me "Managed via LDAP"

[WSULinuxOwner]

This is also an issue for us as well. We upgraded to 6.0.2 and our ldap users are not able to login. Local accounts work fine.

[uberbrady]

Your LDAP auth filter should probably be sAMAccountName=

[daurpam]

Your LDAP auth filter should probably be sAMAccountName=

We have same problems after upgrading to version 6.0.2. But changing that on filter LDAP auth filter works for our config.

Thank you!

[YannickJaeckle]

We've changed our LDAP Filter from memberOf=CN... to &(memberOf=CN...) and LDAP Query to samAccountName= and it works well.

Have also a look here: https://github.com/snipe/snipe-it/issues/11239

[MrHackino]

The issue is still active for me, I ran the troubleshooting module for LDAP and get this exception caught. WARNING: Exception caught during Authed bind to uid=accountldap,ou=XXXX,o=[Jumpcloud Token],dc=jumpcloud,dc=com - Trying to access array offset on value of type resource Unable to get information from bind.

[simsjdf]

Having similar issues on version 6.0.8 build 8409. PHP version is 7.4.30 and Laravel version is 8.83.22. We're hosted so not seeing a way to access logs or debugging info.

LDAP Authentication query is: sAMAccountName= LDAP Filter is: mail=*.domain.tld

Same things are happening to us. Test LDAP Sync works fine. Can do an LDAP Sync under the People section no problem. But users cannot login and the Test LDAP Login fails.

I saw another issue where someone posted that using "domain\username" instead of plain username worked for them. But that does not appear to be the case for us.

[uberbrady]

Oh, if you're hosted you should definitely reach out to support@snipeitapp.com and we'll definitely get you through it.

But that filter based on mail looks like it should work, and that auth query looks good to me (if you're using 'short usernames'). Once we know which account you're on, we'll check the logs for you and advise from there.

Sometimes if your directory service provider requires two-factor auth, that can be an issue as well.

Another thing to keep an eye on is if anything shows up in the LDAP settings with a red outline - those will definitely need to be addressed.