LDAP Invalid Credentials - Works on XAMPP, not on Docker

[Tyree]

Debug mode

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

Describe the bug

This isn't really a bug, as far as I know. I just need some help/insight.
I've had Snipe-it running on a XAMPP server for over a year, no problems. I decided to set it up on Docker instead (linuxserver image on Synology), but I can't get it to connect to our Windows Server LDAP server with the exact same settings. Says Invalid credentials.
From the container console, I can ping the LDAP server via IP and name. So I know the container can "see" the LDAP server.
I've tried the credentials that the XAMPP install is using and our main domain admin account. No luck.
I've checked the php info on the container and ldap is enabled.

I'm running Snipe-it version 6.1.2 on docker and 6.0.13 on XAMPP.
Any ideas what I may be missing?

Reproduction steps

1. Input LDAP settings that match XAMPP install
2. Click Test LDAP Sync
3. Get error message: Could not bind to LDAP: Invalid credentials

Expected behavior

Successful connection to LDAP server as on XAMPP installation.

Screenshots

No response

Snipe-IT Version

v6.1.2 build 10938 (g32747cafd)

Operating System

Docker

Web Server

Apache via Docker

PHP Version

8.1.22

Operating System

No response

Browser

No response

Version

No response

Device

No response

Operating System

No response

Browser

No response

Version

No response

Error messages

No response

Additional context

No response

[uberbrady]

I would try our own image - snipe/snipe-it - you might have better luck with that. I don't know anything about the linuxserver one.

[Tyree]

It appears I might have a deeper issue anyway. Even though I tested while I was writing this help post, now even the XAMPP install is saying invalid credentials. Makes no sense, but definitely does not appear to be a Snipe-It problem.

[Tyree]

After saving the LDAP settings, should the LDAP Bind Password blank be empty again? Or should there still be dots? It makes sense if it's only stored in the database and not repopulated in the form after saving. Just making sure.

[snipe]

We keep it blank so we know it shouldn’t be modified when you save it. If you enter something new, it will save. If it’s blank, we don’t modify it.

[Tyree]

Okay. Makes sense.
This is a head-scratcher. I have code I've written myself on another in-house app on the same XAMPP server as Snipe-It and the LDAP code in there is working perfectly (So the LDAP server is there and responding). I am not understanding why the XAMPP install of Snipe-It suddenly stopped working. Earlier I could hit the test button and I'd see a list of all users. Now, nothing but invalid credentials no matter which credentials I use. Ack!

[Tyree]

So now I'm trying to restore to an earlier backup and it's like it's completely resetting the install. Goes back to the Pre-Flight screen and when I finally log in, even the visual settings are reset. All assets are gone, etc.
I even tried using the same backup zip file I used to restore to the docker install (which worked beautifully) and it resets. Makes me put in the admin user again, but tells me the username is already used.
All my August backups are still there, so I haven't lost anything. But this is really going downhill fast.

[snipe]

What’s in your app logs?

[Tyree]

What’s in your app logs?

Where are they located? I see the storage>logs folder, but hat just has a laravel.log file.

[snipe]

Depending on how mysql was configured, we do sometimes see some stray @ lines in the SQL dump that interferes with the import. Since the restore tool first drops the tables, if it can’t import properly, it has no choice but to kick you back to preflight. When you look at the database itself right after an attempted restore, are there tables? Pre-flight kicks in when 1) there is no record in the settings table OR 2) there are no users.

[Tyree]

These are the only 3 entries for today in the laravel log:
[2023-08-22 14:00:16] production.WARNING: Attempting to restore user: matt
[2023-08-22 14:03:08] production.WARNING: Attempting to restore user: matt
[2023-08-22 14:05:48] production.WARNING: Attempting to restore user: matt

Maybe hinting that it couldn't restore the user?

[Tyree]

After restore, there are tables in the database. I have not yet clicked the Create Database Tables button.
When I look at the users table, the matt user is already there.
But the settings and assets tables are empty.

[snipe]

What’s your log_level set to in your env? You might want to set it to debug so you can see a bit more output.

[Tyree]

I did a manual import of the sql dump and that got it back up. And now testing LDAP works again. Go figure. So now back to figuring out why it works here, but not on docker. :-D
LOG_LEVEL wasn't set at all in the .env file. I just set it to warning. But, looks like I was already getting warnings without it set. Should I set it lower? Is notice the next level down?

[Tyree]

HA! I got it! Now that the XAMPP install was restored, I realize what happened. I have Bitwarden and it had auto-filled the username and password blanks for the LDAP settings with the credentials I use to log into Snipe-It. While technically "correct" for my Windows/LDAP user, it had dropped the FQDN from the end of the username needed to log into LDAP. I had already set Bitwarden to not auto-fill, but the damage was already done.
I think all issues are solved now. Other than why the restore wasn't working correctly.

[snipe]

AHHHH - nice sleuthing! On the user create screen, we implement a few tricks to prevent auto filling (since we don’t want to overwrite a random new user’s password with the password of the logged in user) - I don’t recall if we do that on the LDAP screen, but we probably should.

[Tyree]

AHHHH - nice sleuthing! On the user create screen, we implement a few tricks to prevent auto filling (since we don’t want to overwrite a random new user’s password with the password of the logged in user) - I don’t recall if we do that on the LDAP screen, but we probably should.

If you do somehow prevent it on the LDAP screen, Bitwarden didn't care and filled it in anyway. :-D
Isn't it funny how it all makes sense after you finally figure it out. Like, duh, of course that's why it wasn't working! :-D

[snipe]

I don’t think we implemented it there, but it should be easy enough to do. The tricks we use don’t work across all browsers unfortunately, but we’ve implemented every trick we know on the users’s screen. (Using hidden fields that the browser will fill in but that we don’t save so they get overwritten, using autofill=“off”, etc) so I think we can give that a try on the settings page. We have a PR in testing that rewrites the LDAP interface, so I’ll probably add it to that versus the current LDAP page.

[snipe]

Well crap. We already have the hidden fields. Good for us for thinking ahead, bad news that it doesn't seem to have worked in your case.

snipe-it/resources/views/settings/ldap.blade.php

Lines 41 to 43 in b93adf4

	<!-- this is a hack to prevent Chrome from trying to autocomplete fields -->
	<input type="text" name="prevent_autofill" id="prevent_autofill" value="" style="display:none;" />
	<input type="password" name="password_fake" id="password_fake" value="" style="display:none;" />

I do see that we're using the wrong value for form autocompleting:

snipe-it/resources/views/settings/ldap.blade.php

Line 37 in b93adf4

{{ Form::open(['method' => 'POST', 'files' => false, 'autocomplete' => 'false', 'class' => 'form-horizontal', 'role' => 'form']) }}

But that tag is largely ignored by most browsers anyway, so I'm not sure it will handle your issue. We might be able to disable that field unless it's clicked into, the way we do on the users edit/clone screen.

[Tyree]

Thanks, @snipe
I wonder if it's specific to Bitwarden and/or other password managers. I'm not using Chrome to store/autofill, so I'm not sure the hack works with independent password managers.
I'm not sure how "smart" Bitwarden is by default, but I can specify individual fields, no matter what they are named, to be autofilled. It may look for any field with "password" in the name/id and fill them all.
I've noticed such things when I go to edit my profile on some websites where a password reset form is available. It will fill the current password and both new password fields with the stored password. Which can get the user into trouble in some cases, as with Snipe-It. Not realizing a field is filled and then save the form.
I'd say, in any case, it's up to the user of the password manager to realize these things can happen. Not up to developers like you to protect them from themselves. But I do appreciate the effort. :-)

[snipe]

That field is actually called ldap_pword, so it's odd that it would pick that up. It is a password field (so we don't present the password on the screen, but instead do the "*********" thing, so maybe that's what it's cuing off of. You can maybe try this workaround? (I don't use Bitwarden myself, so I'm just googling on your behalf)

I did merge the changes I made to master, so if you update to latest on master you might give that another go. Other than that, I'm afraid I'm out of ideas :(

[Tyree]

Thanks, @snipe ! I already disabled autofill on the Snipe-It url, so I don't have the problem anymore. I was mostly just speculating on what you'd be up against trying to prevent password managers from autofilling. They can be persistent! :-)
Yeah, maybe it looks for fields that are type="password", not just those with "password" in the name. Not sure what kind of voodoo they do. :-)
I've definitely had it fill in plenty of things when I didn't want it to. Ironically, even the admin settings page for my self-hosted Bitwarden docker has different password fields for the admin key, SMTP auth, etc... autofill! :-D
Thanks again!